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.