IBIS OPEN FORUM
I/O BUFFER MODELING COOKBOOK

Version 4.0

Revision 0.8

Prepared By:

The IBIS Open Forum

Senior Editor:

Michael Mirmak
Intel Corp.

Contributors:

John Angulo, Mentor Graphics Corp.

Ian Dodd, Mentor Graphics Corp.

Lynne Green, Green Streak Programs

Syed Huq, Cisco Systems

Arpad Muranyi, Intel Corp.

Bob Ross, Teraspeed Consulting Group

From an original by Stephen Peters

  • Rev 0.0 – August 10, 2004
  • Rev 0.1 – September 9, 2004
  • Rev 0.2 – October 5, 2004
  • Rev 0.3 – October 7, 2004
  • Rev. 0.4 – October 15, 2004 – added series/series switch descriptions; incorporated written feedback from Arpad, updated the single-ended totem-pole buffer diagrams, reformatted document with appropriate labels and table of contents; used buffer or component in place of device in many cases; incorporated new SSO language; added new differential type diagrams.
  • Rev. 0.5 – October 21, 2004 – minor editorial changes, including fonts on examples; added captions to all drawings; added a new [Pin Mapping] description, with diagram; added diagrams to the “Series Element “ section
  • Rev. 0.6a – November 19, 2004 –added missing table and figure captions, inserted table of figures and table of captions, added A. Muranyi’s suggested changes from Nov. 18 Cookbook meeting; added note regarding pin-to-pad bijective mapping; revised differential section to describe systems before buffers; revised most curve figures; added detail on [Ramp] calculation and matching to I-V table data; grammar and spelling check completed
  • Rev. 0.6b – November 23, 2004 – updated clamp analysis and on-die termination text to account for differences between specification and A. Muranyi algorithms. Cookbook now recommends the Muranyi ranges for clamp generation and Muranyi methods of subtraction
  • Rev. 0.7 – December 22, 2004 – made changes suggested by A. Muranyi, including
  • Additional line breaks before and after each section
  • Expanded [Pin Mapping] example
  • Updated differential comments
  • Rev. 0.8 – May 25, 2005 – incorporates three subdrafts from A. Muranyi

1.0Introduction

1.1Overview of an IBIS File

1.2Steps to creating an IBIS Model

2.0Pre-Modeling Steps

2.1Basic Decisions

2.1.1Model Version and Complexity

2.1.2Specification Model vs. Part Model

2.1.3Fast and Slow Corner Model Limits

2.1.4Inclusion of SSO Effects

2.2Information Checklist

2.3Tips For Component Buffer Grouping

3.0Extracting the Data

3.1Extracting I-V Data from Simulations

3.1.2Sweep Ranges

3.1.3Making Pullup and Power Clamp Sweeps Vcc Relative

3.1.4Diode Models

3.2Extracting Ramp Rate or V-T Waveform Data from Simulations

3.2.1Extracting Data for the [Ramp] Keyword

3.2.2Extracting Data for the Rising and Falling Waveform Keywords

3.2.3Minimum Time Step

3.2.4Multi-Stage Drivers

3.2.5Differential Buffers

3.3Obtaining I-V and Switching Information via Lab Measurement

4.0Putting the Data Into an IBIS File

4.1Basic Syntax: Keywords and Their Definitions

4.1.1IBIS File Header Information

4.1.2Component and Pin Information

4.1.3The [Model] Keyword

4.2Data Checking

4.2.1Data Completeness

4.2.2I-V and V-T Matching

4.3Data Limiting

4.4Additional Recommendations

4.4.1Internal Terminations

4.4.2V-T Table Windowing

4.5Advanced Keywords and Constructs

4.5.1[Model Selector]

4.5.2[Submodel]

4.5.3[Model Spec]

4.5.4[Driver Schedule]

4.5.5[Pin Mapping]

4.5.6Series Elements

4.5.7[Diff Pin]

5.0Validating the Model

6.0Correlating the Data

7.0Resources

Figure 3.1 – Standard 3-state Buffer

Figure 3.2 – Simulation Setup for Extracting Ramp Rate Information

Figure 3.3 – A device having independent input, output and power supply ports

Figure 3.4 – A device with ports using a common ground

Figure 3.5 – An input port with locally generated reference

Figure 3.6 – Single ended receiver

Figure 3.7 – True differential receiver

