Subject: RE: confusion about c_comp

From: "Ingraham, Andrew" <[email-masked]>
Date: Wed, 20 Dec 2000 17:03:17 -0500

> I think I might have used the wrong terminology.  By "bond wire", I
> actually
> meant the connection between the output of the buffer on the die to the
> die
> pad.  That's why I think that it should be included in the c_comp.
 
Yes, the "wiring" on the die should be part of c_comp.

> The effects of c_comp is already in the V/t waveform data.  The on-die
> capacitance is what causes the ramp, right?
 
It is part of it, but not all.  For example, capacitance in the pre-driver
stage may slow the edge rates of the waveforms at the gates of the output
transistors, causing the transistors to switch over a short time.  Even if
you could make them have a purely resistive load (i.e., make c_comp = 0),
the output edges would not be instantaneous.

> So if a simulator is not
> careful enough, and uses the value of c_comp along with the V/t data in
> the
> IBIS model, then the c_comp would be "double-counted".
 
Any simulator that uses the V/T data, must be careful enough to use it
correctly!

Whatever algorithm it uses, it must be able to duplicate the V/T data, by
simulating the device connected to the same elements (R_fixture, etc.).  If
it doesn't, the simulator's algorithm is wrong.

An explicit answer to your question is in the IBIS spec, in the section
about the V/T data:  "All tables assume that the die capacitance is
included."

Both c_comp and the V/T data do include the effects of on-die capacitance,
but that doesn't mean it is being double-counted.  
The V/T data includes the effects of many other parameters in the IBIS data
sheet, including the I/V data, the Voltage_Range, etc.  But the V/T data
doesn't REPLACE those other parameters.

Think of the V/T data as just another "measurement" of your device which is
already specified by all the other parameters.

Andy

---

From: Al Davis <[email-masked]>
Date: Wed, 20 Dec 2000 17:10:35 -0800

On Wed, 20 Dec 2000, Ingraham, Andrew wrote:
> Any simulator that uses the V/T data, must be careful enough to use
> it correctly!
>
> Whatever algorithm it uses, it must be able to duplicate the V/T
> data, by simulating the device connected to the same elements
> (R_fixture, etc.).  If it doesn't, the simulator's algorithm is
> wrong.

It is actually very difficult to implement it correctly.  I am 
curious how they all do in this matter.

C_comp is included in the V/T data, but it is not included in the 
pullup/pulldown data.  This means that to be truly correct, some kind 
of add and remove algorithm is needed, so it will be there at the 
ends, but not be double counted in the middle of the transition.  A 
truly correct implementation of c_comp will tend to magnify errors in 
the V/T data, making me believe that some kind of semi-correct 
implementation may actually be superior in practice.

Even without c_comp, the V/T support is trouble prone.  Sometimes it 
is necessary to tolerate some error in data matching in the interest 
of stability.  It is possible to supply multiple V/T tables that have 
conflicting data, or data that cannot actually happen with the simple 
topology of an IBIS model.  (Driver schedule, bus hold, dynamic clamp 
are all attempts to help in these cases.)  In these cases, often 
something needs to be sacrificed.  Some simulators try to fit the 
best they can, perhaps with some smoothing or other data munging.  
All reject waveforms that don't fit their algorithm.  Some are mpre 
picky than others.  Some just take the first one or two, regardless 
of what is best.  They all keep the details of the algorithm secret.