Free yourself from IBIS-AMI models with PyBERT
The IBIS-AMI modeling standard was supposed to free high-speed serial communication link designers from the SPICE model chains, which perpetually lengthened design cycles. Unfortunately, IBIS-AMI has fallen short of the mark. IBIS-AMI models run from two to three orders of magnitude faster than the SPICE equivalents—which is great for systems designers.
IBIS-AMI models are, however, also plagued by a lack of commitment to the standard by some silicon vendors and a decided lack of consistency in interpretation by the commercial tools supporting it.
Fortunately, you needn't use IBIS-AMI models (or, their SPICE antecedents) throughout the entirety of the link design process. In fact, you only need them at the very end of that process, as a tool for final "signoff" validation of the PCB CAD data, before sending it off to the PCB fabricator. I now introduce PyBERT, a public domain, open source tool that you can use as an alternative to IBIS-AMI models during the initial phases of high speed serial communication link design.
The IBIS model framework that was coopted to create the IBIS-AMI standard is really just a convenient interface shell, or wrapper, around a “black box” executable model of the truly important aspects of SERDES behavior: equalization. Consider, for instance, that one often finds I/V "tables" in IBIS-AMI models contain only four points:
-1.80 -1.000e+01 -1.000e+01 -1.000e+01 0.00 0.000e+00 0.000e+00 0.000e+00 1.80 3.600e-02 4.000e-02 3.273e-02 3.60 1.000e+01 1.000e+01 1.000e+01
The I/V table above was taken directly from an IBIS-AMI model created, using the ibisami public domain tool, and represents the pull-down behavior of a 1.8 V Tx (transmitter) driver with 50 Ω single-ended output impedance. As is obvious, the behavior conveyed by the table, above, could just as easily have been described by the following sub-parameters of the IBIS [Model] keyword, if they existed:
- Low corner
- High corner
- Maximum current
Likewise, the V/T tables of IBIS models are often omitted from IBIS-AMI models in favor of the simpler [Ramp] keyword: (Excerpted from the same Tx model, as above.)
dV/dt_r 0.540/108.00p 0.512/511.58p 0.566/56.57p dV/dt_f 0.540/108.00p 0.512/511.58p 0.566/56.57p
Again, we see that tabular data could easily be replaced by a single sub-parameter: slew_rate. So what, then, is the value of the IBIS format, when behaviorally modeling high speed serial transceivers? Essentially, it boils down to one added keyword: [Algorithmic Model]. Consider the following excerpt taken from the same Tx model, as above:
Executable linux_gcc4.1.2_32 example_tx_x86.so example_tx.ami Executable linux_gcc4.1.2_64 example_tx_amd64.so example_tx.ami Executable Windows_VisualStudio_32 example_tx_x86.dll example_tx.ami Executable Windows_VisualStudio_64 example_tx_amd64.dll example_tx.ami
[End Algorithmic Model]
The keyword block above alerts the simulator to the presence of an executable "black box" model of the Tx equalization behavior (the *.so and *.dll files), as well as a human readable "guide" file (the *.ami file), which can help both the simulator and the user more effectively interact with the executable model. These two files, along with certain recent extensions to the IBIS modeling standard (i.e. the IBIS-AMI extensions), form a supposedly complete and precise specification for integrating the "black box" model of SERDES equalization behavior into the IBIS simulation flow.
Because the model of the SERDES equalization behavior is distributed by its vendor in the form of a "black box" executable, we have no choice but to wait until it becomes available, before we can begin our serial link design, right?
How black is "black?"
Just as Dorothy and her friends discovered that what personal accouterments the wizard was peddling weren't anything they didn't already possess, so can we serial link designers free ourselves from our presumed dependency upon IBIS-AMI models, if we are willing to pull the curtain aside and look at the inner workings of the machinery.
Let's start with the Tx. It's simpler than a receiver. What great wizardry lies inside the mysterious "black" box of a Tx IBIS-AMI model? As it turns out in the vast majority of cases, nothing but a simple FIR (finite impulse response) filter, which has been described in the public literature for decades. Here is the Python code used in PyBERT to model the Tx equalization behavior:
main_tap = 1.0 - abs(pretap) - abs(posttap) ffe = [pretap, main_tap, posttap] ffe_out = convolve(symbols, ffe) tx_out = repeat(ffe_out, nspui) # oversampled output
Should these four lines of Python code deserve wizardly status?
A SerDes Rx is quite a bit more complicated than the transmitter. In fact, several aspects of its behavior (i.e. CDR/DFE [clock data recovery/decision feedback equalization] dynamic adaptive behavior) are still the topic of some rather recent and exciting research work at the Ph.D. level. With those few exceptions, however, the algorithms used to model the equalization behavior of SerDes are well known and documented.
"Do I still need IBIS-AMI models, in order to do my work?" Fortunately, you don't.
Consider that, if you took your favorite SerDes designer to lunch and asked "So, how is IBIS-AMI modeling working for you?”, the designer might struggle to contain his or her bemused contempt for you, wondering how anyone can't be using MATLAB or Python/NumPy/SciPy for the majority of high-speed serial communication link design work. SerDes designers yearn for the day when we lowly systems designers can converse with them in their native language. It's probably time for us to become bilingual.
Among SerDes architects, IBIS-AMI is the unwanted stepchild of a modeling standard they're forced to support only because, if they didn't, we "systems" (PCB) designers wouldn't know how to design around their parts. It's no coincidence that the most junior member of a SesDes design team is usually tasked with IBIS-AMI model creation and support.
Understanding the fundamental concepts of serial communication link design really isn't all that hard. What we need is a community resource that we can use to begin our exploration of serial link design fundamentals, which is completely open and accessible to all. We need a “white box” serial-link simulator with an intuitive user interface with the source code in the public domain so that all can peruse, critique, and improve upon it. An open community can break the spell of the IBIS-AMI modeling myth.