Ken-The unstated assumption has always been that the correct conditions have been set up before the analysis begins. The IBIS file and the AMI file have always been needed to set up the correct conditions.
The only significant change here is that the AMI file contains information about the analog circuit, supplementing the information in the IBIS file.
Mike S. On 01/07/2011 10:36 AM, Ken Willis wrote:
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
--------------------------------------------------------------------- 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