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

From: Arpad Muranyi <[email-masked]>
Date: Fri, 01 Nov 96 10:50:00 PST

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 [email-masked]

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: "[email-masked]'" <[email-masked]>
From: "Boeckmann, Ed (Edward F)" <[email-masked]>
Message-ID: <c=US%a=_%p=INTERGRAPH%l=[email-masked]
o
m>
Received: by hq15.pcmail.ingr.com with SMTP (Microsoft Exchange Server Internet
Mail Connector Version 4.0.994.57)
     id <[email-masked]>; 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 <[email-masked]>;
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: [email-masked]

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 <[email-masked]>
Encoding: 6326 Text
From: "Hilbers, Alex" <[email-masked]>
Date: Wed, 30 Oct 96 10:55:41
.2/8.7.3) with SMTP id CAA10896 for <[email-masked]>; Wed, 30 Oc
t 1996 02:55:31 -0800 (PST)
Received: from mailbag.jf.intel.com ([email-masked] [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: [email-masked]

---

From: Arpad Muranyi <[email-masked]>
Date: Fri, 01 Nov 96 13:25:00 PST

Text item: 

Dileep,

IBIS allows you to define up to a maximum of 100 waveform tables (V-t curves) in
each buffer model.  Each of these V-t tables have their own subparameters, such 
as Rfixture, so you can make a model which provides a series of V-t curves for 
the various loading conditions.  Is that not enough for what you are trying to 
achieve?

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

Arpad Muranyi wrote about the simulator being smart enough
to fit an equation to the given data. The point I am trying
to make is that sufficient data need to be provided. For
example, a straight line is the simplest curve in two dimensions.
The equation of a straight line has two unknowns. Therefore,
at least two data points or two pieces of information are needed.
There are infinite ways of drawing a straight line thru a single
point. There is no unique way of defining a straight line in this
case no matter how smart the fitting method is. Thus, given only
one V-t waveform, it is not possible to predict many V-t waveforms
for all possible loading conditions.
------------------------------------------------------------
Dileep Divekar
Applied Simulation Technology, Inc.
2188 Bering Drive
San Jose, CA 95131

Phone - (408)-434-0967 x 100
Fax   - (408)-434-1003
Email - [email-masked]
------------------------------------------------------------

Cc: [email-masked]
Subject: Re: Re[3]: Rising Waveform Loading Effects: smart simulator
To: [email-masked]
From: [email-masked] (Dileep Divekar)
Date: Fri, 1 Nov 1996 12:26:43 +0800
.org (8.7.3/8.7.3) with SMTP id MAA10182 for <[email-masked]>; Fri, 1 Nov 1996 12
:50:28 -0800 (PST)
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 MAA25117; Fri, 1 Nov 1996 12:43:55 -0800 (PST)
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 MAA16766; Fri, 1 Nov 1996 12:43:54 -0800 (P
ST)
Return-Path: [email-masked]

---

From: [email-masked] (Dileep Divekar)
Date: Fri, 1 Nov 1996 14:57:49 +0800

Arpad,

>the various loading conditions.  Is that not enough for what you are trying to 

At the risk of repeating myself, the point I was trying to make was IBIS does
ALLOW the model developer to specify 100 waveforms, but does not REQUIRE the
waveform tables to follow certain restrictions or conventions.
Therefore, is it then acceptable for each simulator to enforce its own
REQUIREMENTS making IBIS models simulator dependent?
Earlier, it was pointed out that if ONE waveform into ONE RESISTIVE load is
specified, it is possible to predict the waveforms into any load. Then that
particular simulator HAS to make sure that the waveform is specified into a RESISTIVE
load, whereas, the IBIS specification ALLOWS the waveform specification
into ANY load. What is the simulator expected to do if the model developer
specifies the waveform into ANY load since that is ALLOWED by IBIS and hence
it is a legal IBIS model?
------------------------------------------------------------
Dileep Divekar
Applied Simulation Technology, Inc.
2188 Bering Drive
San Jose, CA 95131

---

From: Stephen Peters <[email-masked]>
Date: Fri, 01 Nov 1996 18:41:04 -0800

Hello Arpad, Dileep, others:

     I think Dileep's basic point has been missed, and it really needs
to be responed to.

     Yes, as in Dileeps example of a V/T curve into a 
complex reactive load, it *is* possible to create a perfectly 
legal yet totally useless (to him, anyway) IBIS model.  It
is also possible to make a model that produces different
results on different simulators.  IBIS models are, to some
extent, simulator dependent. However, I'd like to point out
that in both these cases the model would also be useless to the 
model provider (i.e. silicon vendor). The whole point of this exersise 
it to produce simulation models others can use.  It is incumbent 
upon the model provider to both produce a model that works with 
industy simultors and to validate/spec whatever model they provide.
(That, by the way, goes for both transistor level as well as IBIS model).
It is also incumbent upon the simulator vendors to stay current with
the spec and the technology.

     I might also note that the IBIS committee has always relied on the simulator
manufactures to tell us what kind of data is required for acurate 
behavioral simulation.  If a simulator vendor belives that the spec
is inadiqute(sp), or doesn't provide the right kind of data, they should
speak up.  By the same token, the IBIS committee should be listening....

                    Regards,
                    Stephen Peters
                    Intel Corp.

Arpad,

particular simulator HAS to make sure that the waveform is specified
into a RESISTIVE