[ibis-macro] Re: Comments on BIRD 124
- From: "Ken Willis" <kwillis@xxxxxxxxxxx>
- To: <wkatz@xxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 7 Jan 2011 11:36:37 -0500
Hi all,
I missed one of the other meetings on this topic, so I apologize if it was
covered already.
This BIRD brings up a bigger question to me. As we talk about the
high-impedance boundary between the circuit and algorithmic model, it looks
like a lot of the Dependency discussion is around defining analog circuit
parameters in the AMI file (I have seen the same types of models as Arpad).
If so, there are some flow-related issues here.
You need the right circuit to generate the impulse response, which happens
before you get to the algorithmic (DLL) models. So is the proposed flow for
this BIRD to go find and read the AMI files in the topology, identify the
circuit models that goes with them (presumably parameterized), go stuff the
appropriate parameter values into the circuit models, and then we are back
into the standard flow?
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, January 06, 2011 4:57 PM
To: Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Comments on BIRD 124
Arpad,
Since Tx_Strength is Usage In, then it is input to the DLL.
In the case of Ivod and Rterm, the model maker chose to make them Usage
In. Whether they actually used by the DLL and under what circumstances
they are used is known by the model maker, and only the model maker. It is
his choice on how he documents what the effects are. He must, of course,
document Info and Out parameters so that the EDA Vendor, or user of the
model know what to do with them and how to treat them.
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, January 06, 2011 4:38 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Comments on BIRD 124
Walter,
Without an accompanying DLL it is hard to tell whether "Tx_Strength"
in the example of BIRD 124 would really go into the DLL or not, but I will
take your word for that.
However, I have more than one AMI models in my possession which seem to
have parameters in their .ami file which do not result in changes in the
output when the parameter values are changed. In addition, the name of
these parameters imply analog behavior, which further reinforces my
thinking that the executable DLL is not making use of them. On top of
that, these parameter names do not match any of the analog model parameter
names described in BBIRD 122, so I concluded that these must be just for
the purpose of controlling the Dependency Table.
Without mentioning the vendor's name I have an .ami file with a
Model_Specific "Ivod" and "Rterm" parameter. They appear in the
Dependency Table's 1st and 2nd columns. When I change them and execute
the DLL, the results are the same. These parameters are not described in
BIRD 122, so they couldn't possibly be used for the analog model, even
though I know they refer to the analog buffer's behavior. Since I know
that these would have a strong affect on the amplitude of the waveform
results, I would expect to a different eye after executing the DLL, but I
don't get that.
That's what made me conclude that these parameters are only used for the
purpose of the Dependency Table selections.
Am I missing something?
Thanks,
Arpad
=======================================================================
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, January 06, 2011 3:10 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Comments on BIRD 124
Arpad,
All of the data in the Dependency tables are Info. The parameter
Tx_Strength is In and is meant to be input to the DLL. The Dependency
table is just a mechanism for telling the EDA Tool (GUI) how to determine
the values of these parameters.
(List "Tx_Strength In" "Rs Out_Match" "Voh Out_Match")) is meant to
convey that the parameter Tx_Strength is an INdependent parameter that is
an input rather than an output of this dependency table.
I would prefer that (Usage Info)(Type String) be not required in the
rows of the Dependency table, and that the fields within the List that
defines the table only require " when the parameter at the top of that
corresponding table is String. The structure that I came up with here is
required so that it passes the existing parser, and AMI rules, but if we
approve this as part of IBIS 5.1 than we can change the rules and formats,
as long as the basic functionality is maintained.
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, January 06, 2011 3:42 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Comments on BIRD 124
I would like to comment on BIRD 124, the Dependency Table BIRD.
Pg. 140 of our existing specification says the following:
| Usage: (required for model specific parameters)
| In Parameter is required Input to executable
| Out Parameter is Output only from executable
| Info Information for user or EDA platform
| InOut Required Input to executable. Executable may return different
| value.
On the other hand, BIRD 124 describes the control parameters of the
Dependency Table as Usage In. These parameters, however, are not passed
into the AMI executable models (contrary to the rule on pg. 140). This
will create a contradiction or discrepancy in the specification once BIRD
124 gets approved. The example in BIRD 124 illustrates this:
| (Tx_Strength (Usage In)(Type String)
| (List "0" "1" "2" "3" "4" "5" "6" "7")
| (Description "Output buffer strength setting")
| )
|
| (Rs (Usage Info)(Type Float)
| (List 45.0 46.0 48.0 50.0 52.0 50.0 48.0 45.0)
| (Description "TX output impedance")
| )
|
| (Voh (Usage Info)(Type Float)
| (List 0.40 0.42 0.44 0.46 0.48 0.50 0.52 0.54)
| (Description "TX output voltage")
| )
|
| .
| .
| .
|
| (Tx_Strength_Table
| (Dependency
| (Parameter (Usage Info)(Type String)
| (List "Tx_Strength In" "Rs Out_Match" "Voh Out_Match"))
| (Row1 (List "0" "45.0" "0.40")(Usage Info)(Type String))
| (Row2 (List "1" "46.0" "0.42")(Usage Info)(Type String))
| (Row3 (List "2" "47.0" "0.44")(Usage Info)(Type String))
| (Row4 (List "3" "50.0" "0.46")(Usage Info)(Type String))
| (Row5 (List "4" "52.0" "0.48")(Usage Info)(Type String))
| (Row6 (List "5" "50.0" "0.50")(Usage Info)(Type String))
| (Row7 (List "6" "48.0" "0.52")(Usage Info)(Type String))
| (Row8 (List "7" '45.0" "0.54")(Usage Info)(Type String))
| )
| )
where Tx_Strength is Usage In but is not passed into the AMI executable
model.
I see two ways of fixing this problem. One would be to change the words
on pg. 140 about Usage and say something that In can be used for other
purposes than passing parameters into the executable models. The other
would be to find a different Usage name for the Dependency Table control
parameters.
I would prefer the second, because BIRD 122 as well as the Opal document
says that all the analog parameters must be of Usage Info.
If the analog parameters are Info (going to the tool) and the AMI
executable model parameters are Usage In (or InOut), I think the
Dependency Table control parameters should either be Info (since they are
processed by the tool interpreting the Dependency Table), or we should
come up with another distinct Usage type which is strictly meant to be
used for the Dependency Table.
Thanks,
Arpad
====================================================================
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
