Bob,
On Page 194:
The executable model shall return a string to the EDA tool through the
AMI_parameters_out argument. This string shall contain all of the leaf
formatted Usage InOut and Usage Out AMI parameters if there are any defined
in the parameter definition file. No other information may be included in
this string. The string shall always include the root name of the parameter
tree, even if there are no parameters to return to the EDA tool.
This does not distinguish between AMI_parameters_out from the AMI_Init call
or the AMI_GetWave call. Thus, if any parameter (e.g. PAM4_UpperThreshold)
is Usage Out or InOut, the DLL must return a value for it from AMI_Init and
every call to AMI_GetWave.
So if you want the EDA tool to always use the value from AMI_Init, then you
should output that value from each call to AMI_GetWave. If you only want to
use the values from AMI_GetWave, then one cannot do any AMI_Init processing
at all.
We can always remove the requirement that the model define the upper and
lower threshold, or if the upper or lower threshold is returned 0.0, then
the EDA tool would be forced to calculate it on its own.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Miller
Sent: Wednesday, July 29, 2015 5:11 PM
To: Arpad_Muranyi@xxxxxxxxxx
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: PAM4 Out parameters question from yesterday's
meeting.
The PAM4 BIRD doesn’t say anything about which of the two
AMI_parameters_out argument will be used to return the threshold and
offset values. We need to spell out that rule. It can be returned in
either the AMI_Init or AMI_GetWave, or both functions, but this needs to
be stated. The EDA tool needs to know where to look for these values and
when.
This issue as I see it is dependent on the modeler's intent and the way
tuning is done in the model (In AMI_Init versus AMI_GetWave or even both).
From my own parochial perspective, I would assume that if the executable
returns values for threshold/offset in parameters_out, whenever it is
returned, these are intended to be the operational settings from this point
forward in all calculations by the EDA tool until modified again by a
subsequent call to the executable. I realize this may cause some
head-scratching on the part of EDA suppliers as to how accumulated metrics
(i.e in GetWave) should account for changing parameters, but I would regard
this as the most general solution that doesn't cause the issue to devolve
into using PAM4 to disallow certain existing model structures (e.g. "dual
mode" or "tuning-in-GetWave", etc.).
"Last-returned-parameter-wins" seems to me to allow the model maker to more
effectively control his own destiny as to how the EDA tool will ultimately
present his model to the user.
Regards,
Bob
On Wed, Jul 29, 2015 at 2:34 PM, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx> > wrote:
Curtis,
Thanks for sheading some light on my concern. Since I had an AR from
the meeting to check into the validity of the Out/InOut BIRD draft after
all these years, I can add a little more to the “problem description”
of the question I raised in the last ATM meeting.
The latest version of the BIRD draft regarding Usage Out/InOut is v10,
and it is posted on the IBIS-ATM website:
<http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20110613/arpadmuranyi/Out-InOut%20BIRD%20draft%2010/Out_InOut_BIRD_10.pdf>http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20110613/arpadmuranyi/Out-InOut%20BIRD%20draft%2010/Out_InOut_BIRD_10.pdfThis
BIRD draft was written with respect to IBIS v5.0. The “Statement ofthe Issue”
section describes two problems. One is that the (v5.0)specificationdoesn’t say
anything about which of the two IBIS functions returns theparameter value
(AMI_Init or AMI_GetWave or both) for any given Usage Outor InOut parameter.
The other problem that this BIRD draft addresses isthe usage Model_Specific Out
or InOut parameters, in which case there isno way to know what the EDA tool
should do with the returned values.I checked the IBIS v6.0 specification and
the first problem seems to havebeen addressed. As far as I can tell, we do not
have any InOut reservedparameters, and all Out reserved parameters are well
defined (although Ifound a
minor d
iscrepancy which I will mention in the next EditorialMeeting).The section
Curtis quoted is where this definition occurs, on pg. 205 is inthe introductory
section for the jitter parameters. The rules are spelledout clearly that the
returned values are supposed to be returned in theAMI_Init function’s
AMI_parameters_out argument, and if the AMI_GetWAvefunction returns any values,
those “shall not be used by the EDA tool tomodify orcalculate parameter values
passed into simulation models in subsequentfunction calls orsimulations, or to
modify or calculate the simulation results in any way”.It seems that when we
wrote IBIS v6.0, we remembered the need to describewhich if the two
AMI_parameters_out argument is used for the Out (or InOut)parameters, but it
seems that we are starting to forget that need in thePAM4 BIRD. The PAM4 BIRD
doesn’t say anything about which of the twoAMI_parameters_out argument will be
used to return the threshold andoffset values. We need to sp
ell out
that rule. It can be returned ineither the AMI_Init or AMI_GetWave, or both
functions, but this needs tobe stated. The EDA tool needs to know where to
look for these values andwhen.Walter,Regarding your response in the meeting
yesterday that it is not theresponsibility of the IBIS specification to
describe what the EDA toolshould or shouldn’t do, I can only agree with that
partially. I agreein the sense that we should specify for the tool how to
solve any givenproblem, whether to use convolution in TD or multiplication in
FD, butwe do need to have clear rules on when to do what, or how to pass orread
model parameters so that that model maker and the EDA tool wouldn’tend up
doing/assuming totally different things and generate garbage asa result. (Case
in point, we do have AMI flows in the specificationfor this very reason).So I
would like to request to clarify in the PAM4 section which of thetwo
AMI_parameters_out argument will/should be used by the AMI model toreturn
the val
ues for the EDA
tool.Thanks,Arpad==========================================================================From:
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx] OnBehalf Of Curtis ClarkSent: Wednesday, July
29, 2015 1:54 PMTo: <mailto:ibis-macro@xxxxxxxxxxxxx>
ibis-macro@freelists.orgSubject: [ibis-macro] PAM4 Out parameters question from
yesterday's meeting.Hi Walter,In yesterday's ATM meeting, Arpad asked a
question about EDA tools' use ofsome PAM4 "Out" parameters. I believe he was
wondering if the spec shouldspell out what EDA tools are expected to do with
Out parameter values ifthey're returned with each GetWave() block.I think the
gist of your response was that the IBIS spec should define whatthe model
returns, not tell the tools what to do with it.In section 10.5 (reserved AMI
Jitter parameters), there's a Note that mightbe relevant to Arpad's question.
The ent
ire Note
is copied below, but thelast sentence in particular is:The EDA tool may
report the values returned by the AMI_GetWave function tothe user, but these
values shall not be used by the EDA tool to modify orcalculate parameter values
passed into simulation models in subsequentfunction calls or simulations, or to
modify or calculate the simulationresults in any way.Obviously, PAM4 parameters
and Jitter parameters are different. But sincethey're all reserved parameters
that the spec can fully define, perhaps thislanguage is relevant. The Jitter
parameters provide some precedent for thespec telling the tool what to do (or
what not to do) with Out parametervalues. Just wondering if you think that's
relevant to Arpad's PAM4parameters question?Thanks,CurtisNote:If the Jitter and
Noise parameters are Usage Info, the EDA tool shall obtaintheir values from the
AMI parameter (.ami) file, optionally through a userinterface if user
selections are available or needed.If these parameters a
re Usage
Out, the EDA tool shall use the valuesreturned by the AMI_Init function. It
is the model maker’s responsibilityto make sure that the AMI_Init function
returns the appropriate value inthese parameters to the EDA tool to achieve
successful simulations.The model’s AMI_GetWave function may also return values
in these parametersto the EDA tool, and these values are not required to be the
same as thevalues previously returned by the AMI_Init function. The EDA tool
mayreport the values returned by the AMI_GetWave function to the user, butthese
values shall not be used by the EDA tool to modify or calculateparameter values
passed into simulation models in subsequent function callsor simulations, or to
modify or calculate the simulation results in any way.
