|
IBIS
(Originally
published in Printed Circuit Design
Magazine, April, 1997)
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. Thats 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.
| 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
doesnt 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 dont
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.
|