Re: Future directions for IBIS

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.
  

> 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 15:41:38 1999