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.
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
This BIRD draft was written with respect to IBIS v5.0. The “Statement of
the Issue” section describes two problems. One is that the (v5.0)
specification
doesn’t say anything about which of the two IBIS functions returns the
parameter value (AMI_Init or AMI_GetWave or both) for any given Usage Out
or InOut parameter. The other problem that this BIRD draft addresses is
the usage Model_Specific Out or InOut parameters, in which case there is
no 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 have
been addressed. As far as I can tell, we do not have any InOut reserved
parameters, and all Out reserved parameters are well defined (although I
found a minor discrepancy which I will mention in the next Editorial
Meeting).
The section Curtis quoted is where this definition occurs, on pg. 205 is in
the introductory section for the jitter parameters. The rules are spelled
out clearly that the returned values are supposed to be returned in the
AMI_Init function’s AMI_parameters_out argument, and if the AMI_GetWAve
function returns any values, those “shall not be used by the EDA tool to
modify or
calculate parameter values passed into simulation models in subsequent
function calls or
simulations, 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 describe
which 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 the
PAM4 BIRD. 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.
Walter,
Regarding your response in the meeting yesterday that it is not the
responsibility of the IBIS specification to describe what the EDA tool
should or shouldn’t do, I can only agree with that partially. I agree
in the sense that we should specify for the tool how to solve any given
problem, whether to use convolution in TD or multiplication in FD, but
we do need to have clear rules on when to do what, or how to pass or
read model parameters so that that model maker and the EDA tool wouldn’t
end up doing/assuming totally different things and generate garbage as
a result. (Case in point, we do have AMI flows in the specification
for this very reason).
So I would like to request to clarify in the PAM4 section which of the
two AMI_parameters_out argument will/should be used by the AMI model to
return the values for the EDA tool.
Thanks,
Arpad
==========================================================================
*From:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:
ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Curtis Clark
*Sent:* Wednesday, July 29, 2015 1:54 PM
*To:* ibis-macro@xxxxxxxxxxxxx
*Subject:* [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 of
some PAM4 "Out" parameters. I believe he was wondering if the spec should
spell out what EDA tools are expected to do with Out parameter values if
they're returned with each GetWave() block.
I think the gist of your response was that the IBIS spec should define
what the model returns, not tell the tools what to do with it.
In section 10.5 (reserved AMI Jitter parameters), there's a Note that
might be relevant to Arpad's question. The entire Note is copied below, but
the last sentence in particular is:
The EDA tool may report the values returned by the AMI_GetWave function to
the user, but these values shall not be used by the EDA tool to modify or
calculate parameter values passed into simulation models in subsequent
function calls or simulations, or to modify or calculate the simulation
results in any way.
Obviously, PAM4 parameters and Jitter parameters are different. But
since they're all reserved parameters that the spec can fully define,
perhaps this language is relevant. The Jitter parameters provide some
precedent for the spec telling the tool what to do (or what not to do) with
Out parameter values. Just wondering if you think that's relevant to
Arpad's PAM4 parameters question?
Thanks,
Curtis
Note:
If the Jitter and Noise parameters are Usage Info, the EDA tool shall
obtain their values from the AMI parameter (.ami) file, optionally through
a user interface if user selections are available or needed.
If these parameters are Usage Out, the EDA tool shall use the values
returned by the AMI_Init function. It is the model maker’s responsibility
to make sure that the AMI_Init function returns the appropriate value in
these parameters to the EDA tool to achieve successful simulations.
The model’s AMI_GetWave function may also return values in these
parameters to the EDA tool, and these values are not required to be the
same as the values previously returned by the AMI_Init function. The EDA
tool may report the values returned by the AMI_GetWave function to the
user, but these values shall not be used by the EDA tool to modify or
calculate parameter values passed into simulation models in subsequent
function calls or simulations, or to modify or calculate the simulation
results in any way.