[ibis-macro] Re: AMI and direction, for single-ended buffers

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 10 Feb 2014 20:18:57 +0000

Mike,

Currently the AMI parameters are static, i.e. they can't be
changed during the time the AMI models are executed (running).
This is because the arguments are passed into the AMI functions
only once, at the time when the function is called.

So, for AMI_Init, which is called (executed) once for each AMI
run, the EDA tool gets one and only one opportunity to pass
arguments.  The AMI_GetWave is a little different, because it
can be called multiple times by the EDA tool, and the EDA tool
can pass new values at each call.  But looking at the arguments,
you will see that AMI_GetWave doesn't have "*AMI_parameters_in"
which is what you would need to pass AMI parameters into the
AMI models.

So the bottom line is that the AMI parameters (from the .ami file)
can only be passed into the AMI executable model once.

There is, however, a BIRD which might change this situation.
In connection with the Back Channel simulations, there is a need
to pass AMI parameter arguments to AMI_GetWave too.  The reason
for that is because the adaptive algorithms are time variant stuff,
so it must be modeled in AMI_GetWave, and during the training
cycle the Rx needs to be able to the Tx how to adapt itself to
the channel's characteristics, i.e. send AMI parameter values
to AMI_GetWave.

http://www.eda.org/ibis/birds/bird128.txt

BIRD 128 proposes to turn the "**AMI_parameters_out" argument
of AMI_GetWave into a bi-directional argument, so that it could
take in parameters also instead of just output them.

Whether this is the correct way to solve this need has yet to
be determined in the ATM meetings, but there is clearly a need
for this capability.

The other question is whether this input mechanism will be allowed
only during the training cycle of Back Channel simulations, or
for any AMI simulation type.

I hope this answers your questions on how AMI parameters are
passed into the IBIS AMI executable models.

Your suggestion about the reserved parameters for determining the
model type looks good, but I have a question.  These parameters would
tell the AMI executable models what their direction should be (if
they can be configured that way).  But would there be a need for
knowing this on the [Model] keyword level?

For example, if there is a [Model] which is I/O, how would the EDA
tool know whether to run this as an input or output, and how would
this be matched with the AMI reserved parameter?  I know, the tool
could read the .ami file to find out, but would there be some
situations when this is not feasible, or reliable?  I don't know
the answers, I am just thinking out loud...

Thanks,

Arpad
====================================================================

From: Mirmak, Michael [mailto:michael.mirmak@xxxxxxxxx]
Sent: Monday, February 10, 2014 1:02 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: AMI and direction, for single-ended buffers

Arpad,

Thanks!  This helps confirm what we are seeing.

One question: can the states of Reserved Parameters be altered by the tool in 
the middle of a simulation per the specification?  I am assuming so, but wanted 
to confirm.

For true I/O support (targeting single-ended buffers), my thinking is that two 
new Reserved Parameters could be defined, as follows:
        (AMI_Type (Usage Info) (Type String) (Value "I/O") (Description "Valid 
options are I/O, Tx Only and Rx Only"))
        (AMI_State (Usage In) (Type String) (Value "Rx") (Description "Valid 
options are Tx and Rx"))

The specifics are negotiable.  But in this case, the buffer is an I/O and acts 
receiver at the start of analysis.  If needed, the direction could "flip" to 
TX, even in the middle of simulation, and the associated model files should be 
able to cope. Some consistency rules would be needed, and both would be 
required if I/O were set for the Type.  If these parameters ended up passed in 
some form from the tool to the model, then a single AMI parameter file and DLL 
could be maintained for an I/O that handles both TX and RX functions.

Of course, this raises a backward-compatibility issue: for 6.0, how does the 
tool know what direction a given buffer's AMI/DLL files are supposed to support?


-          MM

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, February 10, 2014 9:38 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: AMI and direction, for single-ended buffers

Mike,

Please look at BIRD 148:

http://www.eda.org/ibis/birds/bird148.txt

especially the "Any other background information" section on
the bottom.  We discussed these issues when this BIRD was
developed, and it seems that we fixed the bigger part of the
problem but didn't address all of it, even though we knew
about it...

If this is a problem, we can certainly continue where we left
off...

Thanks,

Arpad
================================================================

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Saturday, February 08, 2014 9:07 AM
To: michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>; IBIS-ATM
Subject: [ibis-macro] Re: AMI and direction, for single-ended buffers

MM,

We chose to require that the analog buffer part of a model be in the .ibs file, 
and the algorithmic part be in the .ami file, so we are required to have 
pointers from the .ibs file to the .ami and .dll files. We could easily have 
put into the .ami files pointers to analog models (Touchstone File, IBIS-ISS 
subckts, or Thevenin equivalent models) as proposed in Opal(tm), but this was 
rejected by the IBIS Open Forum.

I have never seen a SerDes I/O buffer model, although one is certainly 
possible, but unlikely. I would wait until some IC Vendors comes forward and 
requests that IBIS-AMI be enhanced to handle I/O buffers before we invest time 
in handling this be either allowing two DLL's for such a model, or adding 
Reserved Parameters to control the DLL for either Input or Output operations.

There certainly can be an application for applying AMI technology for 
single-ended channels. DDR3 derating is a case in point, where the waveform at 
the input to an Rx needs to be massaged to determine the actual Rx transition 
time, but I would not hold my breath for such a requirement and demand by the 
industry. The industry has been driven by the need to confirm compliance by 
measurements at either the pin or pad of an Rx, and the industry reluctantly 
was forced to an AMI methodology because measurement at the pin or pad became 
both unfeasible or not sufficient to determine the performance of a channel.

Walter

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Saturday, February 08, 2014 12:53 AM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>)
Subject: [ibis-macro] AMI and direction, for single-ended buffers

Imagine that you have a set of AMI files and an IBIS file for a device 
containing exactly one transmitter and one receiver.  However due to file 
corruption and some missing documentation, the [Algorithmic Keyword] pairs are 
missing the DLL and AMI parameter file names - you don't know which files are 
associated with the transmitter and which are for the receiver.

Would you have any way to find out, other than experimenting with the files in 
an EDA tool?

Reading the specification, the text clearly assumes that AMI files have a 
"direction" - either input or output, based on the frequent references to TX 
and RX.  Further, this would imply that Input and Output (and their variants) 
are the only expected Model_types.

Yet the specification only prohibits the use of Model_types Series, 
Series_Switch, and Terminator with AMI models.  I/O and its variants are not 
prohibited.

So what if one wants to use AMI techniques for single-ended models, which is 
explicitly allowed by the specification?  Single-ended interfaces today are 
more likely to be bi-directional.

If you actually associated Model_type I/O with AMI information, there's no 
obvious way to identify to the tool (or the user) outside of a Model Specific 
parameter or tool-specific setting the current direction of the model, or 
whether the AMI file is capable of bi-directional operation at all.  The flows 
assume unidirectional operation or an unambiguous identification of the TX and 
RX in any given situation.

Do we need to prohibit I/O Model_types with [Algorithmic Model]?  Or, probably 
more usefully, do we need to define a Reserved Parameter for AMI that 
identifies directionality both for the AMI file as a whole, as well as its 
current state if it is an I/O?


-          MM

Other related posts: