Re: Future directions for IBIS

Al & Stephen,

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

> It
> also should be not much work to generalize the simpler
> interconnect simulators to take these components.

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

Bob Ross wrote:

> 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
>
> Al Davis wrote:
> >
> > 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 Fri Dec 3 08:42:41 1999