IBIS: Re: Food for thought

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

Hobbs, Will wrote:
>
> 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 24 12:04:12 1999