[ibis-macro] Re: PAM4 Out parameters question from yesterday's meeting.

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: <curtis.clark@xxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 29 Jul 2015 16:43:47 -0400 (EDT)

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] On Behalf Of Curtis Clark
Sent: Wednesday, July 29, 2015 2: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.

Other related posts: