Re[3]: Rising Waveform Loading Effects: smart simulator

Text item:

Alex,

Actually the situation is not as complicated as you might think. I will try to
illustrate it with an example. When you do curve fitting to an equation, you
usually have an idea whether the curve is exponential, sinusoidal, or whatever.
So you pick an equation, and then apply coefficients to it so that it fits the
data. With a second order polynomial eqation you would have:

                   k1*x^2 + k2*x + k3

In this equation, the x variables determine the general shape of the curve and
the k factors modify it so that it fits the data. This is the principle I have
in mund when I talk about the V-t curves. The simulator tools should have their
algorythms, which would be the equivalent of the x variables in the above
example, and the data, being the equivalent of the k factors, should alter the
basic algoruthm to the particular buffer characteristics. I would call a
simulator "bad" if it would, for example, simply copy the V-t data to become the
output waveform. On the other hand, I would call a simulator "good" if it used
the data in its algorythms in a processed "smart" way.

However, since I am not a simulator tool programmer, I do not want to go into
this topic any further. I will let those take over this conversation, who are
experts at it.

Arpad
==============================================================================

Arpad,

concerning your point:

"What I mean by this is, that if the simulator is smart enough, it can take the
data and modify it, derive new curves, etc. So, if you have an I-V curve and a
V-t curve which was generated with 50 Ohm resistive load in the model, a good
simulator should derive a new V-t curve that matches the different load
resistance in that particular simulation. Taking this further, the simulator
could make V-t curves with reactive loads also. In general, then,
the simulator can simulate at each iteration with a different set of curves that
matches any loading condition, even if the "load" is another non-linear I-V
curve. The point here is that the data in the IBIS model is not supposed to be
a limiting factor to what the simulator does with it."

To me this seems to suggest - correct me if I am wrong - that the non linear
time dependant behaviour that is not modelled by the Ibis model is
to be derived by a good simulator. Isn't it easier to use a Spice model together
with a normal simulator? In that case you don't have to go through the trouble
of converting Spice design models into Ibis models, followed by making the
simulator 'good'. Conversion may introduce errors and especially derivation of
curves looks tricky. In the end this may not be faster than using the Spice
models in the first place.

Could you give me more insight on this matter?

Alex

Text item:

Ed,

Your concern is well taken. However, I would like to point out that an IBIS
model is nothing but data. The V-t curve in the IBIS model is not supposed to
be the same as the simulation waveforms, unless the load is identical to the
load that was used to generate the V-t curve. The simulator can do
anything to
this data.

What I mean by this is, that if the simulator is smart enough, it can take the
data and modify it, derive new curves, etc. So, if you have an I-V
curve and a
V-t curve which was generated with 50 Ohm resistive load in the model, a good
simulator should derive a new V-t curve that matches the different load
resistance in that particular simulation. Taking this further, the simulator
could make V-t curves with reactive loads also. In general, then,
the simulator
can simulate at each iteration with a different set of curves that matches any
loading condition, even if the "load" is another non-linear I-V curve. The
point here is that the data in the IBIS model is not supposed to be a limiting
factor to what the simulator does with it.

Of course this is not the only way things can be done, I was just trying to
illustrate the concept.

The reason resistive (and not reactive or transmission line) loads
are preferred
for generating V-t curves is that with a resistive load we get only what the
buffer does. With other types of loads we get what the load does also. Why
would one want to add all that to the V-t curves when it will have to be taken
out anyway to model just the buffer alone?

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

Hello to all,

I am concerned about the validity of using IBIS models for general
printed circuit board signal analysis in an environment of various types
of loads, transmission lines, vias, pads, connectors, various
terminations, etc.

According to the IBIS specification V2.1 dated Dec. 13, 1995, for a
rising waveform (for example), there are various loads specified as
L_dut, R_dut, L_fixture, R_fixture, C_dut, and C_fixture. In addition
data is to be taken with the effects of C_comp included. There is
however no provision for generating curves with a transmission line load
which is more typically the case, especially for high speed circuits. in
actual circuit boards.

