Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS

D. C. Sessions (dc.sessions@vlsi.com)
Thu, 10 Jun 1999 16:49:17 -0700

Marc Humphreys wrote:
>
> Al,
>
> I think you took Jon's comment out of context and went off on a tanget,
> missing his point completely. I think Jon's point was simply that when
> creating an XTK model from the same initial VI curve data (measured
> even),
> via two different methods ( For arguments sake one via the GOLDEN
> process
> - probably by hand, and the other via IBIS) that the filtering effect
> of the
> 100 point limitation hinders the ability to create two identically
> behaving models strictly attributable to the (currently)limited
> VI data in the 'IBIS'ed version' of that same data - No matter how
> carefully those 100 point where chosen!

For some reason, computer people presented with mathematical tasks
always like bigger hammers. An amazing number of programs still
do numerical integration by rectangular summation instead of Simpson's
Rule -- and then use ten or more times as much granularity in an
attempt to make up the difference.

OF COURSE if you're relying on a piecewise-linear approximation you're
going to need a gazillion points. The solution isn't to use more points,
it's to get smarter and use a better interpolation. The graphics gang
figured this out a while ago, and THEY do it in hardware at video data
rates.

> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> -------------
> Marc Humphreys
> Nexabit Networks, Inc.
> 508-460-3355 x236
> e-mail: mhumphreys@nexabit.com
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> -------------
>
> > -----Original Message-----
> > From: Al Davis [SMTP:aldavis@ieee.org]
> > Sent: Wednesday, June 09, 1999 3:10 AM
> > To: ibis@eda.org
> > Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice
> > to IBIS
> >
> > jonp@pacbell.net wrote:
> > > I have actually been faced with the problem that even with software
> > to remove
> > > extra points I cannot
> > > create IBIS models to the accuracy that I desire with the 100 point
> > limitation.
> >
> > I don't believe even 10000 points would provide the accuracy you
> > desire,
> > because the limits to accuracy are usually elsewhere.
> >
> > For example ....
> > 100 points chosen to be uniformly spaced in voltage, modeling a 5 volt
> > rising waveform, provides a data point every .2 volts. Assuming that
> > the interpolation is completely bogus, this leads to a worst case
> > error
> > of .1 volts. In reality, interpolation is much better than that, and
> > even this choice of data points is far from optimal, so the accuracy
> > is
> > much better than this. Remember, this isn't DC, but the dynamically
> > changing voltage during a high speed transition.
> >
> > Some questions ....
> >
> > Is your Spice model that accurate? (I don't think so.)
> >
> > If you measure one real unit with perfect accuracy, and compare to the
> > next one, are they this close to each other. (I don't think so.)
> >
> > Are your instruments this accurate? (Don't forget that you change the
> > reading when you attach the probe.)
> >
> > What if the real load is different from the test load? Since the
> > driving impedance is nonlinear, and not specified anywhere, even with
> > perfectly accurate and complete data for the nominal load, all bets
> > are
> > off for anything else.
> >
> > Sure, the voltage is right, into a resistor, but what about
> > reflections
> > and noise?
> >
> > How accurate is the rest of the simulation?
> >
> >
> > There are other ways to improve the accuracy. One obvious one is to
> > carefully select the data points (as Kellee said). Another is to add
> > another VT table with a different load. (As Kellee also said) The
> > third table does much more to improve accuracy than more points will
> > do. Tying the load resistor to a middle voltage does a good job at
> > modeling the overlap.
> >
> >
> > I wouldn't object to removing the limit entirely, because whatever the
> > limit is, most files will use it, without any valid reason. With no
> > limit at all, it is up to the modeler to decide what trade-offs to
> > use.
> > Maybe with nothing in the spec saying how many points to use, we might
> > actually get some good 20 point models, that are more accurate than
> > the
> > 256 (or whatever) point models that we will get if the limit is
> > raised,
> > and the capability is there for those rare cases when you really do
> > need
> > the extra points. So, maybe the answer is to remove the hard limit,
> > but
> > add a comment that tables with more than 50 points are rarely worth
> > the
> > extra space.

-- 
D. C. Sessions
dc.sessions@vlsi.com