> > [wrt: IBIS v/t curves modelling crowbar current in CMOS]
> > > This is not really true. The V/T curve in the IBIS model definition does not
> > > give any information about the PMO/CMOS overlapped current.
> > > The V/T describes the behavior of the buffer output versus frequency but does
> > > not give any information on the current passing internaly through the output
> > > transistors.
> > > To know the value of the through current it is necessary to know the "Ron"
> > > variation of the two transistors during the transition periode. The value of
> > > this current depends upon the equivalent impedance of the two transistors,
> > > impedance which is connected between Vdd and Vss power supply.
> > The IBIS v/t curves (four, note: one each with the load to power
> > and one with the load to ground for both rising and falling edges)
> > give the full picture. The turnon of the pullup device is given
> > by the rising edge/grounded load curve; the turnoff of the pullup
> > is given by the falling edge/grounded load curve. The turnon of
> > the pulldown device is given by the rising edge/pullup load curve;
> > the turnoff of the pulldown is given by the falling edge/pullup
> > load curve. Crowbar current on the rising edge is just the
> > overlap between the pullup turnon and pulldown turnoff, and on
> > the falling edge between the pulldown turnon and pullup turnoff.
> > Also, the crowbar current in CMOS outputs (esp. tristate ones, and for
> > practical purposes that means all of them) is very low by design. At
> > least the ones I design are, and I have yet to see any others that act
> > differently. Unlike internal gates output drivers have separate paths
> > for turning on the pullup, turning off the pulldown, turning on the
> > pulldown, and turning off the pulldown. As a result it's easy to turn
> > the driver devices OFF faster than ON, and since crowbar current not
> > only wastes power but slows down the buffer I have a hard time imagining
> > a competent designer shipping a driver that has more than trivial
> > crowbar current.
> Excuse my ignorance D.C. but I thought the V/T curves are a function of
> voltage vs time during the respective tr/tf periods.
Voltage vs. time *into a load*, and the timescales are
supposed to match up.
> By itself this
> represents a behavior for the given load and the given load only. In the
> past the V/T curves were used by the simulation vendors as a means to
> coorelate the data. In other words one could look at the v/t data and
> make it match IBIS under that load. Now enter 4 v/t curves. We can use
> the data to test and make that match IBIS. But now the final output wrt
> v/t will depend on the vendors interpretation, algorithms, topology,
> and the phase of the moon. There seems to be a lot of decisions that
> need to be made left up for grabs. Although my company attends the
> IBIS meetings I do not. Is there talk of publishing final V/T curves
> for say a resistively unloaded device for example. This would serve as
> a means of coorelation for the vendors sake.
One reason for loading the driver during derivation of v/t curves is
that outputs typically go through a very high-impedance state when
both devices are OFF. In this time other signal sources such as
gate coupling can have a large effect on the output voltage despite
the fact that the signal source doesn't have the v/i characteristics
of the IBIS driver.
Without going into the other uses of the v/t curves, they *can* be used
to answer the present question, PROVIDED that the test load is heavy
enough to be meaningful (A 10Kohm load isn't going to tell us much
about the characteristics of a driver with an Rdson of twelve ohms.)
The reason that this is so straightforward is that the crowbar
current only flows for a brief time when both devices are nearly OFF
anyway, so they are in deep saturation and thus the drain currents
are pretty much independent of voltage.
> One problem I see is that the v/t information by itself does not contain
> the current information.
Sure they do, it's just Ohm's Law: Id = Vout/Rload
> That's buried in the I/V information. In fact
> we can only get the answer for the given loads not dynamically.
Without feedback, Norton models seem to work pretty well.
> presumption seems to be based on pullup/pulldown simple topologies. In
> fact I can tell you we are dealing with very complex I/O stages with
> feed backs,
Eeeeyeew! Feedback! Feedback is evil. Bad driver, BAD.
Go to bed without stability. Naughty, naughty, naughty.
Well, OK, that's overstating it. Sometimes feedback is
not only useful but necessary; it still makes behavioral
modelling (a la IBIS) pretty well impossible. IMNSHO, this
is more annoying than crippling since feedback has other
properties that limit its usefulness in applications where
signal integrity is a major concern, so giving up behavioral
modelling of feedback-controlled drivers is (again, IMO) no
> multiple current switching techniques, and the like. I don't
> see such a simple solution to this problem. Real devices seem to be much
> more complex and dynamic than IBIS can support.
Well, that's certainly true -- for instance, IBIS can't really deal
with JEDEC flexible-impedance drivers, and I'm writing THOSE into
the IEEE 1394b spec. Great fun. Still, we need to keep in mind that
the more exotic variants that you and I deal with are of very narrow
application. Most people don't encounter anything but the vanilla
CMOS device, and for *that* the simple v/t analysis I presented is
quite adequate. Actually, even for the exotica you mentioned it
will give a pretty good idea of the crowbar current. Oddly enough,
the flex-z stuff is one of the ONLY cases it won't do well.
-- D. C. Sessions firstname.lastname@example.org