[ibis-macro] Re: Yet another problem with Usage Out
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 20 Dec 2011 04:32:46 +0000
James,
I will put some answers after your questions in RED BOLD.
There is a lot of stuff in your attached Word document,
and I will try to reply to that in a separate email.
Thanks,
Arpad
===========================================================
From: James Zhou [mailto:james.zhou@xxxxxxxxxx]
Sent: Monday, December 19, 2011 9:42 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Yet another problem with Usage Out
Mike,
Thanks for your reply. I use the attached document to track some of the issues
related to AMI parameter definitions. Any comments, corrections, feedbacks are
appreciated.
Regarding Format List, I found the following lines in IBIS 5.0 (and 127.4):
| Format: (default is range)
......
| List <typ value> <value> <value> <value> ... <value>
However I couldn't find any statements in IBIS 5.0 that would suggest "IBIS 5.0
defines that Format as selecting one value from a list of valid values". If the
intention of the Specification is to let the user select a single value from
the list, it would help to clarify it in the Specification.
There is some text on that in BIRD 127.4:
|* The EDA tool must process the content of the .ami file so that
|* 1) the 'Reserved_Parameters' and 'Model_Specific' branch
|* names and their associated open and close parentheses "()"
|* are not included in the AMI_parameters_in string, and
|* 2) the AMI Parameter branches with Usage In or Usage InOut
|* are converted to leaf/value pairs for the AMI_parameters_in
|* string, possibly incorporating user selections. In this
|* conversion each AMI parameter branch name becomes a leaf
|* name in the AMI_parameters_in string and each leaf name
|* is followed by a white space, a value and a closing
|* parentheses ")".
Note that there is no mention here about what Format this
applies to, because it is assumed that any multi-valued
Format (Range, List, Increment, Corner, Steps) are reduced
to a single value by "possibly incorporating user selections",
notice the last sentence says: "leaf name is followed by a
white space, a value" where value is in singular. Similar
rules apply to the string returned by the model for Usage
Out and InOut parameters. There are other rules about what
should happen if the user is not making any selections:
Also, BIRD 127.4 states:
| Default <value>:
|* Default and Value are mutually exclusive, and must not be used together
|* for the same parameter. Default is not allowed for Table, Gaussian,
|* Dual-Dirac and DjRj. Default is optional for Range, List, Corner,
|* Increment and Steps. If a Default <value> is specified, its value must
|* have the same Type as the parameter. For example, if Type is Boolean,
|* <value> must be either True or False, if Type is Integer, <value> must
|* be an integer. Also, if Default is specified, <value> must be a member
|* of the set of allowed values of the parameter. If Default is not
|* specified, the default value of the parameters will be the <typ> value.
Note the logic here leaves no way for multi-valued
parameters to not get reduced to a single value. This
is either achieved by Default, or in its absence the
rule that it will be the <typ> value that is selected
from the possible values.
In case you wonder, format Corner is a different animal,
so much so that it got its own BIRD, # 140.2
http://www.eda.org/pub/ibis/birds/bird140.2.txt
but this parameter type will also be reduced to a single
value based on the IBIS corner selected in the simulator.
Similarly, Format Range, Corner, Increment, Steps and Table all are
multi-valued. I think the Specification should clarify, if it hasn't already,
how these parameters should be passed to to AMI_Init.
I hope the above satisfies your request.
Thanks,
James Zhou
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
On Behalf Of Muranyi, Arpad
Sent: Sunday, December 18, 2011 10:13 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Yet another problem with Usage Out
A couple of comments added below in RED BOLD.
Arpad
==============================================
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[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<mailto: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
________________________________
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.
Other related posts:
