Subject: Re: BIRD 42.3

From: "C. Kumar" <[email-masked]>
Date: Fri, 3 Oct 1997 09:28:39 -0400 (EDT)

DC:
I have not also had time to respond to bird 42.3. Your one specific example of zero current does not detract away  the utility of the original contention for current waveforms  in bird 42.3.  

IBIS metholody is a general black box methodology and should not be confined to the vagaries of specific technologies. 

Adding the current waveforms is relatively minor matter since during the spice runs the data is easily available. Redundacy in some cases does just not justify keeping out the data.
- kumar

> From [email-masked] Fri Oct  3 00:44 EDT 1997
> From: [email-masked] ( Bob Ross)
> To: [email-masked], [email-masked]
> Subject: Re: BIRD 42.3
> Content-Type: text
> Content-Length: 2935
> X-Lines: 83
> 
> DC:
> 
> I have been considering your response for quite a while.
> Here are some of my comments:
> 
> (1)  You have provided an interesting demonstration
> case where a two-waveform based IBIS model may be needed.
> 
> If you terminate the load to Vcc, then there will be
> no difference in theory.  However, if you terminate the
> output to some other voltage, you will see a difference.
> 
> (2)  It is also interesting that you pose the problem
> in terms of conductance variations (which could
> be implied by the IBIS architecture.)  It could
> have been presented in terms of resistance
> variations.  However, there would be an implied
> difference.  Pulldown one, for example goes
> linearly from 0 to 20 mS conductance.  If it
> were expressed as resistance, it would go
> non-linearly from infinite to 100 ohms to 50 ohms
> resistance.
> 
> (3)  I understand that there are other real world
> effects that can enter into the bounce analysis
> that may not show up in the IBIS model processing.
> I would still think that a delta current could
> still be used for some of these effects that
> are caused just by the device switching itself.
> 
> Bob Ross
> Inteconnectix
> 
> Date: Fri, 05 Sep 1997 12:23:45 -0700
> From: "D. C. Sessions" <[email-masked]>
> Organization: VLSI Technology Inc.
> 
> To: IBIS Mailing list <[email-masked]>
> Subject: BIRD 42.3
> 
> 
> As long ago promised, here's a talking case for BIRD42.3
> For simplicity, I've restricted the case to a very simple
> falling-edge behavioral model.  The driver in question
> is a 50-ohm switched resistor, with the following
> time/conductance tables.  The pulldown driver is common,
> but there are two different pullup responses:  All
> listed conductances are piecewise linear.
> 
>   Time  |  Pulldown   |	 Pullup #1  |  Pullup #2  |
>         | Conductance |	Conductance | Conductance |
> --------+-------------+-------------+-------------+
>    0 ps |     0 mS    |	   20 mS    |    20 mS    |
>  500 ps |     0 mS    |	   20 mS    |    20 mS    |
> 1000 ps |     0 mS    |	   10 mS    |    20 mS    |
> 1500 ps |     0 mS    |	    0 mS    |     0 mS    |
> 2000 ps |    10 mS    |	    0 mS    |     0 mS    |
> 2500 ps |    20 mS    |	    0 mS    |     0 mS    |
> 3000 ps |    20 mS    |	    0 mS    |     0 mS    |
> 
> As is typical for real-world drivers, these are
> break-before-make.
> 
> *IF* the load had time to settle completely to zero
> current before the next edge, there would be no
> difference between them; however, in real high-speed
> switching even unterminated lines take too long to
> settle and thus the pullup is still sourcing current
> when this schedule starts. Obviously, a terminated
> line is even worse; either way the turnoff of the
> pullup has important consequences.
> 
> IMNSHO, this effect is far more important than the
> (extremely rare) case of major crowbar current,
> and any solution to this will necessarily also take
> care of those few instances where crowbar current
> is actually significant.
> 
> -- 
> D. C. Sessions
> [email-masked]
>  
> 
>

---

From: "Richard A. Schumacher" <[email-masked]>
Date: Fri, 03 Oct 1997 14:25:23 CDT

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?

---

From: "D. C. Sessions" <[email-masked]>
Date: Fri, 03 Oct 1997 12:56:15 -0700

C. Kumar wrote:
> Bob Ross wrote [attribution restored -- dcs]:
> > D. C. Sessions wrote [attribution restored -- dcs]

> I have not also had time to respond to bird 42.3. Your one specific example of zero current does not detract away  the utility of the original contention for current waveforms  in bird 42.3.

Speaking as an I/O designer, we work *very* hard to avoid crowbar
current.
This is not just a matter of a specific example; it's the majority case.
IMNSHO, an extension to the standard which *only* addresses cases with
major crowbar current is best described as "one specific example."

Parsimony dictates that we *not* extend the standard willy-nilly;
if there are two possible extensions, one of which is only marginally
applicable to a rare condition and another which addresses both that
*and* the majority case, the latter is always to be preferred.

> IBIS metholody is a general black box methodology and should not be confined to the vagaries of specific technologies.

True enough, but its relevance escapes me..

> Adding the current waveforms is relatively minor matter since during the spice runs the data is easily available. Redundacy in some cases does just not justify keeping out the data.

I could name a thousand "minor matters" which might be nice to have in
one-of-a-kind
situations.  We're not adding them because their net impact on the
usefulness of the

> > care of those few instances where crowbar current

Real-world, IMMEDIATE applications such as SSTL can't be properly
modeled right now without addressing the case I presented.  (look
back at the time-domain behavior and see what it implies when
applied to a line terminated to Vddq/2)  This isn't something we
can blow off by pretending it's a rare case.  We *need* to
address the issue.  When we have, we'll also have a solution to
the (rare) crowbar-current problem as a freebie.

So what are we going to do?

---

From: "D. C. Sessions" <[email-masked]>
Date: Fri, 03 Oct 1997 13:22:42 -0700

> 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.

---

From: "Richard A. Schumacher" <[email-masked]>
Date: Mon, 06 Oct 1997 9:26:50 CDT

> 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.

---

From: "D. C. Sessions" <[email-masked]>
Date: Mon, 06 Oct 1997 07:43:47 -0700

> developer before handing over circuit designs and operating

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
[email-masked]