Re: Table length reduction

Weston Beal wrote:
>
> D.C.,
>
> I think I understand what you're doing, but wouldn't it be easier and maybe
> more applicable to do linear interpolation? If the program (simulator or
> translator) that reads the resulting IBIS file does cubic spline then you
> are correct in doing the same in your filter. If the IBIS file is going
> into a program that does piece-wise linear interpolation then the filter
> should do the same, I think.

Actually, the program is general. You could set n=1 in the top-level
procedure instead of 2 and it would be linear instead of cubic. On the
other hand, cubic is MUCH nicer from a harmonic-minimization standpoint
and in principle lets the software use fewer piecewise segments, thus
speeding up simulation. If you hold the number of points constant, the
linear method will concentrate them at high-curvature regions (e.g., at
the beginning and end of a rise) and the cubic will concentrate them
before the rise, just after the beginning, before the end, and just after
the end. Sort of.

You have source code -- play with it and see what it does.

> On a related subject, what do ya'll think about a smoothing filter (least
> square?) to reduce measurement noise in IBIS tables? Is it useful or
> dangerous?

I wouldn't use least-squares. At model generation time I'd burn the
cycles to do a Fourier transform and filter the stuff beyond the range
of validity.

> -----Original Message-----
> From: dsession@isis.vlsi.com [mailto:dsession@isis.vlsi.com]On Behalf Of
> D. C. Sessions
> Sent: Monday, May 08, 2000 12:48 PM
> To: IBIS Mailing list
> Cc: Chris Rokusek
> Subject: Re: Table length reduction
>
> Chris Rokusek wrote:
> >
> > D.C.,
> >
> > A Natural cubic spline will often introduce non-monotonicity resulting in
> > simulation instability or inaccuracies especially on diode curves. You
> will
> > need to use a different spline.
> >
> > Don't believe me? Try
> >
> > http://www.glue.umd.edu/~tvp/interp.html
> >
> > and draw a monotonic diode curve.
>
> Chris, I'm not doing interpolation. I'm using interpolation to cull
> redundant points. The algorithm works by calculating a spline from
> the four points adjacent to a subject point and interpolating to
> that point. Those points with minimal discrepancy from the interpolation
> are candidates for removal and their immediate neighbors are kept until
> the next pass.
>
> Then again, one of the things I love about Icon is that prototyping
> is awesomely fast. By all means try a different algorithm...
>
> > > -----Original Message-----
> > > From: dsession@isis.vlsi.com [mailto:dsession@isis.vlsi.com]On Behalf Of
> > > D. C. Sessions
> > > Sent: Monday, May 08, 2000 10:30 AM
> > > To: IBIS Mailing list
> > > Subject: Table length reduction
> > >
> > >
> > > OK, I said I'd have a go at a program to intelligently
> > > reduce the size of IBIS tables so that we can have high
> > > resolution where needed and still keep below the 100-point
> > > limit. Here is is, attached. The language will look
> > > very, very strange to most of you; it's Icon, an academic
> > > language that's sort of a cross between C and Prolog.
> > > You can get documentation and a copy for most any platform at
> > > http://www.cs.arizona.edu/icon/
> > >
> > > The program as written is pretty crude. It takes JUST the
> > > table data and thins it out using a cubic interpolation.
> > > Command-line syntax is
> > >
> > > decimate <pts> <file>
> > >
> > > Where <pts> is the maximum number of points in the output,
> > > and <file> is the source. Output is to standard output, and
> > > if no input file is specified it defaults to standard input.
> > > It expects each line to have the same number of fields (and
> > > will barf if they don't match). For unjustifiable reasons it
> > > does NOT accept scientific notation in; it does accept 'munp'
> > > suffixes. The output is scientific. If I'd been more awake
> > > I'd have done both in scientific and left formatting up to a
> > > perl or awk script.
> > >
> > > That said, I've experimented it several data sets and it seems
> > > to produce reasonable results. Feedback, improvements, or a
> > > complete rewrite to C welcome.
> > >
> > > --
> > > D. C. Sessions
> > > dc.sessions@vlsi.com
>
> --
> D. C. Sessions
> dc.sessions@vlsi.com

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