Re: low budget IBIS tools

Tom Warneke wrote:

> I am perplexed why one would want to convert IBIS to Spice models.
>
> My experience has been that digital designers (which IBIS is intended to
> serve) want to move away from SPICE to tools better suited to analyzing
> signal integrity, cross-talk, and EMC -- the annoying by-products of
> high speed digital circuits and fast edge rate devices that are common
> today.

I disagree that IBIS is intended to serve digital designers who want
to move away from SPICE. IBIS has everything to do with analog
simulation, the same stuff we use SPICE for. IBIS models are not
inherently different from SPICE models in terms of signal integrity,
crosstalk, EMC, etc.

One of the reasons for IBIS is because of the proprietary model
problem. Lots of us folks who use SPICE, have this problem, both
analog and digital engineers. Quoting from the IBIS FAQ: "IBIS ... is
a method of providing the Input/Output device characteristics through
V/I data without disclosing any circuit/process information."

Another reason is speed. SPICE models can be unnecessarily complex,
when all you are after are the interconnect characteristics. Some
SPICE models include the whole chip, or huge portions of the output
buffers, and run unbearably slow. IBIS focuses only on the I/O
characteristics.

Yet another reason, is that IBIS models lend themselves particularly
well to being based on real, measured data. Trying to tweak a
full-blown SPICE model to fit measured data, is risky at best. IBIS
models don't need to be tweaked to fit the data; the measured data
becomes the IBIS model.

In my opinion, the free s2ibis tool, has done a lot to damage IBIS's
potential, by allowing anyone to make IBIS models from their SPICE
models and not even trying to use measured data. s2ibis is how you
jump on the IBIS bandwagon. It's not how you do it right.

On the other hand, a free i2spice tool, is exactly what IBIS needs
and has needed since day 1.

IBIS is neither a simulator, nor a simulation methodology. It is
merely a spec for an electrical model, that is intended to be used in
a SPICE or SPICE-like (analog) simulator.

The very unfortunate thing for us users, is that some of the old SPICE
programs still don't know IBIS.

At work, I use two SPICE programs. One is generic SPICE with in-house
customizations to know all about the CMOS processes of our fab. The
other is a popular program with extensions for dozens of other MOS
transistor models. I *must* use the first program when I want to
simulate something involving the chips we make when I only have models
for the first program. I *must* use the second program when I want to
simulate something involving external vendor's chips where their SPICE
models are unique to that program, as the majority of external SPICE
models seem to be. God help me if I have to simulate a signal that
connects between both kinds of chips!

IBIS models only make this worse. Don't get me wrong; I support the
idea of IBIS models. But I do not have the means to use an IBIS model
in a simulation; neither of the two SPICE programs I use, knows IBIS.

If I use a newer IBIS-aware signal integrity simulator, it would not
be able to accept at least one of the two types of SPICE models above;
maybe even both. That is totally unacceptable to me.

If the majority of my models are proprietary SPICE, and occasionally
an IBIS model comes along, and since my environment is already set up
for working with SPICE, I think I am better off (for now) staying with
the SPICE environment.

So considering those increasingly frequent cases where an IC vendor
refuses to show us the SPICE model, it makes a heck of a lot of sense
to translate their IBIS model into a SPICE-usable format.

In fact, I might even expect such a model to be more accurate, if it
is based on measured data. How often have you gotten a SPICE model
that differed from the measured buffer strength by 300%, or where the
SPICE model completely lacked clamp diodes that were there, or where
all the diodes had zero resistance? If the IBIS model was created
from measured data, then I should be in much better shape with it,
or a SPICE behavioral model derived from it.

> It seems that something will be lost in going from SPICE Model -> IBIS
> -> SPICE model. My understanding is that (behavioral) IBIS models are
> generally derived from (functional) SPICE models.

Indeed, many are, but they shouldn't be. We should expect to get
measured IBIS models for anything for which real silicon exists. IBIS
models derived from SPICE should only be acceptable when the device is
in development and hasn't been built yet. But, alas, IC vendors are
too stupid or lazy to do this.

> IBIS models and simulators are fine tuned to be faster and easier to use
> for their intended purpose. This imposes limitations which are not
> realized in the SPICE world (i.e. support for voltage controlled
> multi-stage drivers and the examples you provided). It seems to me that
> using a SPICE simulator with models derived from IBIS is taking on the
> worst of both worlds: SPICE complexity and run times and IBIS model
> limitations.

What makes SPICE slow, are the SPICE models. Not the simulator per
se. SPICE simulates what happens at every single internal node and
device in the structural model, even if they have no effect on the
I/O pin. IBIS models are faster because they skip all that and
concentrate on just the I/O pin. SPICE can have behavioral models
too, and they run extremely fast. Translating an IBIS model into a
behavioral SPICE model should let it run just about as fast as using
the IBIS model directly in an IBIS-aware environment.

Regards,
Andy
 
Received on Sat Oct 25 19:51:26 1997