A couple of comments added below in RED BOLD. Arpad ============================================== From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger Sent: Friday, December 16, 2011 10:01 PM To: James Zhou Cc: Bob Ross; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Yet another problem with Usage Out James- You and I are pretty much in complete agreement (except for how the Model_Speific AMI_parameters_in string is formatted). In particular, as long as the EDA tool can know how to form a correct input to the model and the model can know how to form a correct output to the EDA tool, then the specification has done its job. Nothing more is required. Also, you are quite correct about reserved parameters. There is some information about a given model that the EDA tool needs in order to form a correct input to the model or interpret the output of the model correctly. That is, the information must directly affect the behavior of the EDA tool. This information is interpreted directly by the EDA tool and therefore must be expressed in a standard way. Also, this information concerns a specific model, and therefore must be expressed either by the model developer or the model itself. This is the role that reserved parameters play. Since the only role of reserved parameters is to convey specific information from the model developer or model to the EDA tool, the only Usages that make sense for a reserved parameter are Info (communication from the model developer to the EDA tool) or Out (communication directly from the model to the EDA tool). I would add InOut to this list, since there might be cases when the model needs an initial value which might be returned later as an optimized value, for example... Regarding model specific parameters with Format List, IBIS 5.0 defines that Format as selecting one value from a list of valid values. That's how the Format is defined, and the model developer depends on that definition in order to make sure that the user and EDA tool know how to form a correct input to the model. If the user or EDA tool were to assign their own interpretation to Format List, then the model developer would no longer be able to tell them that a valid input is one value from the list and not the entire list. Bob Ross points out that BIRD 132 enables a model developer to describe an array-type value as a valid input to a model. I haven't been following IBIS-ATM very closely for quite a while, so I appreciate his bringing me up to date. My point is that it is the model developer who defines the details required for a valid input to the model, in the context of the function signatures and syntaxes defined in IBIS 5.0. I hope this helps. Mike S. On 12/16/2011 08:51 PM, James Zhou wrote: 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