Walter,
Regarding “This BIRD is an attempt to limit what EDA tools can do with Model
Specific Out parameters”
no, that is not the goal of that BIRD draft...
Thanks,
Arpad
================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Wednesday, July 29, 2015 3:44 PM
To: curtis.clark@xxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: PAM4 Out parameters question from yesterday's meeting.
Curtis,
Good point. It is clear that the PAM4 Voltage Thresholds and Time Offsets need
to be used to evaluate the waveform output of the Rx AMI_GetWave. And the EDA
tool should anticipate that the values of these parameters may change each call
to Rx AMI_GetWave. So not only are they used to calculate simulation results,
but they are used to modify the inputs into the simulation models when doing
channel optimization.
There have been repeated attempts to limit what an EDA tool can do with the
outputs of AMI DLL’s. The following rule cannot be checked by the IBIS Parser,
and is unenforceable.
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.
I think that the following statement for Jitter and Noise parameters could be
useful:
The EDA tool may report the values of Jitter and Noise parameters (would need
to list them) returned by the AMI_GetWave function to the user. The model maker
should not require that these values 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.
The EDA tool may report the values of PAM4 Threshold and Offset parameters
(would need to list them) returned by the Rx AMI_GetWave function to the user.
The model maker should anticpate that these values be used by the EDA tool to
evaluate the waveform output of Rx AMI_GetWave function. The EDA tool can apply
these parameter outputs of each call to Rx AMI_GetWave to the waveform output
of that call to Rx AMI_GetWave, use the value of these parameter outputs from
the last call to the Rx AMI_GetWave or process and use the values of these
parameter outputs any way the EDA tool chooses.
We always have on the agenda:
15) Info, Out, InOut BIRD (Arpad)
- latest wording includes "in order to be compliant with this
specification, Model_Specific parameters ... must not ...",
and omits the word "simulation" so it's meaning doesn't have
to be defined
- questions/comments/discussion?
This BIRD is an attempt to limit what EDA tools can do with Model Specific Out
parameters from both AMI_Init and AMI_GetWave. Again, something that cannot be
checked by the parser nor is enforceable.
It is important that the model maker know what he expects the EDA tool to do
with the outputs of the model. There should be absolutely no constraints on
what an EDA tool actually does do with the outputs of a model.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Curtis Clark
Sent: Wednesday, July 29, 2015 2:54 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto: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.
