Subject: Re: Future directions for IBIS

From: Al Davis <[email-masked]>
Date: Thu, 2 Dec 1999 13:03:44 -0800

Try this:

(embellishing on the seed note by Stephen Peters)

The IBIS model is not truly behavioral, but a parameter
list for pre-defined structures.

Model ...
  input, output, i/o, open drain, etc.
Augmentations to the model ...
  driver schedule, bus hold, dynamic clamp ...
Containers ...
  component. package model, ebd, connector

We have all suffered through the need for yet another
structure to be added to the spec, or the discovery that
something is missing,  unclear, or difficult to implement.

My proposal is to have essentially two sections, a
parameter section functionally similar to the existing
IBIS, and a structure definition section that defines these
structures.  By doing this, this structure definition is
removed from the committee and simulator designer, and made
available to the model developer.  A netlist like language
could be used to define them.

To provide a migration path, and prove the appropriateness
of the new language, a set of structure definitions could
be provided with any conforming IBIS simulator, in the same
sense that any C compiler provides a standard library. 
These would be provided in source form so they could be
used by model developers as a prototype for developing
their new structures.  I have these for some of the ibis
model types.  So far, I was able to define structures that
can be expanded by an existing IBIS [Model] section, for
100% backward compatibility.

As an added benefit, we could provide these structure
definitions for 1.0, 1.1, 2.0, 2.1, 3.0, 3.1, 3.2 ...... 
with little additional effort.  All of the proposed BIRDs
can be added to the structure with trivial effort.

This structure should be netlist style, and can be inspired
by the Spice style.  As an alternate to providing a value
for any component, a parameter name could be specified. 
The values for the parameter would be provided in the
parameter section, which would look much like  the existing
IBIS format.  Parameters could be scalars, tables,
multi-dimensional tables, or equations.  They may or may
not have ranges, depending on the application.

Since this will be processed, the format does not need to
conform to any particular Spice implementation.  It can
provide component types and parameters that do not exist in
standard Spice.  It is not much work for a simulator
developer to add the necessary functionality to Spice.  It
also should be not much work to generalize the simpler
interconnect simulators to take these components.

Some elements to provide ...

The classic R, L, C, V, I, E, G .. both in the simple form,
with a value, and an advanced form where the value is a
parameter, for example ...

Rpu  (A1  A2)   I=pullup[V]

This says that the v/i characteristic of this "resistor" is
defined by a table called "pullup", which uses "V" as the
independent variable (first column) and "I" as the
dependent variable (next column).  It could have
typ/min/max as IBIS does now.

A fixed parameterized value could be ...

Cc  (P1  0)  C=c_comp

This one says to use the value "c_comp", which is a scalar.

For generating signals, something time dependent is needed
...

Rpu  (A1  A2)  I=pullup[V,T]

This one says there is a family of tables.

For sensing a value, a "trigger" element could be used ...

T44  V[A1] > Vhigh  ||  V[A1] < Vlow
T55  V[B4] == 3.5

T44 generates a "trigger" when the voltage at node A1 rises
through Vhigh or falls through Vlow.  T55 generates a
trigger when V[B4] crosses 3.5 from either direction. 
These triggers are passed to  anything with a time
dependency to start a waveform.

An optional parameter could be expressed with the "or" 
( || ) operator.

Rpower (pin pcr) R=Rpower || infinity

The resistor Rpower left open if the parameter is missing.

Vpcr (pcr 0) V=Power_clamp_reference || Voltage_range

The voltage source Vpcr gets its value from either
Power_clamp_reference (IBIS 2 or later) or Voltage_range
(IBIS 1)

Other components like transmission lines could also be
included.

It should be apparent that this is capable of generating
all of the structures that are now used by the IBIS
[Model], or are being considered.

More is needed to address the array nature of the
[Component], [Package Model], or [EBD].

One thought is that the component itself could have an
array form ...

Lpin[1:36]  (A[1:36]  B[1:36])  2.2n

This generates 36 inductors ...

Lpin1  (A1  B1)  2.2n
Lpin2  (A2  B2)  2.2n
....

this is based on the syntax where [1:36] means a sequence
of numbers 1,2,..36. 

Coupling might be represented this way ...

Cc[1:35]  B[1:35]  B[2:36]  .5p

It could also use inheritance to minimize the duplication.

We also need to say what this is and how it is called.

Here is a start showing usage ...

