Mike, In IBIS 5.0, BIRD 127.4 and 123.x, I could not find any reserved parameters that are defined as Usage In or InOut, such as the table on page 148 of IBIS 5.0. Are you aware of any reserved parameters that are Usage In or InOut? For model specific parameters, is it outside of the scope of the Specification to define their meaning and, how they should be processed by AMI_Init/GetWave or EDA tools (other than the fact that EDA tools must include them when constructing *AMI_parameters_in)? To further illustrate this point, let's consider the example in your email: "When we have a parameter of Usage In and Format List, what do we send in to the model through ami_parameters_in? Do we send a single value or do we send the entire list? ". If this is a model specific parameter, would it only make sense to let the user making this decision? The EDA tool may also choose to make this decision based on its knowledge about a particular parameter in a particular model. In either of these cases, is it outside the scope of the Specification to make decisions about how to select values from model specific parameters? The only requirement that the Specification should impose upon EDA tools and AMI models (w.r.t. model specific parameters) is that, Usage In and Inout model specific parameters must be retrieved as is from .ami and passed to AMI_Init using *AMI_parameters_in, with the understanding that EDA tools may allow the user to select/manipulate them, before passing them to AMI_Init. However, it should be out of the scope of the Specification to regulate how they should be selected or manipulated. Thanks, James Zhou From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger Sent: Friday, December 16, 2011 4:30 PM To: Bob Ross Cc: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Yet another problem with Usage Out Bob- Thanks for catching me up. This helps. Mike S. On 12/16/2011 05:43 PM, Bob Ross wrote: Mike: I do not know the answer in IBIS 5.0, but with BIRD132 http://www.eda.org/pub/ibis/birds/bird132.txt the your line below could be specified in the .ami file as a one-row Table: Sent to Executable Model: (froboz(grue -1.3e9 0 -4.2e9 0)) ------- AMI File: (froboz (grue (Usage In) (Type Float) (Table (Labels "number1" "number2" "number3" "number4") (-1.3e9 0 -4.2e9 0) ) ) ) The Labels line is optional and is not transmitted. The new Table syntax supports multi-line Tables and also individual Type entries for each column, as shown in BIRD132 for all Usage choices. We also support predefined two- and tree-valued Formats (Gaussian, Dual-Dirac and DjRj), and the <data> for these parameter would be two or three numbers according to the proper definition of " leaf" in the Section 10 BNF as (<parameter name> <value list>) as in your question. Bob From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger Sent: Friday, December 16, 2011 1:18 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: Yet another problem with Usage Out Arpad- When we have a parameter of Usage In and Format List, what do we send in to the model through ami_parameters_in? Do we send a single value or do we send the entire list? We send in a single value selected from the list. There's no reason to suppose that a model sending a value back would do anything else. It will send back a single value from the list. Consider, however, that currently we have no way to declare an array-type value in an AMI file. That makes the array value syntax we put into the parameter string definition considerably less useful. We have run into this problem a number of times in the work we've done; and the solution we came up with is not at all pretty. For example, suppose I want the following parameter string sent into the model: (froboz(grue -1.3e9 0 -4.2e9 0)) According to IBIS 5.0, that's a valid parameter string syntax. The parameter grue has a value which is an array of floating point numbers. What can I put in an AMI file that would tell the EDA tool to generate this parameter string? Thanks. Mike S. On 12/16/2011 01:46 PM, Muranyi, Arpad wrote: Hello everyone, In the process of trying to make heads and tails of this Usage Out discussion, I discovered another interesting situation with the Usage Out parameters. Let's assume that the .ami file contains this perfectly legal parameter definition: (MyExample (Description "Example") (Reserved_Parameters (MyRterm (Usage Out) (Type Integer) (List 100 80 90 110 120) (Default -1) (Description "Illustration") ) ) ) What is the model supposed to return? A single value or multiple values? According to BIRD 127.4 the AMI_parameters_in/out strings can only contain "leaf/value pairs", i.e. a single value for each parameter name (or a Table according to BIRD 132). |**** 2) the AMI Parameter branches Usage Out or Usage InOut are |**** returned as leaf/value pairs in the AMI_parameters_out |**** string. If that is true, why would one define a Usage Out parameter as anything else but Value, Default or Table? If the purpose of defining a Usage Out parameter as a List, for example, would be to tell the EDA tool that the returned value from the Model is a List, we are out of luck, since lists can't be passed through the AMI_parameters_out strings. It seems to me that we have another conflict here. To remove this conflict we should not allow anything else but Value, Default, or Table for Usage Out parameters, or figure out a way to pass more than just "leaf/value pairs" through the parameter string. Comments, questions, suggestions welcome. 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<mailto:ibis-macro-request@xxxxxxxxxxxxx> Subject: unsubscribe ________________________________ This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.