It is well known however, that the ramp rate and levels reached will be
affected by the loads. For example, changing the values of R_fixture
and V_fixture on a typical buffer. (The s2ibis2 program will generate
different curves for different values of R_fixture, for example IBIS
curves for 50 ohms and 100 ohms is generated from a command file that
specified curves for 50 and 100 ohms.)

My question is this: If in an actual simulation environment we really
have a different loading condition with transmission lines , vias, etc.,
how can we legitimately use an IBIS model that was generated with a
different lumped element loading condition ?

I hope someone can help me to understand how the IBIS models will
accurately produce the correct physical response with an arbitrary but
realistic loading condition, different from the test fixture, at least
to a level of accuracy close to that which would result from the
original transistor level spice model, say within 5%.

Ed Boeckmann, "My comments reflect solely my own opinion!"
Intergraph Corp.
Huntsville AL 35894
tel. (205)-730-6219
fax (205)-730-6000
email efboeckm@ingr.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***.

Encoding: 41 TEXT
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.57
Date: Thu, 24 Oct 1996 10:25:42 -0500
Subject: Rising Waveform Loading Effects
To: "'ibis@vhdl.org'" <ibis@vhdl.org>
From: "Boeckmann, Ed (Edward F)" <efboeckm@ingr.com>
Message-ID: <c=US%a=_%p=INTERGRAPH%l=HQ1-961024152542Z-18203@hq15.pcmail.ingr.c
o
m>
Received: by hq15.pcmail.ingr.com with SMTP (Microsoft Exchange Server Internet
Mail Connector Version 4.0.994.57)
     id <01BBC195.E3DA6810@hq15.pcmail.ingr.com>; Thu, 24 Oct 1996
10:26:59 -050
0
Received: from hq15.pcmail.ingr.com (hq15.pcmail.ingr.com [129.135.251.243]) by
vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA29698 for <ibis@vhdl.org>;
Thu, 24 O
ct 1996 08:37:41 -0700 (PDT)
Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com
(
8.7.6/8.7.3) with ESMTP id IAA14618; Thu, 24 Oct 1996 08:30:29 -0700 (PDT)
Received: from ormail.intel.com (ormail.intel.com [134.134.248.3])
by relay.jf.i
ntel.com (8.7.4/8.7.3) with ESMTP id IAA00404; Thu, 24 Oct 1996 08:30:29
-0700 (
PDT)
Return-Path: owner-ibis@vhdl.vhdl.org

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

Subject: Re[2]: Rising Waveform Loading Effects: smart simulator
To: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
Message-Id: <9609308467.AA846701741@uucpgt.tulip.nl>
Encoding: 6326 Text
From: "Hilbers, Alex" <AHilbers@tulip.nl>
Date: Wed, 30 Oct 96 10:55:41
Received: from cc:Mail by uucpgt.tulip.nl
     id AA846701741 Wed, 30 Oct 96 10:55:41
Received: from uucpgt by tulip6.tulip.nl id aa02913; 30 Oct 96 12:04 WET
Received: from tulip6 by ns.NL.net (5.65b/NLnet1.3)
     id AA09526; Wed, 30 Oct 1996 11:07:58 +0100
Received: from ns.NL.net (ns.NL.net [193.78.240.1]) by mailbag.jf.intel.com (8.8
.2/8.7.3) with SMTP id CAA10896 for <Arpad_Muranyi@ccm.fm.intel.com>; Wed, 30 Oc
t 1996 02:55:31 -0800 (PST)
Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4])
by fmmail.fm.intel.com (8.7.4/8.7.3) with ESMTP id CAA08890 for <Arpad_Muranyi@c
cm.fm.intel.com>; Wed, 30 Oct 1996 02:52:14 -0800 (PST)
Return-Path: ahilbers@tulip.nl
Received on Fri Nov 1 11:06:22 1996