IBIS-X proposal

Hello All:

  At the recent IBIS summit there was a fair amount of discussion regarding
the future of IBIS. Among the issues the IBIS community has been wrestling
with are:
1. the growth in complexity of the specification,
2. support for power/gnd and return path modeling
3. receiver modeling, and
4. the need for a general escape mechanism that allows simulators to
incorporate user created models (models that the simulator may not otherwise
support).

  So far, there has been a proposal for incorporating an API (application
programming interface) into IBIS, which addresses point four above. However,
to fully support an API I belive that the current IBIS description would have
to change. Specifically, models would have to become multi-ported
entities with explicit power and ground ports tied to component pins. In
fact, I belive to in order to fully address the problems of complexity
(added keywords for every new type of buffer) and return path modeling there
needs to be a new, general buffer description language, one that supports IBIS
type simulators but also allows a model to be used directly by a circuit
simulator. To that end I'm making a proposal called IBIS-X. I am aware that
this is a fairly radical proposal (for example, it is not backwards compatible
with the existing IBIS specification), but I belive it does address directly
both the needs of those producing models as well as those designing high
speed electrical interconnects.

Please look it over and make your comments. This will be on the agenda at
the next IBIS phone conference.

   Best Regards,
   Stephen Peters
   Intel Corp.

----------- cut here -----------

  The following is a proposal for a new format to be used for creating and
specifying I/O buffer models. This format is an evolution of the current
IBIS description, and provides a couple of fundamental enhancements when
compared with the current specification. Specifically:
  a) IBIS-X provides for much greater flexibility in model descriptions.
Buffers can be described using either the traditional IBIS prototype model
or the user may create their own buffer model by using a set of passive and
behavioral elements connected together nodally. Nodal descriptions provide
a direct path into circuit simulators, and nodal descriptions are also used
to build arbitrary package models around a buffer.
  b) IBIS-X provides support for return path modeling. Component power and
gnd pins are connected directly to a model instance, thus allowing true
system level simulations that incorporate board decoupling effects, ground
return effects, etc.
  c) The IBIS-X proposal provides the necessary hooks that enable
simulators to incorporate an external models thru an API.

IBIS-X COMPARED TO IBIS
  As with the original IBIS specification, the IBIS-X description is
targeted towards transmission line and board level SI simulators. To this
end IBIS-X sticks with the "component centric" format -- each pin of a
component is listed, and pins are attached to a model witch can be used
over and over again. Furthermore, each pin (model) is explicitly declared
as a driver or receiver and each model contains the 'data book' information
(timing test loads, Vinh/Vinl, etc.) that allows for automatic SI and
flight time analysis. The biggest difference is that the IBIS-X
description allows a buffer/receiver model to connect not just to an I/O
pin, but also to power/gnd pin(s). It does this by making the [Model] a
multi-port entity. By allowing a model to have explicit power ports a
circuit type simulator (or an enhanced behavioral simulator) can modulate
the power and ground rails of a behavioral model, thus incorporating the
effects of board level power distribution (including ground return paths)
into a simulation (i.e. enables true system level simulation).

  As mentioned above, the IBIS-X spec allows the model maker a choice of
descriptions. Model makers should be able to model a driver or receiver to
the level of detail required and/or appropriate. Traditional I/V,V/T
descriptions are still very useful and the IBIS-X proposal fully supports a
pure behavioral description of an driver or receiver. In other cases, the
user may want to model a buffer behaviorally, but surround the buffer with
a package model consisting of a network of R/L/Cs (a SPICE like
description). Therefore, the IBIS-X proposal allows the guts of a model to
be a nodal network consisting of passive components, some basic independent
and dependent sources, and submodels. In turn, a submodel can consist of
behavioral descriptions, nodal networks, more submodels, or a coupling
matrix (used to describe pin coupling). By using a approach based on nodal
description and submodels, it should be straightforward to incorporate a
package model around a buffer, or to group buffers together to simulation
SSO effects, etc.

 Finally, the IBIS-X proposal prepares the way for a behavioral simulator
to execute transistor level models by allowing a model or submodel to call
an external model which is executed via an API. I should point out that
adding an API to the existing IBIS specification is possible, but to make
it useful there still needs to be some mechanism to define/declare a
multi-port model and associate those ports with the various [Voltage]
keywords of the current spec and the pins of the component.

========= Details, and a shot at syntax ==============

FILE HEADER
The file header info remains pretty much the same as in
the current IBIS spec.

[Template Version] version #
[Comment Char] | by default
[File Name] file name.ibx
[Date] date
[Source] ASCII text
[Notes] ASCII text
[Disclaimer] ASCII text
[Copyright] ASCII text

