[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 05:48:54 +0000
James,
Thanks for putting so much work into the Word document.
Here are some of my more important reactions:
"What is the meaning of "and" in "Usage Info and Out"?"
This should be an "or". The spec simply doesn't allow
for one parameter to be declared as more than one Usage
type in the .ami file. BIRD 127.4 states that:
... Multiple leaves
|* containing the same reserved word are not allowed within an
|* AMI Parameter branch.
Where "reserved word" serves as a general term for Type,
Usage, Description, Default. (This is not rigorously
defined, but implies from the text).
Regarding "IBIS Specification implies that any Usage Info or Out parameters
contained in the *AMI_parameters_in string would be ignored by AMI_Init"
this is not just by implication, the rules are spelled out in
BIRD 127.4:
|* The EDA tool must pass a string to the AMI executable model
|** through the AMI_parameters_in argument. This string must
|** contain all of the leaf/value pair formatted Usage In and
|** Usage InOut AMI parameters if there are any defined in the
|** .ami file. No other information may be included in this
|** string.
Similar rules are defined for how the AMI model should
formulate the return values:
|* The AMI executable model must return a string to the EDA tool
|** through the AMI_parameters_out argument. This string must
|** contain all of the leaf/value pair formatted Usage InOut and
|** Usage Out AMI parameters if there are any defined in the
|** .ami file. No other information may be included in this
|** string.
Regarding: "The Specification should clarify how many values are allowed and
accepted by the AMI_Init function."
I think the text in BIRD 127.4 is clear on this, one value/leaf
pair per parameter, except Table which is described in BIRD 132.
Regarding: "These rules also imply that AMI_Init ignores any Usage Info and Out
parameters (reserved or model-specific) contained in the *AMI_parameters_in
string. "
again, nothing needs to be implied, I think it is spelled out
clearly in BIRD 127.4 that Info and Out parameters are not
included in the AMI_parameters_in string.
Regarding: "Please note that none of the reserved parameters are of Usage
InOut."
while this may be the case today in practice, there are
no prohibitions in the spec which prevents this. It is
perfectly legal to pass Reserved InOut parameters to the
AMI model, we just didn't create such parameters in the
specification yet.
Regarding: "...the only way to process and use these reserved parameters of
Usage Out is to retrieve them for use by EDA tools and remove them from the
string, which is to be later passed to AMI_GetWave.",
I have a few bones to pick on this one. It is correct
that the EDA tool retrieves these parameters from the
AMI_parameters_out string, but "removal" is not necessary,
and it is not possible for the EDA tool to pass these
to the GetWave function, because the GetWave function
doesn't have a parameters_in argument. The question is
more whether the EDA tool should look for these return
values in the Init or the GetWave function's AMI_parameters_out
string, but since Reserved parameters must be fully described
in the spec, the description of the parameter in the spec
will hopefully explain that for each Reserve Usage Out
parameter.
Regarding: "what to do with Usage InOut our Out model-specific parameters in
**AMI_parameters_out?"
I think this is well defined. Model_Specific InOut parameters
are passed into the AMI model by the EDA tool just like Usage
In parameters are, and when the AMI model returns the value,
they will be "processed" by the EDA tool just like Model_Specific
Usage Out parameters are, i.e. can't be used to alter the tool's
actions, only displayed to the user or saved in a log file.
Regarding: "What is contained in **AMI_parameters_out string returned by
AMI_GetWave and how should it be processed?"
I think BIRD 127.4 defines this clearly, as I showed it
above. Nothing but leaf/value pairs are contained in the
AMI_parameters_out string (in addition to the root name).
It seem that the last two "Cases" you wrote are a repeat
of the previous ones, but it might be late for me to get
the intent of these...
I hope this feedback will help your understanding of some
of these nuances.
In general, I would like to caution you (and myself too) to
one thing. It is easy to get bogged down in deep logic
exercises concerning the validity of the different rules,
and definitions in the spec. There are all kinds of possibilities
left open in the spec which might result in weird unrealistic
or even erroneous models, simply because the spec allows it
to happen. Our goal should not be to close such open doors,
because we never know when something that doesn't make sense
today might make sense tomorrow. On the other hand, we should
strive to make the spec unambiguous, so that the assumptions
and expectations are the same among model makers and EDA tool
vendors in order to ensure interoperability and portability.
It is sometimes hard to distinguish between these two, but
that's why we work as a committee, to keep each other on
the right tracks...
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.
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.
Thanks,
James Zhou
Other related posts:
