IBIS
Dealing with ringing and crosstalk in fast digital systems has never been an easy task. Especially today, with 150-MHz processors, new chips at 300-ps edge rates, and digital designers that want to carpet your board with 128-bit buses flying every-which-way. Sometimes, it's a wonder anything *EVER* works.
On top of that, every year, relentless progress in the density of high-speed integrated circuits makes the situation worse. You can literally watch it happening. To see the effect, compare a new PC motherboard today with one from just a few years ago. The new one will have a lot more terminators. That is the direct, incontrovertible evidence that signal integrity problems are growing more prevalent with every new product generation.
Whenever I speak to a group of digital designers, I ask "How many of you have ever had to add terminators to a board during debug to get it to work?" Without hesitation, everybody's hand goes up.
It's an endemic problem, and an indication of the rather crude state of the art of signal integrity design at many companies. Terminations are one of the key tools available to help fix problems with ringing, yet many digital designers don't know how to tell when ringing will occur, what kind of termination will be required to fix the problem, and where it must be placed.
Too often have I seen a board laid out with termination mounting pads provided on every net, with the assumption that a debug technician will test every signal by hand, apply terminators as needed, and then update the net list. Can't we do better than this? Isn't there some way to automate the process?
IBIS to the Rescue!
WHAT IS IBIS?
The I/O Buffer Information Specification (IBIS) is an international standard for the electrical specification of chip drivers and receivers. It provides a standard file format for recording parameters like driver output impedance, rise/fall time, and input loading, which may then be used by any software application.
The key parameters provided by an IBIS data file are ideally suited for automatic calculation of ringing and crosstalk.
WHO CREATED IBIS?
The IBIS specification was originally written by an industry group called the IBIS Open Forum. The latest version has now been adopted by the Electronic Industry Association as ANSI/EIA-656-1995, Rev. 2.1. The IBIS document may be obtained from any of the engineering document procurement services, like Global Engineering (U.S. 1-800-854-7179).
Keep in mind that IBIS, by itself, is nothing but a file format. It specifies *HOW* to record the various parameters of a chip driver or receiver in a standard IBIS file, but it does not specify *WHAT* to do with them once they have been recorded. That's up to the simulation tools that use IBIS models.
To effect practical simulations using IBIS, you will need four things:
- A source of raw information about your chip drivers and receivers,
- A way to translate that raw data into IBIS format,
- A machine-readable version of the trace layout you wish to simulate, and
- A software tool that understands IBIS, your trace layout format, and can do the calculations you want.
The following vendors are members of the IBIS Open Forum and (presumably) are in the process of producing IBIS-compliant tools and/or logic models.
Table 1—IBIS-compliant tool vendors
| Alcatel | AMP Incorporated |
| Anacad EES | Applied Simulation Technology, Inc (formerly Contec CAE, Ltd.) |
| Cadence Design Systems, Inc. | Cypress Semiconductor |
| Digital Equipment Corp. | EIA/Electronic Information Group |
| Hewlett-Packard/HP EEsof Division | HyperLynx |
| IBM Corporation | INCASES Engineering GmbH |
| Intel Corporation | Interconnectix, Inc. (now part of Mentor) |
| Mentor Graphics Corp. | Meta-Software |
| MicroSim Corp. | Mitsubishi Electric |
| Motorola | National Semiconductor Corp. |
| NCR Corporation | NEC Corporation |
| North Carolina State University | Quad Design Technology, Inc. |
| Quantic Laboratories, Inc. | Symmetry Design Systems, Inc. |
| Tanner Research, Inc. | Texas Instruments, Inc. |
| Thomson-CSF/SCTF | UniCAD Inc. |
| VeriBest Inc. | VLSI Technology |
| Zeelan Technology | Zuken-Redac |
WHAT IS GOOD ABOUT IBIS?
IBIS is a fairly simple, straight-forward file format. It is well-suited for use by Spice-like (but not Spice-compliant, because the file format is not directly readable by regular Spice) circuit simulation tools.
It provides a behavioral description of a driver or receiver without revealing proprietary details of how the circuit is internally fabricated. In other words, vendors can use IBIS models to specify how their great new gate designs work without giving away too much information to their competitors. Also, because it is a simplified model, it is reported to require on the order of 10x to 15x less computation time than an equivalent full-Spice transistor-level model when doing simple at-load simulations.
It provides for specification of a complete V-I curve for a driver in it's HI state, another V-I curve to represent the driver in it's LO state, and a way to morph from one to the other at a defined transition rate. The use of V-I curves is what gives IBIS it's ability to model non-linear effects like protection diodes, TTL totem-pole drivers, and emitter-follower outputs.
IBIS can be used to produce accurate, detailed simulations of high-speed ringing and crosstalk behavior. It can be used to examine signal behavior under worst-case rise time conditions, something impossible to manage with physical testing.
Lastly, because IBIS is a file format, not a procedural specification, we can use it for lots of stuff. Right now, it's being built into many of the tools we use on a daily basis. Don't be surprised if layout tools of the future calculate ringing and crosstalk on-the-fly, as you route traces, identifying and fixing signal integrity violations as they go, during auto-route.
WHAT'S WRONG WITH IBIS?
Of course, IBIS is not perfect. There are some problems, but, in my opinion, none significant enough to imperil IBIS' status as the best, most comprehensive, and genuinely useful piece of signal integrity technology to come along in a great while. With that said, here's my list of flaws:
First and foremost, there is a distinct lack of support for IBIS models among many chip vendors. And IBIS tools won't work without IBIS model files. It's true that IBIS files may be constructed by hand, or automatically converted from Spice circuits, but all the translation tools in the world won't help if you can't pry a minimum rise time number out of your chip vendor.
IBIS doesn't gracefully handle some forms of controlled-risetime drivers, especially those that incorporate sophisticated feedback circuits.
You will hear people say that IBIS is lacking in its ability to model ground bounce. What the IBIS model rev. 2.1 contains is a way to specify a mutual-inductance of various pin-pair combinations, from which can be extracted some very useful ground bounce information. What it doesn't do is model the way that large ground-bounce voltages can modify the behavior of an output driver as it moves from the HI state to the LO state.
I don't view any of these issues as major impediments to eventual acceptance of the IBIS technology. Most engineers today get almost no support when it comes to ringing, crosstalk, and ground bounce, and are suffering because of it. If IBIS helps, I say more power to it.
WHAT YOU CAN DO TO HELP
IBIS is coming. IBIS is going to solve a lot of common, everyday, high-speed design problems, but, first we have to get our chip vendors to provide IBIS model files for every part they make.
Next time you talk to a chip vendor about library files, please indicate your interest in IBIS. Let them know you think it's important. Let them know you need it. And, if you are planning to buy a lot of high-speed parts, let them know that you value working with a vendor that understands the importance of signal integrity in high-speed digital design.