Re[2]: BIRD 42.3

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
dc.sessions@tempe.vlsi.com
Text item: External Message Header
The following mail header is for administrative use
and may be ignored unless there are problems.
***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
References: <199710031328.JAA10440@hot.Cadence.COM>
Subject: Re: BIRD 42.3
CC: ibis@eda.org, bob@icx.com, cpk@hot.Cadence.COM
To: "C. Kumar" <cpk@cadence.com>
MIME-Version: 1.0
X-Mailer: Mozilla 4.02b7 [en] (X11; I; SunOS 5.5.1 sun4m)
Organization: VLSI Technology Inc.
From: "D. C. Sessions" <dc.sessions@tempe.vlsi.com>
Date: Fri, 03 Oct 1997 12:56:15 -0700
Message-ID: <34354DDF.C69CC504@tempe.vlsi.com>
Sender: dc.sessions@tempe.vlsi.com (D.C. Sessions)
Received: from tempe.vlsi.com ([134.27.133.12])
          by mailserver.tempe.vlsi.com (Netscape Mail Server v2.02)
          with ESMTP id AAA14946; Fri, 3 Oct 1997 12:56:15 -0700
Received: from mailserver.tempe.vlsi.com (mailserver.tempe.vlsi.com [134.27.128.
5]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/101195) with ESMTP id MAA141
49 for <ibis@eda.org>; Fri, 3 Oct 1997 12:56:17 -0700
Received: from anubis.tempe.vlsi.com(134.27.128.1) by tweety.vlsi.com via smap (
V2.0)
     id xma027249; Fri, 3 Oct 97 12:56:19 -0700
Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050
895) id MAA27356 for <ibis@eda.org>; Fri, 3 Oct 1997 12:56:35 -0700
Received: from relayhost.vlsi.com (tweety.vlsi.com [134.27.20.23]) by server.vhd
l.org (8.8.5/8.8.3) with ESMTP id NAA05399 for <ibis@eda.org>; Fri, 3 Oct 1997 1
3:11:06 -0700 (PDT)
Received: from server.vhdl.org (server.vhdl.org [198.31.14.3])
     by hebe.or.intel.com (8.8.6/8.8.5) with ESMTP id NAA18598;
     Fri, 3 Oct 1997 13:33:52 -0700 (PDT)
Received: from hebe.or.intel.com by relay.hf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0xHERU-000qDSC; Fri, 3 Oct 97 13:35 PDT