IBIS Modeling - Part 1: Why IBIS Modeling is Critical to Design Success

Displays the time when the model was created.

► Comments

Model Keywords: [Notes]

Provide customers with reference information about the model, i.e. whether the data was obtained from simulation or from benchmark measurements.

► Source

Model Keywords: [Source]

Where the model came from, or who the model provider is.

►Disclaimer ​

Model Keywords: [Disclaimer]

► Copyright

Model Keywords: [Copyright]

Note that the first three items listed under the main header file must be provided. The other items are not required but are good to include in order to provide additional details about the file.

Figure 5. Example of main header files in an IBIS model using Cadence Model Integrity

The second part of the IBIS model describes the component. This part requires the following data:

►Component Name

Model keywords: [Component]

As the name implies, this is the name of the device being modeled.

► Pin List

Model Keywords: [Pin]

In the model, this section has at least three columns: Pin Number, Pin Name, and Model Name. This list is based on the datasheet. Make sure that the pin number and pin name match correctly to avoid confusion. It is also important to note that in the IBIS model, each pin has a dedicated model name. This model name is not necessarily the same as the pin name given in the datasheet, as the model name of the pin is determined at the discretion of the model manufacturer. In addition, some pins may point to the same model name. This is the case for buffers with the same design schematic. They will have the same behavior, so one set of data is sufficient to represent them.

►Manufacturer ​

Model Keywords: [Manufacturer]

Identifies the manufacturer of the component being modeled.

►Package parasitic effects

Model Keyword: [Package]

Model keywords: [Package]

This item describes the electrical characteristics of the component package, including lumped resistance, inductance, and capacitance values. If the RLC parasitics of the pins are also known, they should be listed in the model along with the pin list under the [Pin] keyword. This provides a more accurate model and will override the RLC values ​​listed under the [Package] keyword.

Figure 6. Example of component description in an IBIS model using Cadence Model Integrity

The third part of the IBIS model describes the buffer model. This is where the behavior of the I/O buffer is presented, specifically its IV and Vt data. It begins by giving the model name using the [Model] keyword. The model name should be consistent with the name listed in the third column under the [Pin] keyword. For each buffer model, the parameter Model_type must be specified. The buffer capacitance must also be given under the parameter C_comp to describe the capacitance seen by the buffer from the pad end.

There are different types of buffers that can be modeled, and special rules apply to each type. The following describes the four most common types of buffers and their requirements in the IBIS model:

►Input Buffer

Model Type: Input

This model type requires input logic thresholds, listed under the parameters Vinl and Vinh. If not defined, the simulator uses default values ​​of 0.8 V and 2 V respectively. These parameters help the simulator perform timing calculations and detect signal integrity violations.

Figure 7. Example representation of an input buffer model using Cadence Model Integrity

► Dual-state output buffer

Model Type: Output

This model type represents an output buffer that is always enabled, either driven high or low. It includes timing test load values, listed under the parameters Vref, Rref, Cref, and Vmeas. These parameters are not required, but their presence in the model helps the simulator perform board-level timing calculations.

Note that since this type of buffer cannot be disabled, the keywords [Power Clamp Reference] and [GND Clamp Reference] are not listed, and the VI table data for [Power Clamp] and [GND Clamp] is not given.

Figure 8. Example representation of a two-state output buffer model using Cadence Model Integrity

► Three-state output buffer

Model Type: Three-State

This model type represents an output buffer that has not only a drive high and drive low state, but also a high impedance state because this type of buffer can be disabled. Like the output model type, it also includes timing test load values, listed under the parameters Vref, Rref, Cref, and Vmeas. Adding these parameters to the model helps the simulator perform board-level timing calculations.

Figure 9. Example representation of a tri-state output buffer model using Cadence Model Integrity

► I/O buffer

Model Type: I/O

This model type is a combination of an input and output buffer. Therefore, the model contains parameters such as Vinl, Vinh, Vref, Rref, Cref, and Vmeas.

Model manufacturers must pay attention to these guidelines when generating IBIS models. Further guidelines can be found in the IBIS Handbook on the IBIS Open Forum website. Proper modeling guidelines must be followed or the model will fail validation.

Figure 10. Example representation of an I/O buffer model using Cadence Model Integrity

Model Validation

Verifying the IBIS model consists of two parts: resolver testing and correlation processing.

Parser Testing

When building a model, it is best to use software that already has a Golden Parser, a program used to perform syntax checks and verify that the data of the created IBIS model matches the model version specification. Some software that has this feature are Cadence Model Integrity and Hyperlynx Visual IBIS Editor.

If the model passes the parser test, it means that the generated model follows the standard format and specifications, and the VI data matches the Vt data. If it does not pass, it is best to find out what is wrong. The simplest possible reason is that the format or keywords used in the model do not meet the IBIS specification, which is easy to correct. Other types of errors are VI and Vt data do not match. When this happens, the error can be in the pull-up or pull-down VI data, or in the Vt data. This is the case when the behavior represented by the VI data does not match the behavior represented by the Vt data. To fix this problem, you may need to re-simulate. But before doing so, first check the voltage and load values ​​placed in the model to see if they are correct. If the cause of the error is something simple like the voltage value was defined incorrectly, then you don't have to spend more time re-simulating.

Figure 11 and Figure 12 show examples of IBIS models that pass and fail the resolver test, respectively.

Figure 11. Buffer model that failed the parser test using Cadence Model Integrity

In Figure 11, notice how during the parser test, the software flags the errors that caused the model to fail. This makes it easy for the model manufacturer to correct the model errors before moving on to the next verification step. The cause of the error in this example is the incorrect model type used for the buffer. The IBIS specification requires that the I/O model type be entered in uppercase, but this figure uses lowercase.

Figure 12. Buffer model that passed the parser test using Cadence Model Integrity

Figure 12 shows a model that passes the parser test. Note that in the Model_type keyword, I/O has been changed to uppercase, which resolves the error.

Please note that only models that pass validation can enter the relevant processing.

Related processing

One might ask, how do you ensure that the generated model behaves exactly like the actual device? The answer is correlation processing.

IBIS models exist in different quality levels/relevance:

This article presents an IBIS model with a quality level of 2a. After passing the solver test, the model is simulated including RLC package parasitics and applied loads. The loads are typically timing test load values ​​found in the data sheet to characterize the I/O buffers. Similarly, the design schematic of the device will be simulated using the same setup and loads. The results of both simulations are overlaid to verify that the generated model behaves in accordance with the resulting behavior based on the schematic. The next article will present a use case for generating an IBIS model using open source software.

Why IBIS Models Are Important for Simulation

IBIS models are widely supported by most EDA vendors. They are easy to use and small in size, resulting in faster simulation times. They do not contain proprietary process and circuit information, and most semiconductor vendors are willing to provide IBIS models to their customers. They offer all of these benefits while accurately simulating the I/O behavior of the device.

Using IBIS models, designers can anticipate and resolve signal integrity issues without having to wait until the board prototyping or manufacturing stage. This allows them to shorten board development cycles, which in turn helps speed up time to market.

In short, customers use IBIS models because using them in simulation not only helps save costs, but also saves design and debug time, thereby generating revenue from board designs faster.

Here is a collection of IBIS simulation models for Analog Devices products.

References

Casamayor, Mercedes. AN-715—Approaching IBIS Models: What Are IBIS Models? How Are They Generated? Analog Devices, Inc., 2004.

IBIS Modeling Handbook (IBIS Version 4.0). IBIS Open Forum, September 2005.

IBIS Version 7.0. IBIS Open Forum, April 2020.

Roy Leventhal and Lynne Green. Semiconductor Modeling: For Signal, Power, and Electromagnetic Integrity Simulation. Springer, 2006.

About the Author

Jermaine Lim joined Analog Devices in October 2014 as a product applications engineer. Since then, her contributions to Analog Devices have focused on developing IBIS models for various ADI products. Jermaine graduated from Pamantasan ng Lungsod ng Maynila with a bachelor’s degree in electronics engineering. She can be contacted at jermaine.lim@analog.com.

Keith Francisco-Tapan joined Analog Devices in March 2012 as an analog design engineer. She initially developed IBIS models for various ADI products and mastered model development capabilities at ADGT. She now has a new role as a design verification engineer at AMS. She graduated from Mindanao State University-Iligan Institute of Technology with a bachelor's degree in electronic engineering. Contact: keith.francisco@analog.com.