Publications

IBIS Model Syntax and Keywords

IBIS Model Syntax and Keywords

By Timothy Coyle

Getting to Know the IBIS Header

The keyword syntax of the IBIS Specification can be broken down into a couple of different sections that make it easier to understand. In the IBIS Specification not all of the keywords are required and some are optional. However there are a lot of optional keywords that should be included in an IBIS file so we are going to discuss the important keywords whether they are optional or not by the specification standards. First up we are going to discuss the Header section.

On a side note as you go through the IBIS keyword syntax review in the next couple of sections you are going to see a lot of emphasis on following the syntax rules to avoid errors. Even a simple syntax error in an IBIS file will make it so most simulation tools and parsers cannot process the IBIS data making the IBIS file unusable until it is fixed. So you do have to pay attention to the IBIS syntax as part of an overall quality process flow.

Keep in mind that for some of the keywords you are not limited to just one line. For example, there is a [Date] keyword where you define the date so that won’t take more than one line in the IBIS file. However there is the [Notes] keyword that allows you to enter as many lines of notes in the IBIS file as you want and this can span multiple lines. Most simulation tools parse IBIS files from one defined keyword to the next so you can use multiple lines in most cases.

The above image shows an example IBIS file in an IBIS editor application. The tree pane on the left hand side gives a structural view of the different IBIS keywords and the right hand side displays the actual keyword definitions. In the above example, sample data has been placed to demonstrate just the header section of an IBIS file.

File Header Information Overview

The File Header Information section of an IBIS file contains keywords that are related to information for the overall file such as the file name, the referenced IBIS version, and so on.

IBIS Version

The [IBIS Ver] keyword defines the IBIS version of the overall IBIS file and must be a valid IBIS Specification version such as 2.1, 3.2, 4.0, 4.1, 4.2, and 5.0. The IBIS version is used by different simulation tools and parsers to map the IBIS Specification structure to the model data so this is a very important keyword.

This keyword also has the unique privilege of having to be the first keyword listed in an IBIS file.

Comment Character

The [Comment Char] keyword defines the comment character that can be used in the IBIS file. By default it is the ‘|’ character but other characters as referenced by the IBIS Specification can be used. However most simulation tools and parsers rely on the fact that the default comment character is the ‘|’ character and it’s not recommended to use a different comment character for interoperability reasons.

An example line from an IBIS file using the default comment character could look like the following:

| This line is a comment line in an IBIS File

File Name

The [File Name] keyword defines the name of the actual IBIS file with an .ibs extension. An important thing to note here is that the filename used in the [File Name] keyword must match the actual file name of the IBIS file. For example, if the IBIS file is test.ibs than the [File Name] keyword must be ‘test.ibs’ as well. This may seem like it should be common sense but often times the actual file name of an IBIS file will be different from the [File Name] keyword because model developers do not know of the IBIS Specification syntax rules.

The [File Name] keyword also falls under some general syntax rules listed in the IBSI Specification. These general syntax rules define things like how long a file name can be, reserved keywords, case sensitivity, and so on. In most cases using a common sense approach with naming and character conventions will be adequate but if you run into syntax issues when running quality checks you should review the general syntax section of the IBIS Specification to make sure you are compliant.

File Revision

The [File Rev] keyword defines the revision level of the IBIS file. This keyword is useful for revision control tracking for quality control purposes. While the IBIS Specification does not dictate a set of values to use the following recommended version levels are offered as a guideline: File Revision Description 0.x Silicon and file in development 1.x Pre-silicon file from silicon model only 2.x File correlated to actual physical silicon measurements 3.x Mature product (no more changes likely) I often recommend to clients that they try and map the above guidelines to their internal pre and post silicon release schedule to better fit how their company actual does internal revision control.

Date

The [Date] keyword defines the date of the latest revision of the IBIS file. This keyword is subject to the general syntax rules as well in terms of the total character count.

Source

The [Source] keyword defines the original source of the IBIS data. Typical usage of this keyword is to state whether the IBIS file data was generated from SPICE level models, lab measurement data, or another source.

Notes

The [Notes] keyword defines a section of the IBIS file where notes or comments can be placed. This is a very useful keyword to place all sorts of extra information about the IBIS file such as any reasons why the IBIS file fails the IBIS parser, special usage situations for the IBIS file, or anything else that might be important for someone using the IBIS file for simulation.

Disclaimer

The [Disclaimer] keyword defines the model developer’s disclaimer about the IBIS file. Most often this is where the legal stuff goes about liability and usage. If you are developing a model and giving it out to customers on behalf of your company make sure to consult with your legal department to ensure you have the correct verbiage otherwise you may be getting a visit from a lawyer.

Copyright

The [Copyright] keyword defines the copyright of the model developer.

Using Package Data in IBIS Files

The Component section of an IBIS file is really all about defining the package of the device. The package pin parasitic data and device pin out are included in this section. The data in the Component section is also important because a lot of companies use this data to categorize and archive the IBIS files along with their PCB designs in their specific CAD environment.

Component

The [Component] keyword defines the name of the device that the IBIS file is representative of. Often the vendor part number is used. The IBIS Specification allows for multiple [Component] sections to be present. Each [Component] section should represent a different package of the same device.

There are two sub keywords under the [Component] keyword called Si_location and Timing_location. These sub keywords can be set to either Pin or Die and are used by some simulation tools to automatically select the probe location for timing and signal integrity measurements.

The above image shows an example IBIS file in an IBIS editor application. The tree pane on the left hand side gives a structural view of the different IBIS keywords and the right hand side displays the actual keyword definitions. In the above example, sample data has been placed to demonstrate just the component section of an IBIS file.

Manufacturer

The [Manufacturer] keyword defines the name of the IBIS model vendor.

Package

The [Package] keyword defines the global package pin parasitic values in terms of resistance, capacitance, and inductance. These global package pin values can be used to represent the typical, worst, and best cases for all of the pins in the entire device. The sub keywords are R_pkg, L_pkg, and C_pkg with the first column represented by typical values, the second column represented by minimum values, and the third column represented by the maximum values.

Pin

The [Pin] keyword defines the device pin out, maps the signal pins to the IBIS buffer models, and the individual pin parasitic values. The [Pin] package parasitic values override the global [Package] parasitic values.

The first column under [Pin] is used to define the package pinout as referenced in the device datasheet and corresponding to the actual device. For example, if the pinout of the device is a six pin device and the first pin is number one than you would define it as ‘1’ as seen in the above example. It’s important that this pinout section of the IBIS file matches the actual physical device as well as any associated CAD part since some simulation tools use the CAD part to map to the IBIS file in simulations. This means you need to include all power, ground, signal and no connect pins as well.

The next column is ‘signal_name’ and this column allows the model developer to define a signal name for the associated pin. Again this should correspond to the actual device so if Pin 1 is PCI0 than the signal name should reflect that.

The third column is ‘model_name’ and this model name needs to correspond to a [Model] name defined in the same IBIS file. For example, if Pin 1 is mapped to model ‘output’ there needs to be a [Model] output in the same IBIS file. The IBIS Specification uses special reserved keywords for the power, ground and no connect pins that are POWER, GND, and NC.

The last columns R_pin, L_pin, and C_pin are used to define the individual package pin parasitic values.

Package Model

The [Package Model] keyword defines a package model name that is used elsewhere in the IBIS file to define the package parasitic values in matrices format. Consult the IBIS Specification for more details on how to include this type of package model in an IBIS file.

Differential Pin Mapping

The [Diff Pin] keyword defines a differential signal based upon the existing [Pin] data section. In earlier versions of the IBIS Specification there was no need for differential signals so only single-ended signals were considered in the specification. As differential signaling become more popular support was added to the IBIS Specification. The [Diff Pin] keyword allows the model developer to use the pins defined in the [Pin] section to create a differential signal in an IBIS file. This can be either an input or output differential signal.

The [Diff Pin] keyword defines the non-inverting differential pin and the inv_pin sub keyword defines the inverting differential pin.

The vdiff sub keyword defines the differential input receiver voltage threshold. For a non input differential signal this value should be set to 0 V.

The tdelay* sub keywords define the launch delays of the non-inverting differential pins relative to the inverting differential pins. For an input differential signal the values should be set to NA since they are not used.

Series Pin Mapping

The [Series Pin Mapping] keyword defines a series buffer model that is associated between two signal pins. This keyword was added for series elements so a model developer can create a series buffer model like a resistor and then tie two pins together so they will use the series model in simulation.

The [Series Pin Mapping] keyword defines the pin in which the input impedance is measured. The pin_2 sub keyword defines the other pin that makes the other connection for the series model. The model_name sub keyword defines the model to map the series pin to and this model needs to exist in the same IBIS file. The last sub keyword function_table_group defines an alphanumeric designator that used to associate those sets of Series_switch pins that are switched together.

The [Series Pin Mapping] keyword works for a broad range of series elements and we’ll cover some specific cases in later chapters.

Series Switch Groups

The [Series Switch Groups] keyword defines the allowable switching combinations of series switches described using the names in the [Series Pin Mapping] keyword section using the function_table_group sub keyword.

Model Selector

The [Model Selector] keyword defines a list of [Model] calls rather than a signal call so the user can select which one to use. This allows the model developer to use one model_name in the [Pin] section such as ‘programmable1’ to represent several different [Model] calls that a user can choose from.

The [Model Selector] keyword needs to be the same name as defined in the model_name sub keyword in the [Pin] section. Under the [Model Selector] keyword the actual [Model] call in the same IBIS file needs to be used and the second line is a description line to let the user know what the model represents. Refer to the previous image on how the [Model Selector] keyword works.

Where the Real Model Data Goes

The [Model] keyword in IBIS is where the IV and VT data that represents a buffer resides. This is the real meat and potatoes of an IBIS file and the most important part so we are going to go over it in detail.

The above image shows just the [Model] section from an IBIS file. In the left hand pane the hierarchy structure can be seen where there are different sub keywords that are dependent on the [Model] keyword. The [Test Data] keyword is a special keyword we will cover separately. In the right hand pane the different keyword and sub keywords can be seen along with the data.

Technically, according to the IBIS Specification, [Model] is a keyword but so is [Voltage Range] and others. While they are both keywords the [Voltage Range] keyword and others only make sense when relative to a [Model] so that’s why the hierarchy is displayed this way.

Model

The [Model] keyword is the name of the buffer model and each model name has to be unique within the same IBIS file.

The [Model] keyword has the following sub keywords: Model_type, Vmeas, Cref, Rref, Vref, and C_comp.

Model Type

The Model_type sub keyword defines the buffer model type of the associated [Model]. The model types are defined by the IBIS Specification such as input, output, open_sink_output, and so on. It is important to have the correct model type defined so simulation tools can properly use the IBIS data. The full list of supported model types can be found in the latest IBIS Specification.

Input Thresholds

While not shown in the above example if the [Model] is an input or input/output type than the input thresholds Vinh and Vinl need to be defined. These thresholds are important because most simulators will use these thresholds by default for signal integrity timing and noise margin analysis.

Timing Reference Load

The Vmeas, Vref, Cref, and Rref sub keywords are used to define the manufacturer’s reference load used for AC timing definitions such as the Time to Clock Out delay. These sub keywords are critical to have for output models and we’ll devote a whole section to it later on in the book.

C_comp

The C_comp sub keyword represents the buffer die capacitance only and does not include the package. We’ll explain in a later section in more detail on how to obtain this parameter and why it is so important.

Model Spec Overview

The [Model Spec] keyword is associated with a [Model] call and it was added to later versions of the IBIS Specification to allow for more advanced sub keywords for a [Model] call. For example, let’s say that you have an input model with a DC input low threshold of 0.3*Vcc. However, the IBIS Specification only allows you to enter one Vinl threshold value under a [Model] statement. What you really want to do is to have a separate Vinl threshold value for each process corner since the Vcc value will change. By using the [Model Spec] Vinl keyword you can define a separate Vinl threshold value for each corner. A simulation tool will use the [Model Spec] Vinl value over the [Model] Vinl value if present.

There are a lot of [Model Spec] keywords so we won’t list them all but the following are a few of them and what they mean:

Vinh/Vinl: Input voltage thresholds

Vinh+/Vinh-/Vinl+/Vinl-: Input voltage thresholds for hysteresis

S_overshoot_high/S_overshoot_low: Static (DC) overshoot voltage thresholds

D_overshoot_high/D_overshoot_low: Dynamic (AC) overshoot voltage thresholds

Vmeas/Cref/Rref/Vref: Timing reference load (process corner specific)

Vmeas/Cref/Ref/Vref rising/falling: Timing reference loads for rising/falling edges (process corner specific)

Cref_diff/Rref_diff: Timing reference load for differential buffer (process corner specific)

Receiver Thresholds

The [Receiver Thresholds] keyword is like [Model Spec] in that it allows more advanced sub keywords for a [Model]. The [Receiver Thresholds] sub keywords are used to define the input switching thresholds of a buffer for advanced timing analysis like a DDR3 input buffer. These type of technologies require input thresholds that are sensitive to the supply reference and the [Receiver Thresholds] sub keywords provide the support for this.

Voltage Range

The [Voltage Range] keyword defines the voltage for each process corner that the IBIS data was generated from. If the device has an IO supply defined as 3.3 V +/- 10% then the Typical voltage value would be 3.3 V, the Minimum voltage value would be 2.97V, and the Maximum voltage value would be 3.63V.

