[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 17:37:57 +0000

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

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