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

  • From: Bob Miller <bob.miller@xxxxxxxxxxxxx>
  • To: Arpad_Muranyi@xxxxxxxxxx
  • Date: Wed, 29 Jul 2015 15:10:49 -0600


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>
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



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.

Other related posts: