|
What Is IBIS
The most simple way to summarize the I/O Buffer Information Specification
(IBIS) is as a syntax for describing the analog electrical behavior of digital
buffers. In essence, IBIS allows semiconductor (IC) vendors, electronic design
automation (EDA) tool vendors and system designers to exchange human-readable
information about digital device behavior for use in analog signal integrity simulations.
Though many features have been added and many new applications supported
over the years, this core intent of the specification has remained constant.
Managing the IBIS Specification Standard
The IBIS Open Forum (sometimes “IBIS Committee”) is the organization that
maintains and improves IBIS as a standard. The group meets regularly by teleconference
to discuss and vote on specification improvements, plus address technical
questions. The Open Forum also organizes regular IBIS Summits, now worldwide,
to allow IBIS enthusiasts to meet face-to-face and discuss techniques and challenges.
The Golden Parser
In the early days of IBIS, the original Open Forum members believed that the
rules of IBIS would be difficult to apply without a way to verify that the keywords
and other structures were being used correctly in a given IBIS file. A software
program -- the Golden Parser -- was created to allow any author or user of an IBIS
file to check the file’s syntax. The program checks keyword spelling, placement
and other simple rules plus some of the more complex relationships between data
structures required for a useful model. As IBIS has been updated over the years,
so has the Golden Parser, so that the IBIS community can rely on having the tool
available when new specification versions are released. The parser is still distributed
free of charge to the industry, compiled for a number of operating systems.
The source code is made available for purchase under license, for those wishing to
integrate the parser functions into their own software.
Overview of ICM
ICM, the IBIS Interconnect Modeling specification, was originally proposed
some years ago as a way to describe connector electrical behavior in a standard
form. Once the specification was close to completion, we realized that the description
applied just as well to general interconnects, such as cables or printed circuit
board traces. ICM became an “Interconnect Modeling” rather than a “Connector
Modeling” specification. Though technically separate from IBIS, ICM uses a similar
keyword-based format and is also now a US national standard. ICM differs from
IBIS in that it is tailored specifically for transmission line descriptions, whether as
frequency-dependent RLGC matrices or as S-parameters. We are very pleased to see
EDA tool adoption of ICM picking up in recent months, and have been informed that
the format is now being used for device package modeling in the industry.
IBIS Quality Issues
“IBIS quality” is a broad concept that is gets applied in the industry to both
individual models and sometimes to parts of the specification itself. For individual
models, one can consider the IBIS Quality Specification and Checklist, the Golden
Parser and the IBIS Cookbook as key resources to help IBIS authors create better
IBIS files and system designers verify, at least in part, the IBIS files they receive. The
IBIS Open Forum also has a number of task groups working to assist the industry
to address IBIS modeling issues. The IBIS Quality Task Group maintains the Quality
Specification and Checklist and is now in the process of a keyword-by-keyword
review of the main IBIS specification for areas of improvement where quality checks
can be applied. The IBIS Review Committee, a group of volunteers from individual
EDA member companies of IBIS, will review and provide individual comments upon
IBIS files submitted to the Committee. Finally, the membership itself frequently
exchanges information and tips through the IBIS e-mail reflectors. The biggest
challenges remain raising awareness in the industry of these resources and of how
simple quality assurance can be when the right methods are used to generate IBIS
files.
IBIS Extensions
The original IBIS specification and its subsequent revisions, through 4.0, were
all built around a core set of assumptions about modeling buffers: namely that
one could describe a buffer completely through a set of I-V tables (to represent its
strength), a set of V-t tables (to represent its speed or transition behavior) and a
capacitance (to represent its impedance, whether driving or receiving, in combination
with the I-V tables). When this data is provided across process, voltage and
temperature variations, it provides a powerful “snapshot” of a buffer for use in
simulation without compromising design details. For certain designs, particularly
those with more complicated analog behaviors -- for example, significant variation
in capacitance, self-tuning terminations and the like -- providing a simple snapshot
may not be sufficient. Yet, even with this limitation on representing some design
types, the IBIS format provides significant amounts of information for the component
separate from the individual buffers that make it attractive as a data-exchange
format for designers: pin lists and mapping to individual buffer designs, package information,
signal names, input thresholds and output delay characterization loads.
For this reason, IBIS moved to a hybrid approach for representing devices, where the
buffer description is replaced with more flexible analog and, optionally, digital HDL
code but the surrounding measurement and component information is preserved.
IBIS: Past, Present, and Future
IBIS 4.1 and 4.2 standardized this hybrid approach, so that layout-based analysis
could continue with IBIS, but the flexibility of the buffer descriptions is enhanced.
What’s New in IBIS 5.0
IBIS 5.0 will be a major advance on a number of levels. The specification
introduces the Algorithmic Modeling API (AMI), a way to describe transmit and/or
receive equalizers using compiled code linked to IBIS through a defined application
programming interface (API). This allows system designers and EDA vendors to
make use of the complex equalization schemes now being implemented for multigigahertz
buffer designs while preserving the proprietary nature of the specific
semiconductor design implementations. This is an extension of the original intent
of IBIS into today’s very fast SerDes interfaces and is also part of the kind of hybrid
approach IBIS used to include HDLs and Berkeley SPICE support under IBIS 4.1 and
4.2.
IBIS 5.0 also adds two key enhancements to the traditionaltable-driven analog
description approach. The first adds information on gate modulation effects for
individual buffers, so that the impact on the buffer output of variations in driver
PMOS or NMOS gate voltages, for example, can be captured and included in signal
integrity simulations. The other enhancement adds power rail impedances and
time-based current tables, correlated to the output V-t tables, to individual buffers.
This enables much better power delivery and SSO simulations than have been
previously been possible with IBIS.
All of these enhancements mean that IBIS will continue to be both relevant and
useful to the industry in the years ahead.
Michael Mirmak holds a BSEE from the University of Pennsylvania and is a member
of the IEEE Standards Association and the Design Automation Standards Committee.
He has been employed at Intel Corporation since 1996, developing platform signal
integrity guidelines and models for both processor and chipset products, and has been
a participant in the IBIS Open Forum since 2000 and has been the organization’s chair
since June of 2003. During his tenure, the IBIS Open Forum released the IBIS 4.1, 4.2,
ICM 1.0 and ICM 1.1 specifications, to which Michael made significant contributions.
|
Magazine 
