From: kksys!intgrty!phil (Phil Kleineschay <kksys!intgrty!phil>)
Date: Thu, 12 May 94 11:50:34 CDT

From: Greg Doyle   [email-masked]

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