Re: Future directions for IBIS

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.
Received on Thu Dec 2 13:35:28 1999