Re: Future directions for IBIS

All,

It's been a while, but I thought it would still be interesting to you.

I started a discussion in December about IBIS futures, and received
numerous valuable responses. I compiled a summary in which I
pulled all the main points of the responses together (I paraphrased
some of the more verbal ones).

I gave a short presentation on the subject at the IBIS Summit at
Design Con 2000 yesterday. For the benefit of those who weren't
there (or those who didn't get handouts any more), here is the
summary of the responses.

Note that my presentation will be uploaded shortly on the IBIS web
site. This material is reprinted in the Appendix of the presentation.

Sincerely,

Arpad Muranyi
Intel Corporation
--------------------------------------------------------------------
Advantages:
===========

1) IBIS succeeded because it created an accepted standard for
    distributing simulatable descriptions of I/O buffers.
2) Good at classical CMOS drivers.
3) Adequate for TTL receivers.
4) OK for passing device pinouts.
5) OK for uncoupled package parasitics.
6) OK for selectable drive strength.

Observations, disadvantages:
============================

1a) IBIS is not truly behavioral, but a parameter list for pre-defined
    structures.
1b) IBIS assumes circuit topology to which the parameters are supplied.
1c) Each change requires committee approval and implementation in
    simulators.

2a) IBIS is somewhat arbitrary and is suffering from creeping
    functionalism.
2b) It would be less work to generalize a simulator, than to keep
    modifying them to take new data types every time the spec changes.

3) With Berkeley SPCIE it was known how it will handle L, R, C, K
    values. This is not the case with behavioral simulators.

4a) IBIS does not lead to accurate SSN and return path prediction, and
    no straightforward extension will be able to handle this. A fresh
    start is needed.
4b) No return path models.
4c) No coupled parasitics.
4d) IV curves in (most) behavioral simulators are connected to perfect
    ground which ruins the validity of coupled connector models.
4e) Problems in the package power distribution and pin to pin coupling
    information.

5) Poor receiver modeling.

6) No coupled drivers (e.g. Open-drain current mode differential).

7) No method for source modulation (gate starvation).

8) Problem is not with IBIS itself, it is a matter of IBIS taking on a
    job which isn't fundamentally behavioral, where a structural
    interconnect model works quite well.

9) Kumar was right!

Needs (comments, recommendations):
==================================

Do we need IBIS?
----------------

1a) Revisit the need for IBIS. Can proprietary information be
    distributed through public or private encryption?
1b) Encrypted SPICE models have conflicts with name space and scaling.
1c) Next generation for IBIS is no simulation at all, but design rules,
    in terms of the customers of chip makers. Simulation needs to move
    forward, but not in the same broad fashion we once used to (at least
    in the PC space).
1d) We will not be able to simulate every possible configuration for the
    entire solution space. The customer will have to simulate their
    designs to make sure it will work.

What to keep and/or add?
------------------------

2a) Keep IBIS1.1, in fact do not abandon IBIS as it exists now. Change
    the direction of future IBIS enhancements.
2b) IBIS should remain a data standard, and should not be going in the
    direction of node description language because that exists already
    (SPICE). Focus on It curves which will aid SSN modeling.
2c) Keep the concept of IBIS models documenting the SI requirements.
2d) Keep the concept of an agreed upon standard.
2e) The need for microwave style modeling is clear.
2f) Check into using MMIC, a nodal simulator of the 90's which does a
    fine job of goal based parameter optimization.

3a) Use IBIS [Model] for drivers and receivers.
3b) Enhance IBIS as needed to model gate starvation.
3c) Enhance IBIS as needed to model input behavior.
3d) Receiver characterization should investigate using probability
    techniques. Output is between 0 and 1 representing probability.
    This may be the right way for "jittery receivers".
3e) Specify timings between buffers (skew).

4a) Represent some basic independent and dependent sources in matrix
    form.
4b) Don't forget Boolean capabilities in WSPICE, which may be required to
    characterize buffers.
4c) Need two agreed standards:
    - multi coupled lossy T-line, and
    - table driven, event triggered controlled current sources
4d) IBIS behavioral element needs to be standardized. Receiver model
    will become standardized subcircuits using these elements.
    S-parameter and LaPlace types will be useful also. Expressions should
    include logical 'if else' and derivatives.

Language, syntax
----------------

5a) Develop a SPICE like macro language describing the circuit with
    parameters and program logic. Parameters refer to tables, values,
    formulas in separate sections who's syntax matches existing IBIS
    [Model] and [Submodel] sections.
5b) IBIS should be a set of macro models that properly capture I/O edges
    and Vdd and GND transients. Table based IV macro models are
    appropriate.
5c) Need fundamental open work on what is needed to accurately model a
    driver with a macro model.
5d) Should be able to produce macro models from SPICE or measurements.
5e) Should be possible to translate the macro models into popular SPICE
    flavors.
5f) The IBIS committee needs to define and verify the standard
    structures for new devices.

6a) Use an XML based syntax which is essentially a structured SPICE. It
    should include BSPICE in addition to IV, Vt, etc. tables. May need
    to limit what SPICE elements to use. Lossy elements will need to be
    addressed soon.
6b) A perfect language should accept IBIS, SPICE, N-port network
    description language, graphical input, measurement based tables of
    S, Y, or Z-parameters by frequency or NDL equations.
6c) A common thread seems to be network description objects, object
    oriented language. Look at Agile user manual. It uses the linpack
    nonlinear PDE solvers. Smalltalk, and Matlab solver would work for
    prototyping.

7a) Netlist-like format is really necessary to define return path and
    coupling effects.
7b) A netlist type structure is the only sensible route forward. Would
    vote for an extended SPCIE syntax, which could be used to model
    existing devices, or we could redefine the current structures using
    the new syntax.
7c) Use EDIF netlist (or extended SPICE format which allows distributed
    parasitics) to model on-chip return paths.
7d) Proposing two sections, a parameter and a structure definition
    section. A netlist like language (inspired by SPICE) could be used
    to define them. However, since it will be processed, it could
    provide component types and parameters that do not exist in standard
    SPCIE. To provide a migration path, a set of structure definitions
    could be provided with any conforming IBIS simulator.

Package
-------

8a) Do not include package in IBIS models. Use SPICE for that.
8b) Standardize die, pkg, and connector model on the CAD tool level.
8c) RLC will not be satisfactory for packaging, need lossy coupled
    transmission lines.
8d) Sounds like you are leading towards the 'Universal parser' for
    packaging related info with some common format.
8e) Use connector syntax or netlist to model package parasitics.
8f) Use some of the items from the proposed connector specification.
    Additional features to be considered:
    - Behavioral modeling of interconnects (S-parameters).
    - Consider delay and impedance (admittance) matrixes for cable
      modeling.
    Would have really liked to develop nodal methods for the connector
    specification but there was a pushback in those days. Really like
    the inclusion of PWR/GND references.

IBIS-X
------

9a) The IBIS-X approach proposes that in addition to the traditional
    IBIS prototype model, behavioral elements should be connected
    together nodally. The nodal approach allows build arbitrary
    packages around the buffer for SSN, power delivery, and return path
    modeling.
9b) A model is a multi port entity. Submodels are also allowed.
9c) In addition, provide hooks that enable simulators to incorporate
    external (transistor level) models through an API.
9d) Each model should also contain data book information for automated
    flight time and skew analysis.
9e) Not clear how behavioral simulator can call SPICE since SPICE is not
    set up to be callable.
9f) Question: Will it be IBIS calling other formats or other formats
    calling IBIS?
9g) IBIS-X should consider the connector RLC interconnect methodology
    for package.
====================================================================
Received on Tue Feb 1 08:57:41 2000