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

From: Marc Humphreys <mhumphreys@nexabit.com>
Date: Wed Jun 09 1999 - 12:21:51 PDT

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!

------------------------------------------------------------------------
------------------------------------------------------------------------
-------------
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.
Received on Wed Jun 9 12:28:18 1999

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT