Subject: confusion about c_comp

From: Betty Luk <[email-masked]>
Date: Wed, 20 Dec 2000 13:37:28 -0500

Hi,
 
I am a bit confused about c_comp.  C_comp is the silicon die capacitance,
which includes the parasitic capacitance of the buffer, the bond wire and
the die pad capacitance.  When the Spice simulations are run to generate the
IBIS data, the effects of the c_comp parameter should already be included
(since you can't take away the parasitic capacitance of the circuit).  So
when the [c_comp] keyword is specified, isn't the effect of c_comp
double-counted?
 
For example, when I generated my IBIS model, I estimated the value of the
bond wire and die pad capacitance, and added that as an explicit capacitance
to the buffer output before using Spice to extract data.  Then I estimated
the value of parasitic capacitance of the buffer circuit (as described by
Arpad Muranyi).  The total [c_comp] value is the sum of bond wire and die
pad capacitance, and the parasitic capacitance of the circuit.  Is this
approach correct?
 
I would really appreciate any feedback.
 
Thanks very much,
Betty Luk

---

From: "Ingraham, Andrew" <[email-masked]>
Date: Wed, 20 Dec 2000 15:07:51 -0500

> the die pad capacitance.
 
I would not have included the bond wire capacitance, because the bond wire
is part of the package (although the position of the capacitance relative to
L_pkg may make this debatable).  I think c_comp would apply to just the bare
die, even though the IBIS spec does not explicitly say so.

> When the Spice simulations are run to generate the IBIS data, the effects
> of the c_comp parameter should already be included (since you can't take
> away the parasitic capacitance of the circuit).  So when the [c_comp]
> keyword is specified, isn't the effect of c_comp double-counted?
 
By specifying the c_comp keyword, you are providing the IBIS-aware simulator
with the equivalent capacitance that you had in your SPICE simulations.
That is the only place in the IBIS data where this capacitance exists!  I
don't see how there is any double-counting.

> bond wire and die pad capacitance, and added that as an explicit
> capacitance to the buffer output before using Spice to extract data.  Then
> I estimated the value of parasitic capacitance of the buffer circuit (as
> described by Arpad Muranyi).  The total [c_comp] value is the sum of bond
> wire and die pad capacitance, and the parasitic capacitance of the
> circuit.  Is this approach correct?
 
If your SPICE model is complete enough to include die bonding pad
capacitance (and bond wire capacitance if you determine that it should be
part of c_comp too), then whatever value of capacitance you extract from
your SPICE simulations *IS* the value for c_comp.  You would not add a
correction factor to account for the die pad capacitance.  If, on the other
hand, your SPICE simulation doesn't include the die pad, then you should add
it to the extracted capacitance to get the c_comp value for the IBIS data.

However you do it, c_comp should represent the effective on-die capacitance.

Andy

---

From: "Ingraham, Andrew" <[email-masked]>
Date: Thu, 21 Dec 2000 09:13:45 -0500

> > Any simulator that uses the V/T data, must be careful enough to use
> > it correctly!
> > ...
> 
> It is actually very difficult to implement it correctly.
 
Yes, I'm sure it is!

> 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,
 
?  The pullup/pulldown (I/V) data is DC data.  C_comp is irrelevant, it has
no effect on the pullup/pulldown data.  Maybe I misunderstood you.

Regards,
Andy

---

From: "Muranyi, Arpad" <[email-masked]>
Date: Thu, 21 Dec 2000 12:47:16 -0800

Hello,

To sum this problem up, I usually say that C_comp needs to
be visible from the outside looking in, but invisible from
the inside looking out.

Here is how I did it in my HSPICE implementation (before the
B-element came out).  I used PWL sources to contain the I-V
and V-t tables and some additional controlled sources to do
the math between these.  C_comp was a normal capacitance
connected to the end of all this.  If I would have left it
this way, I would have indeed double counted for C_comp,
because the shape of the V-t curve in the PWL source already
includes its effect.  Yet I knew I had to have that capacitor
there, because a reflection that hits this (driving) buffer
will bounce back from it differently if it was not there.

This is what I did to remove the double counting.  I connected a
duplicate C_comp on the output of the PWL source(s) which had the
V-t curve(s).  Then I just simply included an additional term
in my math which combined the I-V and V-t curves so that the
current of this duplicate capacitance was subtracted from the
total result.  I know this will have some error as the actual
waveform deviates from the V-t curve, but this error is smaller
than double counting C_comp (zeroing it out).

Of course, when you write the code of your simulator you have
much more control over writing an algorithm that does a better
job than this.

Arpad Muranyi
Intel Corporation
================================================================

-----Original Message-----
From: Christopher Reid [mailto:[email-masked]]
Sent: Thursday, December 21, 2000 9:02 AM
Cc: [email-masked]
Subject: Re: confusion about c_comp

Hello IBIS land,

I don't see this as confusing at all.  The VT curves are what the
simulator should produce under the load conditions specified in
the IBIS model for each curve.  The simulation vendor must devise
an algorithm to "make it so."

The C_comp must be in place during the actual simulation because
it will affect the results in different ways for different loading
conditions.

Chris Reid
Mentor Graphics

"Lorang, David D" wrote:
> 
> This is a great thread!  I think many of us, both SI tool users and
> simulator developers, have struggled with this Ccomp problem.
> 
> It is possible to match up the V-T curves using a piecewise linear ramp
> waveforms, various controlled voltage or current sources, and perhaps some
> resistors, but no storage elements.  If the simulator produces its
internal
> model to match the waveform in this manner, then afterwards adds Ccomp to
> the model, then the Ccomp has been double counted and the final model
would
> be in error.
> 
> What should happen is that the simulator should match the IBIS waveform
> using all of the ramps, sources, resistors, but with Ccomp in place also.
> Then, because Ccomp is already in place in the simulator's internal model,
> it must not be added in again.
> 
> I have seen this problem, when trying to correlate IBIS based models with
> the transistor level simulations they were developed from.  You see the
> problem when waveforms do not correlate unless the Ccomp is manually
"zeroed
> out" in the model.
> 
> I'm not sure we can fault the vendors too much because it is easy to get
> wrong and the IBIS Specification standard does not spend a lot of words
> explaining all of this.   Perhaps some more clarification in the IBIS
> Specification standard is in order.  Further thoughts?
> 
> Best regards,
> Dave Lorang
> 
> -----Original Message-----
> From: Ingraham, Andrew [mailto:[email-masked]]
> Sent: Thursday, December 21, 2000 7:14 AM
> To: [email-masked]
> Subject: RE: confusion about c_comp
>