Food for thought

IBISers,

Food for thought:

For years, naysayers have said that IBIS was fine for some
things, but with newer, higher speed and new buffer innovations,
IBIS wasn't going to be sufficient. They made that claim when we
went from 50 MHz to 66, and again from 66 to 100, and so on. For
years, we've proven the naysayers wrong. One of the ways we've
done so has been to improve IBIS over time, adding features to
support emerging needs, addressing subtler effects, etc. I won't
itemize the improvements here-- just look at the deltas from IBIS
1.1 to 2.1 to 3.2, and at the current work going on to get an
idea of the progression.

Nonetheless, IBIS still lags some of the leading edge needs, and,
as with any living standard, will probably always lag in one area
or another. In addition, there are some nagging problems we still
haven't addressed satisfactorily, even though we've faced them
for years-- SSO comes to mind.

I would like to propose a way to satisfy emerging needs in a more
timely way: Define an API that would allow structural models,
compiled with execution engines (such as public domain Spice
variants) to interface to behavioral simulators. The API would be
a C-based procedural interface that would handle passing of data
back and forth between the IBIS simulation and the self-contained
compiled model.

The resulting simulation would be slow and big, but the model
developer could have the freedom to include support for power and
ground routing, and whatever other details that (s)he deemed
necessary for accurate simulation not available in the current
IBIS version.

Meanwhile, IBIS can continue to address these emerging needs,
making each successive generation's structural models
unnecessary, at least until the next problem not addressed by
IBIS became critical. Then this "escape" mechanism would still be
available, and customers wouldn't have to run separate
simulations for their unique structural models and their
behavioral models.

IP concerns could be dealt with through the compilation process,
which could easily be obfuscated or encrypted enough to hide
structural and process details.

I suspect such an API could be fairly simple. For example, it
would have to support a pin list, some initialization information
passing, voltage and time-step information. There is probably
additional data that would have to cross the simulator/model
boundary, which would go into the API definition-- not sure what
all that would be.

Should this be part of IBIS? I think so, but am open to other
opinions. At the very least, I believe this body has the right
constituency to take this on if anyone agrees with this
suggestion.

I realize that such an API could have a detrimental effect, in
addition to its positive one. If the API were to exist, it might
remove some of the incentive for enhancing IBIS. However, the
speed of execution issue alone would probably keep IBIS moving
forward. There would also be the problem that an executable model
would have to be re-compiled and re-validated for each specific
platform it had to run on-- not an insurmountable problem, but
one which IBIS doesn't have. I think IBIS would continue to
mature for these reasons.

This API might even offer a way to allow IMIC and IBIS to inter-
operate-- I haven't given that much thought yet.

Comments?

Will
Received on Fri Sep 3 13:24:56 1999