Assume for a moment that and inductance model has been developed for
the chip/package/pcb system that correctly gives the loop inductance
for several IO switching at the same time. The chip ground node will
bounce up when the IO edges fall; the chip vdd node will bounce down
when the IO edges rise. The IV curves given in IBIS data sheets
correctly give a reduction in driver output current due to the bounce
on the power rails.
For example, when a driver switches from high to low, the voltage on
the NFET source rises (voltage drop across ground inductance),
reducing the sink current of the NFET. This is a negative feedback
mechanism, similar to a source or emitter resistor.
But, the effect that has not been accounted for is the reduction in
gate drive for the NFET, sometimes known as overdrive voltage.
Assuming the FET is saturated, the traditional equation for drain
current is:
Ids = (u Cox / 2) * (W / L) (Vgs - Vt) ** 2
This equation accounts for the reduction of drain current as the the
overdrive (Vgs) voltage drops. The IBIS data sheets already give us
the Ids when power supplies are at their nominal value and Vgs can be
assumed to be the full power supply voltage. So, if Vt were known, we
could solve for a constant to replace (u Cox / 2) * (W / L). With
this addition to the IBIS data sheet, I believe it is possible to to
build an IBIS model that accounts for SSN.
I like to distinguish between IBIS data sheets and IBIS models.
Models are executable in a circuit simulator. John Lin asked a very
pertinent question today:
> How do I construct a SPICE model from an IBIS model?
This may seem trivial, but in fact is the key to making IBIS account
for SSN. A circuit topology must be chosen that enables the model to
respond correctly to power supply collapse. The topology must include
the IV curves given in IBIS data sheets, modified by the reduction in
gate drive given above, as well as the ramp rate. I have not done
this in spice, but several years ago, I created a circuit topology in
IBM's circuit simulator (ASX) that would do this.
...This note is getting pretty long and has gotten off the topic of
output impedance (and besides, I am out of time). Perhaps we can
start a new thread called "SSN and IBIS models" and continue this
discussion at a later time. IBIS models that account for SSN would be
of great value to our industry.
regards,
Larry Smith
Sun Microsystems
> Date: Thu, 02 Apr 1998 08:29:58 -0700
> From: "D. C. Sessions" <[email protected]>
> MIME-Version: 1.0
> To: [email protected]
> Subject: Re: [SI-LIST] : Output Impedance
> Content-Transfer-Encoding: 7bit
>
> Brian Young wrote:
> >
> > I'm convinced IBIS works great if you have no rail collapse so that the IV
> > curves are valid. I don't think they are valid under heavy bus switching
> > with significant rail collapse, although I hear people claim otherwise. I
> > just don't see how IV curves provided at, say 3.3V, work when you have 0.5V
> > of collapse. Any comments?
>
> Almost always correct. For normal CMOS outputs, rail collapse steals
> gate
> drive and thus violates the assumptions used in creating the IBIS model
> in
> the first place. The only exception I know of is N-follower pullups,
> where the gate drive gets stronger as the rails drop. Combined with a
> regular P pullup this can be pretty much Vddq independent. (Doesn't
> help
> with the pulldown, though.)
>
> It's been suggested that semiconductor manufactureres (you and me,
> Brian)
> produce worst-case models that take into account SSO collapse. This
> isn't
> easy in IBIS as it stands because it involves multiple chip models for
> different conditions. If anyone has an inspiration on a way to extend
> IBIS to make this easier, by all means forward it to the IBIS forum:
> mailto:[email protected]
>
> > > ... I have compared the results of IBIS simulation to that of full
> > > HSPICE model simulation and hardware measurements for several different
> > > transmission line problems. IBIS model simulation compares very well to
> > > both.
>
> Certainly within the envelopes of device, dielectric, geometric,
> etc. tolerances.
>
> --
> D. C. Sessions
> [email protected]