[ibis-macro] Re: Usage Out syntax rules

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 19 Dec 2011 05:51:39 +0000

James,

You are raising an interesting question.  However, don't
forget that the .ami file and the model code is authored
by the same person (or at least the same company).  Therefore
the algorithmic model (DLL) doesn't have to read the content
of the .ami file to find out what the Usage Out parameters
are.  So there is no need for these parameters to be passed
to the executable model, or for the model to parser the .ami
file.  The only requirement is that the model maker should
be consistent with their executable model and their .ami
file.

Regarding:
"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) ?"
The parameter has to be defined in the .ami file so that the
EDA tool can find out about it and look for it in the AMI_parameters_out
string.  But as far as supplying a value with these, I fully
agree with your observation that the <data> either shouldn't be
there in the .ami file, or the spec should say something about
having to ignore it.  I am concerned that if we don't do this,
people might read into things and start using it for unintended
purposes (as this thread uncovered some differences of opinion
about Default), creating incompatibilities between models and
EDA tools.

Regarding
"the Specification does not seem to distinguish between AMI_Init-returned Usage
Out or, AMI_GetWave-returned Usage Out",  you are absolutely correct,
and we started addressing that in a BIRD draft, which is still
in the draft stage:

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

The solution we are thinking of implementing is that for Model_Specific
parameters these would only be allowed to be used for display, or
logging purposes in the EDA tool, and for Reserved parameters the
parameter definition and description in the spec will have to give
full detail on which function returns them and how they shall be
treated by the EDA tool.  The reason I started "fussing" about the
jitter BIRD and Usage Out is because I didn't think that the description
was adequate for them regarding Usage Out and felt that it either needed
to be discussed in more detail in the BIRD 123 or elsewhere in the
spec.  That's what started this thread.

I think you are correct about the list of the parameters.  We will have
to check out "Ignore_Bits" in this context to see if there is enough
detail in its description, or if we write some text in a general location
as I proposed, to make sure that it doesn't cause any conflicts.  I think
our decision last time was to remove Usage Out from the BIRD 123 jitter
parameters, so that problem will go away.

You are making a very good suggestion with saying:
"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?"

I can think of two possible reasons, optimization and/or initialization,
but both of these could/should really be done using InOut parameters,
not Out.  This thread uncovered at least two interpretations for how
"Default" supposed to be interpreted, and depending on the outcome,
we might get a different answer to the above question...

Thanks,

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







From: James Zhou [mailto:james.zhou@xxxxxxxxxx]
Sent: Friday, December 16, 2011 6:54 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Usage Out syntax rules

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

Other related posts: