Re: BIRD 42.3

Richard A. Schumacher wrote:
>
> > > In other words, different applications require different
> > > device models. Even one given circuit will require
> > > different models depending, as in the example, on whether
> > > the time between output transitions is greater than or less
> > > than the settling time. True?
> >
> > That's one way. (For those joining late: Mr. Schumacher refers
> > to the problem where an output is still sourcing current into
> > an unsettled line when it switches LOW. The pullup turnoff
> > will produce one output step, followed some time later by the
> > pulldown turnon step.)
> >
> > Far more serious, I would tink, is the situation in terminated
> > lines (eg, SSTL) where the line NEVER quiesces to a zero-current
> > state. For a whole lot of reasons, the output will almost
> > always do a two-step: first to the OFF state and then to the
> > reverse state. The difference between this and the academic
> > smooth-transition model is pretty significant.
>
> So, to get a correct IBIS driver model for a given situation,
> a user must either
>
> (a) ask the device vendor to run the vendor's SPICE model
> driving the user's desired circuit at the desired switching
> rate, capture the i-v curve for that circuit and package the
> curve as an IBIS model, or
>
> (b) ask a model developer to attach a real device to the
> desired circuit, switch it at the desired rate, capture
> the i-v curve, and package the curve as an IBIS model.
>
> If best- and worst-case temp/process/SSO models are desired then
> the above must be repeated for each condition. Repeat the above
> for each additional desired switching rate of the circuit; and
> again for each new circuit which the device might be used to
> drive. That entire family of curves then becomes one IBIS model
> for one user.
>
> A user might have the vendor/developer capture the waveforms
> at all the pins of the circuit and save himself the trouble
> of repeating the simulation/measurement. Prudence requires
> executing an NDA with the device supplier/third party model
> developer before handing over circuit designs and operating
> conditions.

The problem isn't with the v/i curves, it's with the
time-domain behavior. Actually, performing the v/t
curve capture with the output terminated to vddq/2
would solve most of the problems, since that way you
get to see the transition from pullup to pulldown and
back again.

-- 
D. C. Sessions
dc.sessions@tempe.vlsi.com