COMPONENT SECTION
The major function of the component section is to map the component pins
to a model. However, instead of calling out just a model the [Pin] keyword
connects pins to a specific port on a model. The [Model Selector]
functionality is retained, along with the [Diff Pin] keyword. However, the
[Diff Pin] keywords function has been changed to list only skew between
differential outputs only. (Note: To aid parsing each "section" of the spec
begins with a [Begin "Section Name"] keyword and ends with an [End "Section
Name"] keyword.

[Begin Component]
[Component] component name
[Manufacture] manufactures name
[Pin]
pin_name signal_name model_name port_name R_pin L_pin C_pin
(Note: only a *model_name* is allowed, not a submodel name. To support
IBIS compatible descriptions NC, PWR and GND are legal pin connections, and
a generic R_pin, L_pin and C_pin can be included.)

[Diff Pin]
inverting_pin non_inverting skew_typ skew_typ skew_max

[Model Selector]
[End Component]

MODEL SECTION
The purpose of the model section is to identify the top model type (input,
output, bidir, etc.), list the data book specs that support SI simulators
and board level timing products (timing test loads, input parameters,
etc.), define the ports of the model and finally, provide a place to put
the guts of a model.

[Begin Model] model_name
model_type = select from list
C_comp* = I/O capacitance value
[Temperature_Range] typ min max
[Pullup Reference] typ min max
[Pulldown Reference] typ min max
[POWER Clamp Reference] typ min max
[GND Clamp Reference] typ min max
[Receiver Reference] type min max
  (The voltage range keywords are used a bit differently than in IBIS.
These keywords indicate the voltage at the associated model port. For a
traditional behavioral simulator these value still end up being the
references for the I/V curves. For an IBIS-X simulator they would be a
fixed voltage at the pins, and a structural description can be used to put
a package model in between the pin (port) and the buffer model itself. For
a pure SPICE simulator (where the board level power distribution is
modeled) these keywords serve mostly as documentation.)
[Driver Spec]
  (timing test loads, Vmeas, etc. Use if a model is an output or I/O)
[Receiver Spec]
  (input thresholds, overshoot/undershoot thresholds, etc. Use if a model
   is a receiver or I/O)
[Port list]
port_name port_type
  (port types are:
      primary_io | primary I/O pin
      pullup_ref | power connection pin
      pulldown_ref | power connection pin
      pwrclamp_ref | power connection pin
      gndclamp_ref | power connection pin
      rcvr_ref | power connection pin
      gnd | reference pin
      ctl | a digital (1/0) control pin
      analog | an analog control pin
      stim_in | external stimulus (not a component pin)
      recevier_out | output of a receiver (not a component pin)
   )
[Begin Model Description]
description_type = behavioral | structural

  (put the guts of the model here)

[End Model Description]
[End Model]

MODEL DESCRIPTIONS
  A model can be described in one of three forms: A conventional behavioral
(IBIS) description, a nodal description that interconnects submodels and
passive components, or a call to an external file.

For a traditional IBIS description, the following keywords are supported
(initial list).
[Pullup]/[Pulldown]/[POWER Clamp]/[GND Clamp]
[Rising Waveform]/[Falling Waveform]
[Ramp]
[TTgnd]/[TTpower]
[Driver Schedule] (replace by IBIS submodel mechanism?)
[Add Submodel]
[SubModel]

   (Note: The keywords that support series switches, series devices, or
terminator networks have not been included. Given that these devices are
adequately supported in IBIS, or could be described using a circuit
description, I have not included them in the initial list.)

A nodal description connects passive components, submodels and independent
voltage and current sources together. Transistors are not supported, but
a general three terminal device is included. Syntax would be some most
common denominator of the existing SPICE variants.

Rxxx node1 node2 value= explicit value or equation (resistance)
Lxxx node1 node2 value= explicit value or equation (inductance)
Cxxx node1 node2 value= explicit value or equation (capacitance)
Vxxx node1 node2 value= explicit value, equation or table (V source)
Ixxx node1 node2 value= explicit value, equation or table (I source)
Sxxx node1 node2 node3 value = equation or table(s) (three terminal device)
Xxxx port1=>node1, port2=>node2, ...parameter1=>value,... (submodel)

Finally, the guts of a model (or a submodel in a nodal or IBIS description)
could be a call to an externally defined model that the simulator executes
via an API (applications programming interface). The syntax of the call
has yet to be worked out, but one would expect something like

Xxxx port1=>node1, port2=>port2,... parameter1=>"path to model file", ...)

One question that has been puzzling me is the mechanism used to apply
stimulus to the external model. Does the simulator simply flip the stim_in
node from '0' to '1', or does the user have to attach an explicit stimulus
source?

SUBMODELS
Submodels are used both by behavioral descriptions ([Submodel] statements)
and nodal descriptions (Xxxx calls). Submodels are a lot like top level
[Models], but they do not include any of the top level simulation
information nor can they connect directly to a component pin. Again,
behavioral, structural and calls to external models are supported. In
addition, a submodel can support a matrix type description of a passive
network.

[Begin Submodel] submodel_name
description_type = behavioral | structural | matrix
[Port List]
  (port name, but do we need a description??)

  (put description of submodel here)

[End Submodel]

[End]
Received on Fri Nov 12 12:50:02 1999