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

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: <wkatz@xxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 11 Feb 2014 08:27:44 -0500 (EST)

MM,

 

By far the best solution is to use Model Selector. The Pin model name
could be TxRx, and it would have a Model Selector for models Tx and Rx,
and models TX and Rx would have their own .ami files and .dll's. This is
no change to IBIS documentation, but could be part of an AMI cookbook.

 

Walter

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Monday, February 10, 2014 5:57 PM
To: Arpad_Muranyi@xxxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: AMI and direction, for single-ended buffers

 

MM,

 

What I would suggest is:

 

        (AMI_Type (Usage Info) (Type String) (Value "I/O") 

            (Description "Valid options are I/O, Tx and Rx "))

        (AMI_State (Usage In) (Type String) (List "Tx" "Rx") 

            (Description "Valid options are Tx and Rx"))

 

I certainly would limit simulations to one directional. I would not want
to think of the flow complications of turning the bus around. Is there
something important about the details of what happens when one I/O stops
driving and the other I/O starts driving?

 

Walter

 

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

 

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] 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] On Behalf Of Walter Katz
Sent: Saturday, February 08, 2014 9:07 AM
To: 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
OpalT, 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] On Behalf Of Mirmak, Michael
Sent: Saturday, February 08, 2014 12:53 AM
To: IBIS-ATM (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:

  1. Home
  2. ibis-macro
  3. Archive
  4. 02-2014