Signal Integrity

Power-aware Signal Integrity and EMI/EMC On High-speed Digital Chip-to-Chip Links

Signal Integrity header image 2

Four Things That Drove Me Nuts About IBIS 5.1

Posted September 25th, 2012 · 6 Comments · Technical Paper


By Colin Warwick

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…

IBIS AMI isn't like a sandwich (Photo credit: )

Why IBIS AMI isn’t like a sandwich
(Photo credit: Wikimedia Foundation/ 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.

Tags: ··

6 Comments so far ↓

  • Jim Nadolny

    Great post, I found it useful. Any suggestions on where I could find some IBIS AMI models of TX/Rx devices? I would like to play around in ADS with these features.

    thanks – jn

  • Colin Warwick

    Thanks, Jim.

    There are several demo models built in to ADS. From the schematic menu, select DesignGuide==>IBIS AMI==>Sample AMI models. The model files are placed in the data folder of the workspace. Browse for them from the dialog box of the AMI component in your schematic. If you want models of real ICs, you usually have to sign an NDA with your IC vendor before they will give them to you.

    Best regards,

    — Colin

  • Mohammad Bapi

    Thank you Colin for this great post.

    When I first started looking at IBIS-AMI, I was also confused about AMI_INIT, which sounded like this function is for initializations only. It took a while to realize that there is more to it…

    Also from item 4 in your post, it appears that it is best to put all the non-linearity in AMI portion, even though it will NOT be totally wrong if .ibs contains some non-linearity (as you mentioned it will simply get linearized out)

  • Colin Warwick

    Thanks, Mohammad, Fortunately with the LVDS of modern SERDES there isn’t much analog non-linearity so a linear *.ibs file works very well. Most of the non-linearity is in the Rx. The slicer of the DFE is non-linear at finite error rates and the CDR is usually non-linear. Adaptive equalizers are time varying before they settle.

    Best regards,

    — Colin

  • Mohamed Daoudi

    Thanks Colin for this wonderful post, I’m new in IBIS ami modeling and all tools related to it, your post was so well written that after having read it, I feel confortable with a global overview on the subjects

    Best regards

  • Colin Warwick

    Thanks, Mohamed. Please let us know if we can be of further assistance.

    Best regards,

    — Colin

Leave a Comment