Figure 3.8 – Half differential receiver

Figure 3.9 – Pseudo differential receiver

Figure 3.10 – Single ended driver

Figure 3.11 – True differential driver with external load

Figure 3.12 – Half differential driver with external load

Figure 3.13 – Pseudo differential driver example

Figure 3.14 – Block diagram of a true differential model using IBIS v3.2 constructs

Figure 3.18

Figure 4.1 – Conceptual Diagram of Model Keyword Structure

Figure 4.2 – Model Keyword Structure with Added Diode Detail

Figure 4.3 – Graph of [GND Clamp] I-V Table Data

Figure 4.4 – Graph of [POWER Clamp] I-V Table Data after Clamp Subtraction

Figure 4.5 – Raw I-V and Extrapolated Final [GND Clamp] Data Graphs

Figure 4.6 – Raw I-V and Extrapolated Final [POWER Clamp] Data Graphs

Figure 4.7 – Graph of [Pulldown] I-V Table Data, after Clamp Subtraction

Figure 4.8 – Graph of [Pullup] I-V Table Data after Clamp Subtraction

Figure 4.9 – Diagram of Resistive Load for Rising Waveform

Figure 4.10 – V-T Table Loading Example

Figure 4.11 – V-T Table Loading Example, Simplified

Figure 4.12 – [Pullup] I-V Table Data with Load Line Intercept

Figure 4.13 – Data Point Selection Example

Figure 4.14 – Diagram of I/O Buffer with Internal Termination

Figure 4.15 – Raw I-V Table Clamp Data for Ground-connected Termination

Figure 4.16 – Graph of I-V Data for Ground Terminated Buffer in High-Impedance State

Figure 4.17 – Graph of Power and Ground Clamp I-V Data for Vcc-connected Termination

Figure 4.18 – Graph of I-V Data for Vcc Terminated Buffer in High-Impedance State

Figure 4.19 – Component Diagram Showing Buffer and Supply Buses

Figure 4.20 – Connection of Single-ended and Series [Model]s

Table 1 – Recommended Load Circuits and Waveforms for V-T Data Extraction

Table 2 – IBIS File Header Keywords

Table 3 – IBIS Component and Pin Information

Table 4 – IBIS [Model] Subparameters

Table 5 – IBIS [Model] Temperature and Voltage Keywords

Table 6 – [Model] I-V Table Keywords

Table 7 – Pulldown I-V Table (Typical Only)

Table 8 – [Ramp] and Waveform Table Keywords

Table 9 – Example V-T Table Data for Rising Waveform

Table 10 – V-T Table Loading Recommendations

1.0Introduction

This cookbook describes the steps required to produce IBIS models for digital integrated circuits (ICs). IBIS (officially, EIA standard 656-A-1999, IEC 62014-1) stands for I/O Buffer Information Specification. IBIS models provide a standardized way of representing the electrical characteristics of an digital IC’s pins (input, output, or I/O buffers) behaviorally, i.e., without revealing the underlying circuit’s structure or process information.

The purpose of this document is to describe how to gather the information required to produce an IBIS model, as well as some of the common pitfalls to avoid when creating the IBIS file itself. Note that the basic behavioral information in an IBIS model can be obtained either by direct measurement of the component or transistor level simulation of the component’s buffers. This cookbook describes both methods. The cookbook is targeted towards generating models of CMOS, GTL, and bipolar parts, and applies to models generated for IBIS versions 3.2 and 4.0. For the most recent version of the specificationand other IBIS documents visit the IBIS web page. For access information, see section 7.0later in this cookbook.

The intended audience of this cookbook is those responsible for performing the measurements or simulations that gather I/O buffer data, as well as those responsible for actual IBIS model creation. Persons involved in SI or system level PC board simulations may also benefit by reading this document. It is assumed that the reader has some familiarity with behavioral modeling of I/O buffers and analog simulation.

1.1Overview of an IBIS File

An IBIS file contains, in a human readable ASCII format, the data required to behaviorally model a component’s input, output and I/O buffers. Specifically, the data in an IBIS file is used to construct a model useful for performing signal integrity (SI) simulations and timing analysis of printed circuit (PC) boards. The fundamental information needed to perform these simulations is a buffer’s I-V (current vs. voltage) and switching (output voltage vs. time) characteristics. Please note that the IBIS specification does NOT define an executable simulation model – it is a standard for the formatting and transfer of data. As such, the specification defines what the information included in an IBIS file represents and how it is to be gathered. It does not specify what an analog simulation application does with the data.

