Subject: Food for thought

From: "Hobbs, Will" <[email-masked]>
Date: Fri, 3 Sep 1999 13:18:21 -0700

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

---

From: Bob Ross <[email-masked]>
Date: Fri, 24 Sep 1999 12:03:33 -0700

Will:

It has been a while since issued this email.  We have been mentioning 
the possibility of an API (application program interface) for several
years as a possible IBIS enhancement.

Adopting an API for IBIS represents a fundamental shift in IBIS.
However, it may be necessary, as you discuss, to provide:

  (a) accurate information in a timely manner, 
  (b) with a standardized interface format
  (c) without requiring revealing proprietary details

These are consistent with IBIS goals.

Here are some questions I have that come from your initial
discussion:

(1)  What is the scope of the compiled model?  You mention that
it might be the structural model compiled with a public domain
Spice.  Could that mean that a public domain Spice (such as a
version of Berkeley Spice is included?  Or an internal
proprietary Spice engine set up for processing only that model?
Or a commercial Spice (which I doubt you will be able to
distribute)?.  Or are only the structural model itself plus API?
Or does the execution engine such as a Vendor-specific Spice neeed
to be supplied separately?

(2)  How simple can the API be for it still to be useful?  Upon
investigation, it might have to return at each time step all of
the voltages and currents at each node.  I presume the API would
connect at the buffer or differential buffer level to capture
properly the buffer interaction.  A number of such buffers could
be connected for SSO analysis externally.  The package model
description would probably be outside such an API.

(3) Some other details of the API might need to be considered.
Would extra connection parameters be needed for additions
such as external reference voltages, inputs for outputs, or test
point nodes?

You raise some good points about the advantages and disadvantages
of an API.  After more discussion I think we will be ready for some
specific proposals.

Bob Ross
Mentor Graphics