Let's Get Intimated with IBIS
By Deepak Kumar Behera, Sumit Varshney, Sunaina Srivastava and Swapnil Tiwari
Freescale
The Rise of IBIS:
IBIS is the abbreviation for ‘I/O Buffer Information Specification’. It is actually specification for data format which represents the analog behavior of various IO buffers. With the need for extensive SI simulations for high speed IO buffers, there was an increasing need to look beyond the normal method of simulations using SPICE models. The experiment of using I-V curves based buffer models for simulations by Intel became a huge success. But, since the users use tools from various tool vendors, it was agreed upon by several EDA tool vendors for a common, tool-independent behavioral model format. Thus the IBIS Open Forum was born and since then many a versions of the IBIS have been standardized and the latest version is IBIS 5.0, released in August 2008.
Detailing IBIS:
Let’s have a look at how the data for a buffer, here we shall only be dealing with CMOS buffer, is modeled in IBIS format. A CMOS buffer in IBIS is modeled as the following building blocks.
Figure 1: Building Blocks of an IBIS Model
As it was felt conceivable to model CMOS buffer using edge rates and I-V curves, above basic building blocks were construed to suffice the modeling of the buffers, though at the later stages many new items were introduced into the IBIS model. In the above figure, the leftmost block is the logic block which controls the rest other blocks to put the buffer into receive, drive high or drive low or tri-state mode. As seen in the figure, the basic IBIS model consists of four I-V curves, two ramp numbers (V-t curve), die capacitance and package model.
- The four I-V curves model the pullup and pulldown structures and their associated power clamp and ground clamp characteristics.
- The ramp-up and ramp down provide the V-t curves for the edge rates, both rising and falling, while switching.
- The die capacitance is the value of all capacitances summed up when we look into the die pad.
- The package models describe the package parasitic.
In a CMOS buffer the pullup structure is usually implemented using pMOS and pulldown by nMOS. In case of pulldown I-V curve the reference is Pulldown Reference, GND. However, when one goes for pullup I-V curve, the reference is Pullup Reference, Vdd i.e. the source voltage and it doesn’t make any sense for the pullup I-V curve to be ground relative as the Vgs and Vds are not related to GND potential. I-V curves of Vdd ¬relative pullup structures and GND relative pulldown structures are perfectly symmetric. Moreover, when there is power supply noise the simulator is not required to recalculate the GND relative voltages w.r.t. the varying supply voltage.
A buffer usually has three different modes of functioning like receive mode, drive high and drive low mode. IBIS model of a buffer consists of I-V curves for all three modes. So what exactly the I-V curves contain for each mode?
Receive Mode: It contains anything and everything that is constantly ON while not driving, like the characteristic current of parasitic diodes, ESD protection circuits, ODT or pullup/down resistors etc.
Drive Mode: In addition to the above, it contains the current that is dynamically turned ON and OFF. This includes the current of pullup and pulldown structures and any other dynamically switching structures.
It is to be noted that the I-V curves during the driving mode already contain the static current present in the receive mode. So, to avoid repetition the IBIS [pullup/pulldown] tables must not contain the data already present in [Power Clamp] and [GND Clamp] tables i.e. subtraction has to be made between the two measurements before putting the data in the [Pullup/Pulldown] tables.
The transient characteristics of buffer are introduced into the IBIS model using keyword like [Ramp] and [* Waveform]. It contains information about the edge rate i.e. how fast the pullup and pulldown transistors turn on/off. While tabulating the data for these tables, package effects are excluded. However, the effects of die capacitance, C_comp cannot be excluded, since C_comp is an integral part of the buffer model. Since [Ramp] and [* Waveform] data already includes the effects parasitic die capacitance, simulators must not load the buffer model with C_comp, yet C_comp must be in the model because I-V curves do not model capacitive effects (dV/dt). Simulators have special algorithm to avoid double counting C_comp, i.e. eliminate its loading on [Ramp] or the [* Waveforms], while keeping it visible when looking into the buffer model from outside.
Content and Structure of IBIS file:
An IBIS file starts with a header section, the details of which are shown in the tree-structure of Figure 2.
Figure 2: A View of IBIS File in 'HyperLynx Visual IBIS Editor'
Which part of the IBIS file is used for which mode is summarized in the below table:
The content of each table is summarized below:
Again, the I-V curves range is based upon transmission line theory. So it should span from –Vdd to +2*vdd. However, it’s not the same for Clamp I-V tables to prevent double counting. Both [GND Clamp] and [POWER Clamp] contains the same information except that the former measurement is w.r.t. the GND and the later is w.r.t. the POWER. Hence, [GND Clamp] spans from –Vdd to +Vdd and [POWER Clamp] spans from +Vdd to +2*Vdd. IBIS specifications limits the number of data points per I-V table to be 100 and per V-t table to be 1000. However, it has given freedom to the model makers to select any 100 points best suited to describe the shape of the curve i.e. uniform distribution of points along x-axis is not compulsory.
An IBIS file may contain modeling information for multiple devices or components, each starting with the keyword [Component]. Each component has its package data available along with some advanced items like model selector, differential pin associations etc. The model data describes each mode of the buffer distinctly. Also, models from different vendors can be combined into a same .IBS file, thus forming a system model with multiple components. Therefore, there may be multiple repetitions of package data, model selector etc.
Why go for IBIS?
We recommend the use of IBIS models whenever possible. IBIS models for many devices are often available as free downloads. Using IBIS provides the following:
- Faster simulation speed.
- Large variety of IOs in a single IBIS file, so easy system model simulation is possible.
- Inclusion of signal integrity specs like input logic thresholds, overshoots, etc.
- Elimination of non-convergence.
- Strong support from virtually all EDA vendors.
- Backward compatibility with models created under previous IBIS standards.
IBIS against SPICE
IBIS models are behavioral models which describe the electrical parameters as seen at their terminals. In essence, it is a black-box model which reveals no internal information unlike the SPICE models which are structural models. IBIS models are analogous to S-parameters modeling of interconnects. On the other hand, SPICE models which are structural models contain great amount of details. SPICE contains the detailed circuit schematics including the process file.
Best Practices to Follow:
Following things need to be taken care of while using IBIS models:
- The syntax of the IBIS models to be checked with the freely available Golden Parser.
- Operating conditions need to be mentioned, like temperature, process (min, max etc.).
- All used parameters to be included if possible.
- Correct model type to be used with corresponding parameters.
Hope the article serves the purpose of increasing IBIS awareness to a larger audience.
References:
[2] http://www.mentor.com/products/pcb-system-design/multimedia/ibis-models-webinar
[3] http://www.eda.org/ibis/home/tools/
|
Related Articles
New Articles
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- Synthesis Methodology & Netlist Qualification
- Streamlining SoC Design with IDS-Integrate™
E-mail This Article | Printer-Friendly Page |