Subject: Re[2]: BIRD 42.3

From: Stephen Peters <[email-masked]>
Date: Mon, 06 Oct 1997 08:55:25 -0700

Hello Arpad, all:

   In your comments below you ask if it would be appropriate to
add some clarification (regarding including four v-t curves in a
CMOS model) to the spec.  The latest edition of the cookbook does
explicitly make this recomendtion.  In general I'm in favor of
making specific modeling recomendations in the cookbook, and not
the spec itself.

            Regards,
            Stephen Peters
            Intel Corp.

======================================================================
On Fri, 03 Oct 97 14:52:05 Arpad Muranyi wrote:

Text item: 

All,

I have been following this discussion, but didn't reply for a while because it 
wasn't entirely clear what the real issue was (is).  Now it seems that D. C. 
Sessions' example really addresses the issue of modeling the turn-off 
characteristics of a transistor.  This is important - as he says - when the 
signal didn't settle yet, or when there are DC currents through resistive 
terminations of some sort.

In the days when we were working on the 2.0 specification and were discussing 
the usage and implementation of V-t curves in the Open Forum meetings I brought 
up something that may apply to this issue.  In those days we decided not to put 
it into the spec for various reasons, but now it seems that we probably should 
have addressed the issue somehow.

My goal was to use the V-t curves for characterizing both the turn-on and 
turn-off behavior of the transistors.  Starting with the assumption that 
designers try to avoid crowbar currents like a plague, one can see why 
transistors get usually turned off much quicker than turned on.  Now, if I 
generate a rising V-t curve with a resistor to GND, I will get the turn-on 
characteristics of the pullup transistor.  However, if I generate a rising V-t 
curve with a resistor to Vcc, I will get the turn off characteristics of the 
pulldown transistor (because the resistor will pull the voltage high before the 
pullup transistor even started to turn on).

This is why my IBIS models have four V-t curves for a CMOS buffer and two for a 
GTL buffer.  With the appropriate combinations of Vfixture and Rfixture values I
am describing the turn-on and turn-off characteristics of the transistors.

In my behavioral HSPICE I/O buffer model this is how I use the V-t curves, and I
get the kind of results one would get in real life.  If I have a resistive 
termination to Vcc/2, I would normally see a quick edge to Vcc/2 and then a bit 
later a slower edge towards the opposite rail.

If all simulators used these V-t curves the way I intended them to be used, I 
believe this discussion wouldn't be taking place now.

Now, the question is why doesn't the spec describe all this?  As I mentioned 
above, we talked about it, but decided not to write it down.  The reason was 
that there are always exceptions (as this discussion is also alluding to it) and
we didn't want to impose a possible limitation in the future by writing 
something this down.  It is very difficult to write a spec which is general 
enough and does not get outdated as technology evolves.

Would it be appropriate to add some clarifications to the spec?

Sincerely,

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

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
standard is *negative*.  Repeating what I wrote in the first place:

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

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?

--
D. C. Sessions
[email-masked]