(no subject)

From: Greg Doyle gdoyle@intgrty.mn.org

Subject: Including Vt, Cref, Rref & Vref in IBIS models

I support adding this information to the IBIS models
for the following reason(s). People use signal
integrity tools for many different reasons. Some use
them for up front rules generation, some for back end
signal integrity verification and (ugh!) people use
them for debug. The byproduct of the powerful
capabilities we all provide to the users is that they
can get timing delays for the interconnects and then
use them to check system level paths. We have all read
the papers showing how as the clock speeds go up, the
interconnects start to become the critical path. This
makes the ability for a SI tool to easily fit into the
design process more important.

As a result of this, system designers see the signal
integrity tools as satisfying two needs. One is to
give the circuit designer a toy to play with. The
second is to get the circuit designer to get accurate
delay values back into a system timing simulation.
One of the problems with doing this over time
has been that the delay through SSI devices were
typically specified at a predetermined load
condition, typically 50pF and perhaps a pullup
resistor or diode. This was done to give some
guard band for the testing environment and also
to give the design engineer some margin to
account for a "representative" load seen by the
driver in an application.

Unfortunately, this method is somewhat dated as a high
speed driver sees a transmission line, not a lumped
load. Many devices today are characterized at no load
because the SI tools will allow the designer to
calculate the interconnect delays, where in the past
they were not available. Secondly, the tester
environments look nearly invisible to a driver under
testing conditions, so the need to add guard banding is
gone.

To simply add the interconnect delay defined as
the delay from the output of the driver to the
input to a receiver to the part delay would
create the situation of double counting.
Therein lies the problem. Different tools try
to account for this in different ways. The
common piece of information needed to try and
adjust for this is the loading conditions for
the delay characterization
measurements/simulations.

So after all of this testimonial, what I am saying is
that SI tools are being used for a variety of purposes
today. IBIS was designed to allow these SI tools be
used with much more ease. Namely, to prevent users
from having to build/edit models by hand. This has
been a barrier to making SI tools proliferate. As time
goes on, speeds will increase, making the role of the
SI tools even more tied to system level timing
analysis.

To allow IBIS to be used as it is perceived,
"Everything you need to define a part", we must be
open to allowing new parameters be supported by the
IBIS model. The users are going to demand this
from the committee when they get IBIS models and
then are asked to edit/supplement them with
additional information.

As users join the forum, they will demand that the IBIS
spec be extended to make all databook parameters used by
a SI tool available (and required?). This makes the IBIS
model as transparent to the user as possible.
Typically, the functionality of the device is supplied
to the user in a Verilog or VHDL model, thus it is not
important to include this.

What John Keifer proposed was to make these parameters
optional. It is my feeling that IBIS should be extended
to include as much databook information about a part as
possible. If a simulation tool does not use certain
information, it should skip over the data. This
philosophy allows the user community to benefit the most
from the models. If they have to continually add and edit
the vendor supplied model to fit into their simulator,
IBIS will lose its appeal and we will all lose.

OK, I'll shut up for now.

Greg Doyle
Received on Thu May 12 13:12:15 1994