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

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: <michael.mirmak@xxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Sat, 8 Feb 2014 10:06:32 -0500 (EST)

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