Temperature Range

The [Temperature Range] keyword defines the temperature for each process corner that the IBIS data was generated from. Remember that for most common CMOS processes the Minimum corner will have the highest (hottest) temperature and the Maximum corner will have the lowest (coldest) temperature.

Pullup IV Curve

The [Pullup] keyword defines the voltage and current for each process corner for the buffer model driving high. This data has to be entered in a table format and remember that the Pullup IV data is Vcc relative.

Often times it is more useful to graph the IV table data and below is an example Pullup IV curve (Vcc relative) for a 3.3V CMOS driver. (Notice how the IV curve is not monotonic due to a slope change of the data near –Vcc. We’ll cover some of these quality issues later in the book.)

Pulldown IV Curve

The [Pulldown] keyword defines the voltage and current for each process corner for the buffer model driving low. This data has to be entered in a table format.

Below is an example Pulldown IV curve for a 3.3V CMOS driver.

Ground Clamp IV Curve

The [GND Clamp] keyword defines the voltage and current for each process corner for the buffer model ESD structure. This data has to be entered in a table format.

Below is an example Ground Clamp IV curve for a 3.3V CMOS input.

Power Clamp IV Curve

The [Power Clamp] keyword defines the voltage and current for each process corner for the buffer model ESD structure. This data has to be entered in a table format and it has to be Vcc relative.

Below is an example Power Clamp IV curve for a 3.3V CMOS input. Typically the Power Clamp current will be very small especially compared to the other IV curves.

Rising Waveform VT Curves

The [Rising Waveform] keyword defines the voltage and time for each process corner for the buffer model driving different loads with an input rising edge. Remember that the IBIS Specification does not put a limit on the number of VT curves you can have for a [Model] but most of the time you will only need two rising and two falling waveforms to get good accuracy. Each rising waveform VT curve has to be entered separately in the IBIS file using the [Rising Waveform] keyword.

Below is an example Rising Waveform VT curve for a 3.3V CMOS driver. There are two sets of VT curves shown here: one for a 50 Ohm to ground load and one for a 50 Ohm to VCC load.

Falling Waveform VT Curves

The [Falling Waveform] keyword defines the voltage and time for each process corner for the buffer model driving different loads with an input falling edge. Each falling waveform VT curve has to be entered separately in the IBIS file using the [Falling Waveform] keyword.

Below is an example Falling Waveform VT curve for a 3.3V CMOS driver. There are two sets of VT curves shown here: one for a 50 Ohm to ground load and one for a 50 Ohm to VCC load.

Ramp Data

The [Ramp] keyword defines the 20 to 80 voltage and time transition of a buffer output signal. Remember that the [Ramp] values are really just measurements from the Rising and Falling VT waveforms. For the Rising Edge the reference load is R_fixture to Ground (pullup on) and for the Falling Edge the reference load is R_fixture to Vcc (pulldown on) using 20 to 80 transition measurement.

Below is an example of the [Ramp] keyword and sub keywords from an IBIS file:

From the example above there are three sub keywords that need to be present in the [Ramp] keyword. R_load: This is the resistance value used to generate the VT data curve that the ramp measurements are measured from. dV/dt_r: The 20 to 80 voltage and time transition for the rising edge. dV/dt_f: The 20 to 80 voltage and time transition for the falling edge.

Test Data

The [Test Data] keyword defines voltage and time waveforms that represent the buffer model switching into a specific load from a source other than the IBIS data such as the original SPICE model or lab measured data. The [Test Data] keyword (or Golden Waveforms as they are sometimes called) is intended to be used to correlate the simulated IBIS model. The concept is pretty simple: if you just have an IBIS buffer model like a 3.3V CMOS driver and simulate it you will probably want to know if the simulated results are accurate. Since IBIS data is either derived from SPICE simulation or lab measurement by placing the Golden Waveforms in the IBIS file one can easily do the correlation.

The Golden Waveforms have to be in the form of rising or falling waveforms using the sub keywords [Rising Waveform Near], [Falling Waveform Near], [Rising Waveform Far], or [Falling Waveform Far]. The voltage and time data is entered in a table format. An example of a rising waveform for [Test Data] is given below.

The [Test Load] sub keyword is used to define the actual test load (such as resistors, transmission lines, etc) that the Golden Waveforms were generated under.




Learn How IBIS DRC Can Automatically Validate IBIS Models for Signal Integrity Simulation

IBIS DRC uses over 75+ built-in quality checks based off of the IBIS Specification and the IC vendor datasheet to provide a comprehensive quality report.