[ibis-macro] Re: Usage Out syntax rules

  • From: James Zhou <james.zhou@xxxxxxxxxx>
  • To: "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 16 Dec 2011 16:53:44 -0800

Arpad,

The statements in BIRD 127.4 (as quoted in your email)  appear to be 
inconsistent:  the first paragraph states that  only Usage In and InOut 
parameters should be included in the string and "No other information may be 
included in this string". The second paragraph states that,  the string must 
contain Usage Out AMI parameters "if there are any defined in the .ami file". 
If the Usage Out parameters are prohibited from being passed by 
*AMI_parameters_in into AMI_Init, the only way AMI_Init could find out "if 
there are any defined in the .ami file" is to parse the .ami file directly. Is 
this what's implied by the Specification?  If Usage Out parameters are not 
allowed to be passed to AMI_Init or AMI_GetWave, why include them in the .ami 
file (since Usage Out is designed to pass parameters  from AMI_Init or 
AMI_GetWave to EDA tools) ? If a parameter is merely passed from model creator 
to EDA tool/user, it should be Usage Info.

Also, with respect to Usage Out parameters, the Specification does not seem to 
distinguish between AMI_Init-returned Usage Out or, AMI_GetWave-returned Usage 
Out. However, AMI_Init-returned Usage Out parameters can be processed by both 
AMI_GetWave and/or EDA tool; AMI_GetWave-returned Usage Out parameters can be 
processed only by EDA tool (if it is processed at all). The Specification 
should clarify what EDA tool operations are required/allowed to process 
**AMI_parameters_out returned by AMI_Init and AMI_GetWave.

When looking at all reserved parameters defined by IBIS 5.0 and Bird 123, I 
found six of them that are either Info or Out: Ignore_Bits, TX_Jitter, Tx_DCD, 
Rx_Receiver_Sensitivity, Rx_Clock_PDF, Rx_Noise. Please let  me know if any are 
missing from this list. All other reserved parameters are Usage Info.  I also 
do not see any Usage In and InOut parameters. As described in previous emails 
between you and Mike, existing models may overwrite some of these values 
provided by .ami and return them with **AMI_parameters_out string. In this 
case, we do have a situation of logical contention as you have pointed out in 
earlier emails. As a user of these models, I would think that it is highly 
undesirable to have models that have inconsistent parameter values (between 
.ami and **AMI_parameters_out returned by AMI_Init or AMI_GetWave) and the 
Specification allows the EDA tools to pick any one without clear decision 
criteria defined in the Specification.

The answer (or insight) to the following question should help us to better 
understand the issue of parameter contention between .ami and 
**AMI_parameters_out: what are the reasons/justifications that models could 
have different values in .ami and **AMI_parameters_out, for the same reserved 
parameter?

Thanks,
James Zhou




From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Muranyi, Arpad
Sent: Thursday, December 15, 2011 9:40 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Usage Out syntax rules

Radek,

Thanks for your comments.  I went back to BIRD 127.4
and found the following, related to this discussion
and your comments:


|*              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.  The string must always include the root name of
|**             the parameter tree, even if there are no parameters to pass
|**             to the algorithmic model.
|*
|*              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.  The string must always include the root name of
|**             the parameter tree, even if there are no parameters to return
|**             to the EDA tool.
|*
|*              For Usage In, the value in the "AMI Parameter" leaves are
|*              determined by the EDA tool based on the "AMI Parameter"
|*              branches in the .ami file.  For Usage Out, the value in the
|*              "AMI Parameter" leaves are determined by the Algorithmic
|*              Model.  For Usage InOut, the value in the "AMI Parameter"
|*              leaves are first determined by the EDA tool based on the
|*              "AMI Parameter" branches in the .ami file and passed into
|*              the Algorithmic Model which may return a new value in the
|*              "AMI Parameter" leaves after some processing.

These paragraphs define what the content of the
AMI_parameters_in/out strings should be and how
the values are determined (tool or model), but I
couldn't find anything about how the values are
to be used (tool or model).  So, the answer to
our question:

"If we did not explicitly state that the EDA platform is to use the values
returned by the model (which is sort of obvious) we should add it."

is that we unfortunately didn't state that.  This is why
"Then, in the context of the Out parameters, there is no issue of Default 
values..."
is false, i.e. we have an issue.  This is what I was trying
to solve with this new BIRD draft, but it seems that Bob and
Mike S. question that there is an issue.  I would very much
like to hear the opinion of the rest of our team on this.
Do we have an issue, or not?

Regarding your question on
"Since the AMI_parameters_out string can be passed from both AMI_Init()
and AMI_GetWave() functions, do we have clear rules and exceptions for
AMI_GetWave() to be allowed or not to override the values set by AMI_Init()?"

the draft BIRD which is still pending:

http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20110613/arpadmuranyi/Out-InOut%20BIRD%20draft%2010/Out_InOut_BIRD_10.pdf

contains the following text:

| Note: Algorithmic models may return (Usage Out) or (Usage InOut)
| parameters in the AMI_parameters_out argument of either the AMI_Init
| or the AMI_GetWave function, or both.

but we don't say more about when and how the EDA tool should
use them, because this will most likely depend on the nature
of the parameter itself and it would be hard to establish a
general rule.  I would expect that for Reserved parameters
this would be described independently for each parameter.  On
the other hand, for Model_Specific parameters, the same
document states the following:

| EDA tool vendors are strongly encouraged to collect the information from
| Model_Specific parameters of (Usage Out), (Usage InOut) and/or (Usage Info)
| in a database and make it available to the user. Since each call to the
| AMI_GetWave function may return a unique value in the AMI_parameters_out
| argument, EDA tool vendors are encouraged to build a database in which the
| parameters and values obtained from each AMI_GetWave call are organized in
| rows and columns so that the user can view them conveniently. Information
| from the .ami parameter file or information returned through the
| AMI_parameters_out argument of the AMI_Init function may be treated as the
| first data point of a data series returned by the AMI_parameters_out
| argument of the AMI_GetWave function for matching parameter names.  . . .

which seems to address your concern.

Questions, comments, suggestions are welcome.

Thanks,

Arpad
===============================================


From: radek_biernacki@xxxxxxxxxxx [mailto:radek_biernacki@xxxxxxxxxxx]
Sent: Thursday, December 15, 2011 6:24 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Usage Out syntax rules

Hi Arpad,

As I recall it, we have made it very clear in recently accepted BIRD 127.4 that 
the model must return values for all the parameters InOut and Out using the 
AMI_parameters_out string. If we did not explicitly state that the EDA platform 
is to use the values returned by the model (which is sort of obvious) we should 
add it. Then, in the context of the Out parameters, there is no issue of 
Default values since any values defined in the *.ami file will be effectively 
ignored (replaced). Therefore any values specified in the *.ami file for the 
Out parameters serve only as placeholders.

Of course, in the case of InOut and Out parameters within the "Model_Specific" 
branch - as long as we do not disallow it - the EDA platform must not use the 
returned values to affect the simulation. That was extensively discussed in the 
past but, I believe, has not been finalized.

For the "Reserved_Parameters" branch one more issue may need clarification. 
Since the AMI_parameters_out string can be passed from both AMI_Init() and 
AMI_GetWave() functions, do we have clear rules and exceptions for 
AMI_GetWave() to be allowed or not to override the values set by AMI_Init()? 
Alternatively the rules can be set for the EDA platforms. I do not recall it, 
but perhaps this has already been addressed.

Radek

________________________________
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:

  1. Home
  2. ibis-macro
  3. Archive
  4. 12-2011