IBIS models are component-centric. That is, an IBIS file allows one to model an entire component, not just a particular input, output or I/O buffer. Therefore, in addition to the electrical characteristics of a component’s buffers an IBIS file includes a component’s pin-to-buffer mapping, and the electrical parameters of the component’s package.

In general an output or I/O buffer is characterized behaviorally using the following information:

  • The buffer’s output I-V characteristics when the output is in the logic low state
  • The buffer’s output I-V characteristics when the output is in the logic high state
  • The buffer’s output I-V characteristics when the output is forced below ground and above the power supply rail (referred to as its ‘beyond the rail’ characteristics)
  • The time it takes a buffer’s output to switch logic states (i.e. from low to high and high to low)
  • The buffer’s capacitance

For an input buffer the required information is reduced to:

  • The buffer’s I-V characteristics (including its ‘beyond the rail’ characteristics)
  • The buffer’s capacitance

The above information is included in an IBIS file using ‘keywords’. A keyword is a word or phrase surrounded by square brackets. Keywords are followed either by specific parameters or tables of data. For instance, the [Model] keyword would be used to encapsulate the I-V and V-T tables, plus other data, for individualsingle-ended I/O buffer. Some keywords are required, but most are optional. At a minimum, a valid IBIS file contains the following data and keywords:

1. Information regarding the file itself and name of the component being modeled. This information is contained under the keywords [IBIS Ver], [File Name], [File Rev], [Component] and [Manufacturer].

2. Information about the package’s electrical characteristics and the pin to buffer model mapping (i.e. which pins are connected to which buffer models). This information is included under the [Package] and [Pin] keywords.

3. The data required to model each unique input, output and I/O buffer design on the component. The [Model] keyword introduces the data set for each unique buffer. As described above, buffers are characterized by their I-Vbehaviors and switching characteristics. This information is included using the keywords [Pullup], [Pulldown], [GND clamp], [POWER Clamp] and [Ramp]. In addition, the required parameters to the [Model] keyword specify a model’s type (Input, Output, I/O, Open_drain, etc.) and its input or output capacitance.

The details of constructing an IBIS model from data are included in the chapter Putting the Data Into an IBIS Filelater in this document.

1.2Steps to creating an IBIS Model

There are five basic steps to creating an IBIS model of a component:

1.Perform the pre-modeling activities. These include deciding on the model’s complexity, determining the voltage, temperature and process limits over which the IC operates and the buffer model will be characterized, and obtaining the component related (electrical characteristics and pin-out) and use information about the component. See the chapter titled Pre-Modeling Steps.

2.Obtain the electrical (I-V tables and rise/fall) data for output or I/O buffers either by direct measurement or by simulation. See the chapter titled Extracting the Data. This chapter may also be used by those who are doing the simulations required to gather the data but not actually creating the IBIS file.

3.Format the data into an IBIS file and run the file through the Golden Parser. See the chapter titled Putting Data Into an IBIS File.

4.If the model is generated from simulation data, validate the model by comparing the results from the original analog (transistor level) model against the results of a behavioral simulator that uses the IBIS file as input data. See the chapter titled Validating the Model.

5.When the actual silicon is available (or if the model is from measured data), compare the IBIS model data to the measured data. See the chapter titled Correlating the Data.

The rest of this cookbook documents these steps in detail.

2.0Pre-Modeling Steps

2.1Basic Decisions

Before one creates an I/O buffer model there are several basic questions that must be answered regarding the model’s complexity, operational limits, and use requirements. Answering these questions requires not only a knowledge of the buffer’s physical construction, but also a knowledge of the final application in which the IC will be used, and any specific requirement the model users may place on the model. These questions cannot be answered by the model creator alone; they generally require the involvement of both the buffer designer and members of the team responsible for insuring that the I/O buffers are useable in a system environment. This team is referred to as the interconnect simulation team. Together, the model creator and interconnect simulation team must determine the following:

2.1.1Model Version and Complexity

Based on the characteristics and construction of the I/O buffer itself, and the model user’s simulator capability, you must decide what IBIS version of the model is most appropriate. Different IBIS versions, as denoted by the [IBIS Ver] keyword, support different features. Additionally, the checking rules used by the IBIS Golden Parser change slightly with each version. In general, models should use the highest [IBIS Ver] version number supported by the Golden Parser and by their simulation tools. Similarly, following good engineering practice, use the simplest model that will suffice.

For standard CMOS buffers with a single stage push-pull or open drain outputs,a version 1.1 model is the starting point. A version 1.1 model describesa buffer using a low state and high state I-V table, along with a linear ramp that describes how fast the buffer switches between states. IBIS version 2.1 adds support for tables of V-T data, in addition to support for ECL and dual-supply buffers, ground bounce from shared power rails, differential I/O buffers, termination components, and controlled rise-time buffers. A version 2.1 or above model will be required if the I/O buffer has any of the following characteristics:

  • Multiple Supply Rails -- A version 2.1 (or higher) model is required if the buffer contains diode effects – from parasitic diodes or Electrostatic Discharge (ESD) diodes – which are referenced to a different power rail than the pullup or pulldown transistors, or if the I/O uses more than one supply (for example, a buffer whose output swings from below ground or above Vcc).
  • Non-Linear Output Switching Waveform – A version 2.1 (or higher) model is required if the I/O buffer’s output voltage vs. time waveform (its V-T waveform) when switching low-to-high or high-to-low cannot be accurately described using a linear ramp rate value. This is the case for GTL technology, or for any buffer that uses “graduated turn on” type technology.
  • In addition, a version 2.1 model description is required if the model maker wishes to enable the user to perform ground bounce simulations by connecting several buffers together on a common supply rail. See the [Pin Mapping] keyword description below.

IBIS version 3.2 and abovesupport an electrical board description, multi-staged buffers or buffers which may use multiple -I-V tables and diode transient times, among other features.

2.1.2Specification Model vs. Part Model

A model can be made to represent a particular existing component or can be made as a representative encapsulation of the limits of the specification for a class of components. Specification vs. Part is a major factor in determining if and how much guard-banding or de-rating a model requires. Generally, a “spec model” is based on an existing part, then the strength and edge rate of the model is adjusted to meet the best and worst case parameters of a particular specification. For example, an GTL buffer model for a particular processor may give a worst case Vol of 0.4 Vat 36mA. However, if the GTL specification allows for a worst case Vol of 0.6 V at 36mA the model’s pulldown table may be adjusted (or de-rated) to describe the specification and not just the behavior of an individual part.

2.1.3Fast and Slow Corner Model Limits

The IBIS format provides for slow (weakest drive, slowest edge), typical and fast (strongest drive, fastest edge) corner models. These corners are generally determined by the environmental (temperature and power supply) conditions under which the silicon is expected to operate, the silicon process limits, and the number of simultaneous switching outputs. The interconnect team or project must supply the model developer with the environmental, silicon process, and operational (number of SSOs) conditions that define the slow, typical and fast corners of the model. Please note that for an output buffer model to be useful for flight time simulations these conditions MUST match those used for specifying the buffer’s Tco parameter.

2.1.4Inclusion of SSO Effects

Closely related to the discussion on model limits is the decision on how to include Simultaneous Switching Output (SSO) effects. SSO effects can be included explicitly in a model by measuring the I-V and edge rate characteristics under SSO conditions. For example, a buffer’s I-V characteristic can be measured with all the adjacent buffers turned on and sinking current, or the buffer’s edge rate may be measured while adjacent buffers are also switching. Alternatively, a model that represents a single buffer in isolation may be created, then several buffers may be connected to a common power or ground rail via the [Pin Mapping] keyword. The former method (including SSO effects in the I-V and V-T tables) has the advantage that the resulting model is straight forward to verify and less dependent on any particular simulator’s capability. Note however, the [Pin Mapping] keyword method does give the user the ability to perform explicit ground bounce simulations and devise specific ‘what if’ scenarios.

Note that the information provided under IBIS 4.0 and earlier versions only describes the output behavior of buffers under loaded conditions. Therefore, SSO simulations will only be based on the behavior at the pad and not upon information extracted about the current profile of the supplies as the buffer switches. Different distributions of internal buffer current may result in the same behavior at the pad. Different simulation tools may therefore make radically different assumptions regarding SSO behavior for the same IBIS data. Check with your simulation tool vendor for details on their specific assumptions and IBIS SSO simulation algorithms.