[ibis-macro] Re: Yet another problem with Usage Out
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 21 Dec 2011 02:43:25 +0000
Yep!
Arpad
========
From: James Zhou [mailto:james.zhou@xxxxxxxxxx]
Sent: Tuesday, December 20, 2011 6:16 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Yet another problem with Usage Out
Hi Apard,
By "the model can do that "internally" if necessary", you must be referring to
the **AMI_Memory_handle, which "shall be passed back during the AMI_GetWave
calls" "as is" under the variable name **AMI_memory.
Thanks,
James
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: Tuesday, December 20, 2011 3:58 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Yet another problem with Usage Out
James,
Once again, I will put my comments
between your lines in BOLD RED.
Thanks,
Arpad
===================================
From: James Zhou
[mailto:james.zhou@xxxxxxxxxx]<mailto:[mailto:james.zhou@xxxxxxxxxx]>
Sent: Tuesday, December 20, 2011 5:31 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Yet another problem with Usage Out
Arpad,
Your reply helps a great deal to clarify many of the issues I have on this
subject.
Regarding "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"
Is it true that the EDA tool has to pass the AMI_Init-returned
**AMI_parameters_out string to AMI_GetWave as an input variable
NO, the model can do that "internally" if necessary
and, AMI_GetWave returns it with a (possible) new value?
The AMI_parameters_out argument of AMI_Init and AMI_GetWave can return
different values for the same parameter, in fact multiple calls to the
AMI_GetWave function can also return a different value for each call
for the same parameter. Also, the address the model puts into these
arguments in the AMI_Init function and AMI_GetWave function doesn't
have to be the same.
If this is not true, it would be better to use different names for
**AMI_parameters_out in AMI_Init and AMI_GetWave. (It is true that variables
are local in c function definitions. Two variables having the same name in two
functions are programmatically independent of each other. But the fact that two
variables having the same name and referenced by pointer's pointer may lead to
interpretations that one is inherited from the other. It would help if this can
be explicitly clarified).
I fully agree with you that "something that doesn't make sense today might make
sense tomorrow". However that does not justify "weird unrealistic or even
erroneous models". As you have pointed out: "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".
If "There are all kinds of possibilities left open in the spec which might
result in weird unrealistic or even erroneous models", then, how could it
possible 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" ?
Let me try to illustrate this with a SPICE example:
Consider a resistor element. What should a SPICE
engine do if the user gives it a negative number?
Issue an error and stop? Take the sign off and
continue with the absolute value? Keep the sign and
continue with the negative value?
These are all questions which need to be answered in
a specification if this resistor element should be
portable among multiple SPICE simulators.
Let's assume that the specification says to keep the
sign and simulate with it as the user defines the value.
This eliminates the ambiguities in the spec, but doesn't
protect against user mistakes or intentional weirdnesses.
The spec's job is not to protect against bad content,
it is to make sure that the model definition is
unambiguous and therefore portable.
Thank you again for your comments and I will update the Q&A according to your
comments and send out to the reflector.
Best Regards,
James Zhou
QLogic Corp.
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: Monday, December 19, 2011 9:49 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Yet another problem with Usage Out
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]<mailto:[mailto:james.zhou@xxxxxxxxxx]>
Sent: Monday, December 19, 2011 9:42 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto: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
________________________________
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.
________________________________
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:
