[ibis-macro] Re: Yet another problem with Usage Out

A couple of comments added below in RED BOLD.


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


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:

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.

James Zhou

Other related posts: