Break away from IBIS-AMI models with PyBERT

Article By : David Banas

PyBERT is 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-AMI modelling standard was expected 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.

Background
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 behaviour: equalisation. Consider, for instance, that one often finds I/V "tables" in IBIS-AMI models contain only four points:

[Pulldown]

-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 behaviour of a 1.8 V Tx (transmitter) driver with 50 Ω single-ended output impedance. As is obvious, the behaviour 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:
 • Impedance
 • Low corner
 • High corner
 • Maximum current

Likewise, the V/T tables of IBIS models are often omitted from IBIS-AMI models in favour of the simpler [Ramp] keyword: (Excerpted from the same Tx model, as above.)

[Ramp]

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

[Algorithmic Model]

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 equalisation behaviour (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 modelling standard (i.e. the IBIS-AMI extensions), form a supposedly complete and precise specification for integrating the "black box" model of SERDES equalisation behaviour into the IBIS simulation flow.
Because the model of the SERDES equalisation behaviour 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 equalisation behaviour:

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 behaviour (i.e. CDR/DFE [clock data recovery/decision feedback equalisation] dynamic adaptive behaviour) 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 equalisation behaviour 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 favourite SerDes designer to lunch and asked "So, how is IBIS-AMI modelling 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 modelling 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 modelling myth.

Introducing PyBERT
PyBERT is a free, open source, public domain, serial communication link modelling and design tool, written in the Python language. It makes use of the Traits/UI library from Enthought to provide a GUI (graphical user interface). It can be used to explore serial link design concepts, as well as to begin the high level architectural trade-off phase of link design.
PyBERT comes with absolutely no guarantee of support or merchantability/fitness for any particular purpose, whatsoever. As with the vast majority of public domain, open source projects, the risk you undertake by using PyBERT is yours and yours alone. Please understand this clearly before proceeding.
To install PyBERT into your existing Python installation, execute one of the following two commands, from your system command prompt:
 • pip install PyBERT
 • easy_install PyBERT

After installation, execute the python -m pybert command, from your system command prompt to launch PyBERT. If you need to install Python onto your machine, you have several options. I suggest opting for Python 2.7, as opposed to 3.5, for now. Because that's the version I used for testing PyBERT.

PyBERT Demo
Let's see PyBERT in action. Figure 1 shows the first tab presented to the user, immediately after PyBERT is launched. It is the tab used to configure the simulation.

*Figure 1: Customise the simulation to your particular SERDES device.*
Configuration occurs in seven main categories, described below.

1. Simulation Control
2. Channel Parameters
3. Tx Equalisation
4. Rx Equalisation
5. CDR Parameters
6. DFE Parameters
7. Analysis Parameters

Note: You can access help text for any item in the configuration tab by hovering your mouse cursor over the data entry field for that item.
Additionally, there is a status bar near the bottom of the PyBERT application window that provides the following information:
 • Simulator status
 • Performance of last simulation run
 • Estimated channel delay
 • Number of bit errors detected in last run
 • Estimated power dissipated by the transmitter
 • Jitter breakdown from last run

and a button for launching the simulation.

Simulation control
The simulation control group is used to configure certain general properties of the simulation, such as: bit rate, samples per bit, Tx driver output voltage, etc. Currently supported modulation types include: NRZ, Duo-binary, and PAM4.

Channel parameters
This group is used to define the properties of the interconnect between Tx and Rx. This interconnect may be defined, either by entering numbers into the provided fields, or by reading in an impulse or step-response file.

Tx equalisation
This is where you set the Tx equalisation settings. Additionally, this group offers the possibility to sweep the Tx equalisation settings through some number of user-defined states.

Rx equalisation
Rx equalisation settings are configured here. The available CTLE (continuous time linear equalisation) modes are:
 • Off. CTLE is disengaged and provides no modification to the passing signal. Note, however, that the finite bandwidth of the Rx signal path, set by the Bandwidth parameter, is still observed.
 • Passive: the maximum frequency response is scaled to 1.
 • AGC: The settling output of the system step response, up to and including the CTLE, is adjusted to equal the value of the Level parameter. (See DFE Parameters section, below.)
 • Manual: The DC offset of the CTLE frequency response is set by the user.

When Ideal DFE is selected, the bandwidth of the DFE summing node is assumed infinite. This improves simulation performance, but introduces sharp transitions in the DFE output, at UI boundaries, which aren't realistic. Typically, these sharp jumps don't alter the aspects of the eye, which we are most concerned with, which is why the option is provided.

CDR parameters
These parameters require a fairly sophisticated understanding of bang-bang CDR operation, as well as a deep dive into the code and, probably, a few conversations with me, to understand. Fortunately, they almost never require fiddling.

DFE parameters
This group of parameters controls the DFE adaptation behaviour, as follows:
 • Gain. The raw error is multiplied by this value, before being fed into the LMS adaptation engine.
 • Taps. Number of DFE taps.
 • Level. Slicer output voltage (i.e. – reference value for error calculation)
 • Nave. Number of averages taken before allowing LMS adaptation engine to step (also, and not coincidentally, the number of CDR adaptations that occur, for every DFE adaptation).
BW. Summing node bandwidth (only meaningful, when Ideal DFE is not checked).

Analysis parameters
These control the analysis of the simulation results. Currently, there is only one parameter: Pj Thresh, the threshold (in units of standard deviation) used, when plucking periodic signals out of the jitter spectrum during jitter breakdown.
Figure 2 shows the second tab of the PyBERT GUI: DFE. This tab displays information about the CDR/DFE adaptation process from the last simulation run. It contains four plots:
CDR Adaptation: Shows the instantaneous clock period, as a function of time.
DFE Adaptation: Shows the values of all DFE taps, as a function of time.
CDR Clock Period Histogram: Shows the histogram of clock periods output by the CDR, over the entire period of the last simulation run. The two "wings" correspond in position to the magnitude of the CDR proportional branch, while the spreading of all three peaks is due to the finite gain of the CDR integral branch.
CDR Clock Period Spectrum: Shows the spectral content of the CDR "Clock Period vs. Time" signal. The large spikes are, typically, harmonics of the bit pattern repetition frequency.

*Figure 2: PyBERT's DFE tab lets you see DFE and CDR adaptation behaviour.*

Figure 3 shows the EQ Tune tab of the PyBERT GUI. Here's where you can optimise the Tx/Rx equalisation for your chosen channel, bit rate, and modulation type. (All three modulation types support equalisation optimisation.) The fields should be self explanatory, but remember, hovering over a data entry field will produce a helpful message explaining the intent of that parameter.

*Figure 3: EQ Tune tab lets you configure settings for TX/Rx equalisation.*

Individual optimisation of Tx and Rx, via the OptTx and OptRx buttons, as well as Tx/Rx co-optimisation, via the CoOpt button, are all supported, although co-optimisation is currently experimental. Clicking the ResetEq button will reset all equalisation settings to those currently entered in the Config. tab. The SaveEq button performs the reverse operation, moving the newly optimised settings to the Config. tab, so that you can try them in a new simulation run.
The plot displays the new system pulse response (in blue), up to and including the CTLE, but not the DFE, as well as the predicted CDR clocking instants used by the slicer (in grey).
The next nine tabs of the PyBERT GUI all share the same general layout, which consists of four plots:

1. Channel
2. Channel + Tx Pre-emphasis
3. Channel + Tx Pre-emphasis + CTLE
4. Channel + Tx Pre-emphasis + CTLE + DFE

For some particular system characteristic being displayed, you can easily see the behaviour of the unequalised channel as well as how that behaviour is modified by each of the three equalisation stages: Tx pre-emphasis, CTLE, and DFE. A few examples are shown in figures 4 through 8.

PyBERT output examples
*Figure 4: This tab shows the pulse response, at different points in the link.*

*Figure 5: The Eyes tab of the PyBERT GUI lets you see how settings affect signal integrity.*

*Figure 6: The Freq. Resp. tab of the PyBERT GUI shows the incremental and cumulative frequency response at different points in the link.*

* Figure 7: You can see the jitter distribution of the simulated design using the Jitter Dist. Tab.*

Figure 8: PyBERT also lets you see a serial link's bathtub curves.

Future forecast
I hope I've intrigued you with the possibility of having a community maintained resource for high-speed serial communication link design, such that the project attains critical momentum and galvanizes a movement, among systems designers, to break free from the constraints of black boxes, obfuscated models, and wizardly deception. I believe such a movement has the power to liberate us from IBIS-AMI dysfunction and re-empower us with control over our serial link design project schedules.
I envision that the growth of the PyBERT source code base will take two orthogonal courses:

1. The more generous souls in our community will find a little time to participate in the maintenance and further development of the source code, returning any improvements to the public domain source pool and generally operating with a spirit of community and sharing.
2. The less evolved among us will probably use the existing code base as a starting point for their own internal, proprietary tools, which they'll opt not to share back with the PyBERT community.
   In my opinion, both courses of action are perfectly acceptable. In fact, I have chosen the BSD3 licence for this work, as opposed to the GPL, specifically so that those who wish to travel course 2 can do so without concern about licence virility, which might force you to share any improvements made with the rest of us. It is my intent that each person who improves the PyBERT source code shall have complete freedom in deciding whether or not to share the fruits of his or her labour with the rest of us. Of course, we hope you will. If you don't, that's our problem, not yours

Conclusion
I want to make it clear that PyBERT is not intended to replace IBIS-AMI simulation as the vehicle for final sign-off of PCB CAD data, before release to board fabrication. PyBERT is not suitable in this role because it lacks one very important feature: implied liability/accountability on the part of the silicon vendor. This is an important part of the accountability chain for any commercial product, and should not be omitted.
What PyBERT can offer us all is a way to get started on our next serial link design, before IBIS-AMI models of our SERDES become available.

About the author
David Banas is a 23 year veteran of the semiconductor industry, currently, providing customer design, modelling, and characterisation support for high speed serial transceivers in the programmable logic space.