[Begin Structure] Model_base (pin, pwr_clamp_e, gnd_clamp_e)
Rpc (pin pwr_clamp) I=POWER_Clamp[-v]
Rgc (pin gnd_clamp) I=GND_Clamp[v]
Cttpwr (pin pwr_clamp) C = TTpower * I(Rpc) / VT || 0
Cttgnd (pin gnd_clamp) C = TTpower * I(Rgc) / VT || 0
Ccomp (pin 0) C=Ccomp
if (pwr_clamp_e){
  pwr_clamp = pwr_clamp_e
}else{
  Vpcr (pwr_clamp 0) V = Power_clamp_reference || Voltage_range
}
if (gnd_clamp_e){
  gnd_clamp = gnd_clamp_e
}else{
  Vgcr (gnd_clamp 0) V = GND_clamp_reference || 0
}
[End Structure]

[Begin Structure] Terminator (pin, pwr_clamp, gnd_clamp)
inherit Model_base (pin, pwr_clamp, gnd_clamp)
Rac (pin t1) R = Rac || 0
Cac (t1 0) C = Cac || 0
Rpwr (pin pwr_clamp) R = Rpower || infinity
Rgnd (pin gnd_clamp) R = Rgnd || infinity
[End Structure]

[Model] b1000_terminator
Model_type = Terminator
[POWER_Clamp]
.....
| exactly the same as you define a Terminator now!  100% compatible.

I have structures for some of IBIS 3.2.  So far, the only
"element" I needed that isn't trivial is a "driver" that
accomodates rising and falling waveforms with pullup and
pulldown as a single element.  The only reason this one is
needed is for backward compatibility.  It is amazing how
simple and clear some of the models are with this approach.

This is a start.  If we complete this, I believe it can
solve most of the existing IBIS problems, and address new
ones nobody thought of yet.  Also, it provides the added
functionality of IMEC, while maintaining the behavioral
nature of IBIS.  It is also easy to implement, much easier
than the existing IBIS 3.2.

If it stands a reasonable chance of being adopted, I
volunteer to write a complete spec based on this, and an
initial set of compatibility structures.

---

From: Bob Ross <[email-masked]>
Date: Thu, 02 Dec 1999 18:18:06 -0800

Al:

We have had some interesting discussions on future
directions for IBIS.  Thank you all for participating,
and I welcome more discussion of the subject.

You have provided another proposal along with some excellent
arguments that need to be considered by the IBIS Committee.

Bob Ross
Mentor Graphics

---

From: Christopher Reid <[email-masked]>
Date: Fri, 03 Dec 1999 08:41:03 -0800

Al & Stephen,

I like your ideas for a structure-oriented future for IBIS.
The comment that

> It

This is probably not true; but I do think it would be less
work to generalize a simulator once to take care of these
structures than to keep modifying simulators to take new
data types every time the IBIS spec changes.

Even if this approach is adopted, the comittee still needs
to define the standard structures for new devices and to
verify that these structures adequately represent the
devices they are supposed to mimmic.  Individual users
could vary from these standard structures, but for the
most part I would like to see publicly available models
following standard structures so that everyone has some
confidence that the results will be correct.

Chris

---

From: Stephen Peters <[email-masked]>
Date: Fri, 03 Dec 1999 15:28:27 -0800

Hello Al:

  This is a very intriguing proposal, especially with its potential for making 
the IBIS base model extensible.  If I understand correctly, what you are 
proposing is that the current IBIS prototype model be explicitly defined and 
documented by these simulation structures, and a user is free to create new 
structures as the need arises.  I especially like the way you did the nodal 
language, and the fact that you slipped in some programming constructs.

Just a couple of thoughts:

1.  There is still the problem of incorporating the package
power distribution and pin to pin coupling information.  The 
IBIS-X proposal took the approach of mapping component power/gnd pins
to a buffers power/gnd nodes, then allowing that buffer to
be made up of models of the package power distribution and the actual 
buffer.  I'm guessing your 'simulation structures' would still
have to be incorporated into an overall model/sub-model structure.

2.  (This thought courtesy of Scott McMorrow).  One item that I have not 
seen any proposal address is specifying timings *between* 
buffers.  For example, suppose there is a group of nine buffers that are
used in a source synchronous configurations. How does a component model tell a 
simulator (for example) pins 1-8 are the data, pin 9 is the strobe, and there 
is
Xns delay between the data bus and strobe?

Again, thanks for the thought provoking proposal.

   Regards,
   Stephen Peters
   Intel Corp.