Re[2]: Rising Waveform Loading Effects

Text item:

Dileep,

If we go by your suggestion, we would have to specify every simulation algorythm
in IBIS. The tool vendors would not subscribe to that, as I see it. Even the
way IBIS is now with some of the rules on how I-V curves "must" be handeled was
debated at length in the Open Forum meetings. I am referring to the clamp
curves being subtracted from the pullup and/or pulldown curves, and the Vcc
relative notation, for example.

Take, for example, the Vcc-relative curves in IBIS. My intension was to enable
GND bounce and Vcc droop simulations by properly referencing which pin these I-V
curves get their currents from, with the added benefit of a nice symmetry.
Also, with this notation all pullup curves go through the same point when Vds is
0, regardless of what the Vcc voltage is for each given curve (typ., min.,
max.), just like in the case of pulldown curves. This makes it a lot easier to
compare them with each other.

However, since it is fairly unusual to say that the origin of the plot is not at
the GND potential, but at Vcc, many people have (or had) problems with this
notation. (Even though ECL or the old tube technology does basically the same
with all those negative voltages). Anyway, this and similar issues prompted
lengthy debates on what the "right" way of doing things is. One argument I
heared frequently was "give me raw data, and my tool will do the necessary
things to it the way I believe is the right way".

This is just an example for why you can't specify in the IBIS spec what the tool
should do with the data. Tool vendors want to be able to differentiate
themselves from others, because they believe they know it better how to do it
right. And there is nothing wrong with it. The customer has to figure out
which tool he believes before he invests.

And, again, IBIS is not a device physics algorythm spec, but a data format spec.

Now, if there is something missing in it in order to be able to simulate
correctly with the given data, we can consider to add new data definitions to
it. One example for this with respect to the V-t curves was the attempt to add
a keyword that defined whether the device was CMOS or Bipolar. I don't remember
where that issue stands now, but it seems to me that it was dropped.

Without trying to be funny or sarcastic(!) this situation is similar to
politics. Which is better, dictatorship, or freedom? In dictatorship you loose
your freedom, but everything is unified, controlled, etc. In freedom you loose
control, and things have a tendency to become caotic, etc.

Anyway, since I am getting outside the range of my expertise, I better shut up
and let the experts take over this topic.

Sincerely,
Arpad Muranyi
Intel Corporation
===============================================================================

Chris Rokusek, Quad Deisgn Technology wrote:
>
>There are a few "dimensions" of knowledge not explicity present in the
>.ibs model which may be useful to a simulator:

That is precisely my point. You are making certain assumptions and guesses,
which are OUTSIDE the ibis specification. In fact you are trying to guess
the information which ibis is trying to hide. What do you do if you encounter
some data which does not fit any of your guesses?

All the knowledge "dimensions" should be utilized in developing the
specification,
but once the specification is developed, it should have any loose ends.

Let us assume that you have a simulator which can predict waveforms for any
arbitrary load, given ONE waveform for one RESISTIVE load. But the ibis
specification does not specify that. A model developer can specify a waveform
into a general RLC load (as shown in the example on page 19 of 2.1
specification)
and claim that they have provided a perfectly legal ibis model and now it is
up to the simulator to do the rest. What does
the simulator do in this case with the waveform with all the ringing,
overshoot,
undershoot etc.? The simulator should not place restrictions in ADDITION to
the ibis specification. Therefore, if one waveform into one resistive load
is all that is required, then it should be stated explicitly. Otherwise
different people can make different assumptions and guesses. If certain things
are REQUIRED to carry out a simulation, then the ibis model should SPECIFY
those things instead of leaving them to guesswork.
------------------------------------------------------------
Dileep Divekar
Applied Simulation Technology, Inc.
2188 Bering Drive
San Jose, CA 95131

Phone - (408)-434-0967 x 100
Fax - (408)-434-1003
Email - dileep@apsimtech.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***.

X-Sun-Charset: US-ASCII
Cc: dileep@contec.Apsimtech.COM
Subject: Re: Rising Waveform Loading Effects
To: ibis@vhdl.org
Message-Id: <9610301630.AA20030@contec13.contec.COM>
From: dileep@contec.Apsimtech.COM (Dileep Divekar)
Date: Wed, 30 Oct 1996 08:30:53 +0800
Received: by contec13.contec.COM (5.0/SMI-SVR4)
     id AA20030; Wed, 30 Oct 1996 08:30:53 +0800
Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1)
     id AA15156; Wed, 30 Oct 96 08:22:05 PST
Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1)
     id IAA26120; Wed, 30 Oct 1996 08:27:06 -0800
Received: from netcomsv.netcom.com (uucp7.netcom.com [163.179.3.7]) by vhdl.vhdl
.org (8.7.3/8.7.3) with SMTP id IAA13026 for <ibis@vhdl.org>; Wed, 30 Oct 1996 0
8:53:35 -0800 (PST)
Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c
om (8.8.2/8.7.3) with ESMTP id IAA21097; Wed, 30 Oct 1996 08:51:43 -0800 (PST)
Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4])
by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id IAA21725; Wed, 30 Oct 1996 08:
49:09 -0800 (PST)
Return-Path: owner-ibis@vhdl.vhdl.org
Received on Fri Nov 1 12:10:12 1996