Re: Re[2]: BIRD 42.3

Arpad:

This is very important and should be added. This is the same reason I believe Dileep of Contec was saying about the multiple way of interpolating v-t curves. The problem is that even though you can provide many v-t tables there is no single unique mathematical solution. While IBIS on the one hand gives the notion of a black box. it certainly is not when it comes to v-t curves where it is subject to severe qualifying assumptions.

IBIS spec does not specify clearly the reason for the 4 v-t (not 10 or 100) curves.
It should abd the qualifying assumptions should be put on the table unambiguousely.

You can have problems with this assumption. Does the crow bar current assumption applies to ECL?

Thanx for clarification

- kumar

> From Arpad_Muranyi@ccm.fm.intel.com Fri Oct 3 17:58 EDT 1997
> From: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
> To: cpk
> cc: ibis@eda.org, bob@icx.com, cpk
> Subject: Re[2]: BIRD 42.3
> Content-Type: text
> Content-Length: 6830
> X-Lines: 149
>
>
> 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
>
 
Received on Sun Oct 5 04:43:56 1997