FreeLists / si-list / [SI-LIST] Re: IBIS Driver Models, Simulators and CComp

[Roy_Leventhal@xxxxxxxx]

Todd,

About 4 years ago I ran simulations to check on the effects of Ccomp on
reflection. I proved to my personal satisfaction that Ccomp could be
"double counted" if care wasn't taken with the simulator code. To check a
given simulator I just varied the value of Ccomp from a "high" value to a
vanishingly small value. I expected driver rise time at the pad to not
change if the simulator was implemented correctly.

By double counting I specifically mean when Ccomp modifies the output V-T
curve (or, for that matter, slew rate). As you state, the effects of Ccomp
are already included in the driver output V-T. How could it be otherwise?
Wouldn't make sense not to.

Double counting, as we both know, leads to false results by attenuating
high frequency components of the time domain pulse. Therefore, the faster
the driver and the more complex the topology, the more pronounced the
effect on reflections, crosstalk and EMI.

As you point out, Ccomp is needed to correctly simulate the situation when
load reflections reach the driver and (usually) get re-reflected. Ccomp
can, and should vary, depending on whether the driver is on or off. As
well, Ccomp depends on the technology, drive conditions, the
presence/absence of elements such as active clamping, etc., and is the
total capacitive loading seen from the driver/receiver pad to ground. Not
just the die capacitance. That total loading is what I'm trying to take
into account from a circuit point of view.

All this variation in Ccomp presents a challenge to any behavioral
simulator as opposed to SPICE, a circuit element and physical condition
simulator. But, using SPICE on verification of our 5000+ net boards is
unacceptable from a run time standpoint. Perhaps the different values for
Ccomp wasn't important in the past. But, as the speed and complexity
envelope gets pushed - - - .

What do you think of the idea of a table of Ccomp values for the simulator
to select from? The real challenge will be in getting model providers to
consistently supply correct values.


Best Regards,

Roy







"Todd Westerhoff" <twester@xxxxxxxxxxx>@freelists.org on 01/09/2002
04:47:20 PM

Please respond to twester@xxxxxxxxxxx

Sent by:  si-list-bounce@xxxxxxxxxxxxx


To:   <si-list@xxxxxxxxxxxxx>
cc:
Subject:  [SI-LIST] IBIS Driver Models, Simulators and CComp



Hi all,

We've been doing an investigation recently, comparing IBIS models and
simulation results to their HSpice counterparts.  One of the things that
has
emerged as a focal point is the concept of Ccomp (the die capacitance) and
how the IBIS simulator handles it for a driving output.

Ccomp (as I understand it) is meant to represent the intrinsic parasitics
of
the I/O cell.  As such, it isn't anything that can be precisely identified
in the Spice model of the I/O - rather, Ccomp models the cumulative effect
of a bunch of things.  That being the case, the V-T curves created for the
IBIS model using Spice will already have the effect of Ccomp included.  If
the IBIS simulator adds a Ccomp capacitor across the IBIS driver's output,
the effect of Ccomp may be "double-counted" when the device is driving.

On the other hand, if the capacitor is not added to the circuit - then the
reflections off the driver will be incorrect, because the driver's output
capacitance will not be modeled.

So the question(s) are -

a) Have other people run into this issue?
b) I suspect the handling of Ccomp for an IBIS driver is EDA tool
dependent.
Does anyone know how the different tools handle this?
c) Are there applications > 150 MHz where people are using IBIS and HSpice
interchangably?  If so, how are the correlation issues between the two
simulators managed?

One problem that seems especially insidious (we're still not sure of
exactly
what's going on) is that we have a bidirectional I/O whose effective
capacitance seems to be different in the driving and tri-stated conditions.
Given that IBIS allows only one value for Ccomp, that makes correlation
even
more challenging.

All responses, public and private - are both welcomed and appreciated.

Todd.


Todd Westerhoff
SI Engineer - Hammerhead Networks
5 Federal Street - Billerica, MA - 01821
email:twester@xxxxxxxxxxx - ph: 978-671-5084
============================================

"Oh, but ain't that America, for you and me
 Ain't that America, we're something to see
 Ain't that America, Home of the Free
 Little pink houses, for you and me"

- John Mellencamp




------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List archives are viewable at:
          http://www.freelists.org/archives/si-list
or at our remote archives:
          http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
          http://www.qsl.net/wb6tpu






------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List archives are viewable at:     
                http://www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages 
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu