Updated October 19, 2012: A couple of people asked for a clarification about what combinations of Channel Simulator mode with the four model flags were valid, and what happened in each of the 32 cases. I made a table a placed it here: IBIS 5.1 32 AMI combinations. Please refer to IBIS 5.1 for the case where you add in crosstalk transmitters…
Why IBIS AMI isn’t like a sandwich
(Photo credit: Wikimedia Foundation/http://pdphoto.org/public domain)
On August 24, 2012, after four long hard years in the making, the IBIS Open Forum approved IBIS 5.1 which supersedes IBIS 5.0 approved in August 2008.
Version 5.1 doesn’t add many new capabilities but it does clarify the AMI flow that was added to IBIS in version 5.0. I have to admit I have a love/hate relationship with the AMI flow. “Love” because it lets you generate ultralow BER contours (10−18 or lower if you need them) in seconds not hours. “Hate” because, even with the simplifications of version 5.1, it is so fiendishly complicated for my poor brain to understand.
My colleague Fangyi Rao and I have written a white paper Explore the SERDES design space using the IBIS AMI channel simulation flow that attempts to reveal some of the mysteries. Our method in writing it was for me to ask lots of dumb questions, and Fangyi to patiently answer them.
Here are my personal “Top four frustrations that motivated me to write the paper.” I offer them not out of criticism of the hard work of the folks like Fangyi who are volunteers to the IBIS Open Forum, but in the spirit of helping others overcome some of the misunderstandings that have tripped me up. Plus an expert told me that “writing with conflict” will attract more readers and comments to my blog!
1. The name of AMI_Init belies its real purpose
My first exposure to AMI was in 2007 when I was at MathWorks. One of the architects behind it came to my office and showed me the three C-callable functions in the API: AMI_Init, AMI_GetWave, AMI_Close. I naturally assumed that it was like a sandwich. AMI_Init “bread” allocated memory, AMI_Close “bread” deallocated memory, and that AMI_GetWave was the meat. No, it turns out that AMI_GetWave is in fact optional! What kind of sandwich has an option filling? After much confusion I learnt that, as the standard now coyly admits:
While the primary purpose of the AMI_Init function is to perform the required initialization steps, it may also include linear time invariant (LTI) signal processing algorithms. Therefore, statistical simulations may be performed using the AMI_Init function alone.The IBIS AMI allows either or both LTI and NLTV sections in any given model. So my recommendation is that when you see “AMI_Init” read it as “AMI init and LTI” meaning that it contains not only init code but, in the case of a LTI transmitter (Tx) or receiver (Rx), the whole model. Likewise read “AMI_GetWave” as “AMI non-linear and/or time varying (NLTV)” meaning that, if AMI_GetWave exists, then the model is NLTV, and its behavior is described in AMI_GetWave. But wait, what if a model has both? I’ll get to that strange case next…
2. A Tx or Rx that is NLTV can also be described by an (approximate) LTI representation
AMI allows the model builder to provide an LTI approximation of an inherently NLTV Tx or Rx. This made me wonder “Is that a valid thing to do?” and “Why would you even try?” It turns out the answer to the first is “Yes, under some circumstances.” For example, an adaptive equalizer can be modeled as LTI once its taps have settled out. Likewise a clock/data recovery circuit has an LTI approximation once it’s PLL is stably locked. The answer to the second question is that the motivation is if you have an “LTI trifecta” (LTI Tx model, an LTI channel model, and an LTI Rx model), you can apply a clever trick that gets you an eye pattern diagram and all the BER contours very quickly. There is a mathematical algorithm called statistical eye diagram that can construct the BER contours purely from the convolution of the three LTI impulse responses. The algorithm is super quick compared to the superposition of a long bit pattern waveforms. IBIS AMI channel simulators supports the super quick method (called “statistical mode”) if both Tx and Rx models have an exact or approximate LTI representation in AMI_Init. The model builder will set a flag called Init_Returns_Impulse if the model has an LTI representation available to the channel simulator.
3. The impulse responses seems to be calculated in the wrong order
In statistical mode, the order the impulses responses are calculated is: channel first, Tx second, Rx third. At first blush, the logical order would be Tx, then channel, then Rx. Why reversal of channel and Tx? The reason is that the Tx is allowed to “peek” at the channel impulse response before it decided what its response should be. This twist allows the model builder to build in a simple representation of backchannel where the Tx optimizes itself for the channel it is connected to. Likewise, the Rx can “peek” at the convolution of the Tx and channel before it decides what its impulse response is. This is a mechanism for modeling adaptive equalizers that have settled out.
4. The *.ibs file is required, but the non-linear parts are linearized out
In the traditional IBIS flow, the analog model is specified in the *.ibs file which runs in a SPICE-like transient simulator that solves Kirchoff’s current laws by modified nodal analysis. The IBIS AMI flow also requires a *.ibs file (and two other files) but the channel simulator uses the *.ibs file in a rather different way. The channel simulator triggers the digital input of the *.ibs analog model of the Tx, the step has passes through the Tx *.ibs analog model, then the channel, and then the Rx *.ibs analog model. The channel simulator then differentiates the output of the Rx to get hac, the analog-channel impulse response. If anything in the analog-channel is non-linear, it gets linearized out, and the linear approximation hac is used. The bottom line is that you can’t take a traditional *.ibs file and merely plug a *.ami file and some executable code into it. You have to put non-linearity (if any) into the AMI_GetWave function, and write a *.ibs file that is LTI.
Remember, there’s lots more info in our new white paper Explore the SERDES design space using the IBIS AMI channel simulation flow
As always I welcome your feedback. What do you like about IBIS 5.1? What drives you nuts? Please leave a comment!
See also our IBIS AMI FAQ.