Re:IBIS-X proposal

Stephen and other "IBISians"

For what it is worth.... When I initially started with the IBISCnn
specification (IBISCnn = IBIS Connector Specification).... I really tried to
incorporate a nodal methods. And, for what it is worth, I still think it would
be a powerful addition. However, at the time (and maybe still) there seemed to
be a lot of resistance to incorporating a "SPICE deck like approach" in the IBIS
specification.

Further, I really like the inclusion of the PWR/GND (or maybe more
specifically, current return path) references. For what it is worth, these have
been included in the IBISCnn specification (soon to be available for your
critical reviews). As such, after IBISCnn is available, I would greatly
appreciate your comments.

If it would help the group, I would also suggest that the IBISCnn RLCs
interconnection metodology may address Stephans: "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".

As such, maybe it may also be possible to represent " some basic independent and
dependent sources" in the same "matrix" format.

Also, it is important to know that the IBISCnn specification does incorporate
"NO GROUND" models. Unfortunately, this functionality is lost if a simulator
insists on having "perfect ground" reference points on both sides of a
connector.

Best Regards,
_gus

____________________Reply Separator____________________
Subject: IBIS-X proposal
Author: Stephen Peters <sjpeters@ichips.intel.com>
Date: 11/12/99 12:42 PM

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.
Received on Fri Nov 12 13:22:48 1999