Re: Verifying IBIS models

Hi Luke,
My oppinions here are my own, and not necessarily those of my company.
I missed this when you first posted, but I feel compelled to input
my oppinion on this. There has been discussion on the ibis reflector
in the past regarding the accuracy of SPICE models, particularly in
the diode voltage regions. For HSPICE in particular, we concluded
that the only way to provide a "non-ideal" set of clamping
diodes (for CMOS), the transistors' inherent diodes needed to
be shut down (set IS=0, AD=0, and AS=0, I believe), and a descrete
set of diodes placed on the drains of the transistors. This problem
had something to do with the fact that there was no way to model
the bulk resistance (the majority of the resistance that the
inherent diodes should have experienced) without increasing
channel resistance. The reason that I am even bringing this up
here, is that I wanted to provide at least one example of a
potential source of innacuracy of a *very* commonly used
version of SPICE.

We (painstakingly) developed our first IBIS model from a SPICE
netlist, by attempting to add *all* possible parasitic components
that we knew would exist in our actual silicon layout (resistance
and capacitances in our metal interconnects, etc.). We discovered
the above mentioned problem during this process, and sought
advice throught this email reflector. What we found was that while
a few companies that were participating on the reflector knew about
and addressed this particular problem, there were definitely others
that didn't. How well can you trust a vendors SPICE based IBIS model
that you downloaded off the web? Not to sound too harsh, but roll
the dice.

Our hope was to produce a IBIS model based on silicon measurments,
and then check to see how accurately the SPICE versions corellated.
If they matched well, we knew that we would have a very usefull method
of providing an IBIS model file to our customers, potentially
even before we had silicon available. In addition, we wanted
to be able to rely on the ramp data generated from the SPICE
models, because we knew that this data would be extremely hard
to extract from the Lab (on a packaged part, you have the
package parasitics effecting the ramp; on an unpackaged
die, you have parasitics added by the probe leads, etc.).

What we found after doing our lab measurements, was that there
was pretty good corellation between GND and VCC, but guess what?
The diode regions were close, but still had some discrepencies
(mostly around the knees).

This, in my oppinion, is the ultimate test that you are asking for.
However, when a vendor does this, they (like us) aren't going to
bother releasing the SPICE based IBIS model - why should they, when
they now have (the more accurate) silicon measurement based version
that they can release instead? I'm not saying that SPICED based
versions are untrustworthy; undoubtably there are some vendors that
have developed extremely accurate SPICE models, even to the extent that
they may have done all sorts of tricks so as to accurate model their
netlists in the Voltage areas that are not traditionally dwelled in
for development verification (more than a volt or 2 above VCC or below
GND). But a behavioral model can only be as accurate as the thing
that it's supposed to be behaving. If that "thing" is a SPICE
netlist... I have just pointed out what I believe to be one definite
shortcomming in one of the more popular SPICE versions out there.
However, I also pointed out an unofficial workaround that *some* vendors
are aware of. I'll let you draw your own conclusions.

A last oppinion that I would like to make is this: I personally
think that SPICED based IBIS model files should only be used as
a last resort. The case where SPICE models for a new process
are available, but the packaged silicon is not yet available,
might be a good example - you might be interested in a chip
vendors product even before it has hit the market, and this provides
a way for you to initially simulate it's behavior on the new
board that you are designing, now - before it can even be purchased.
Otherwise, why bother? I am interested in hearing other vendors
response to this. My conclusion was that extracting the data
in the lab was 10x easier that struggling with trying to get the
SPICE netlist to be as accurate as possible; and, the lab data
is the "real thing" anyhow. Consequently, lab data can be screwed-up
too, so ultimately you will need to either quiz the heck out of
the vendor who created the model file as to their methodology
(if they didn't describe it in total minute detail within the comments
of their IBIS model files), or you will just have to trust them...

-Scott Schlachter Design Engineering
 scotts@actel.com Actel Corporation
                        Sunnyvale, CA

> From owner-ibis@server.vhdl.org Fri May 30 15:21:20 1997
> Luke Chang wrote:
>
> > When IC vendors create IBIS models for their components, how do they
> > verify whether they are correct or not, compared to either the original
> > SPICE models or to physical measurement data? Do they actually do this
> > comparison? Is there a simulation methodology to do this comparison?
> >
> > I am just a user of IBIS models and will never create them. So I am
> > mainly interested in knowing whether I can always (blindly) trust the
> > models I get from the vendor Web sites or directly from the vendors.
>
> I suppose the usual disclaimers (I can't, strictly speaking,
> speak for VLSI, much less other manufacturers) are in order.
> That said, here's a little about our approach:
>
> 1) We SPICE the dickens out of I/O designs.
> 2) We verify the SPICE characteristics in design
> validation and test against them.
> 3) We generate IBIS models from the SPICE models.
> 4) We spot-compare SPICE simulations made from
> hand-translating IBIS back to SPICE.
>
> We're in the process of converting the canonical
> model for testing purposes from old-fashioned data
> sheets to IBIS. We *intensely* wish we had a
> working IBIS-to-SPICE translator that we could use
> for closing the loop, but at present there don't
> seem to be any around.
>
> --
> D. C. Sessions
> dc.sessions@tempe.vlsi.com
>
 
Received on Mon Jun 2 10:49:13 1997