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

  • From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
  • To: "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 10 Feb 2014 19:01:36 +0000

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

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