RE: Table length reduction

I think it's a good idea. However - it would require some definition of
"noise," which would be rather controversial. Along those lines, here's
another idea for a filter. A script to remove nonmonotonic data(noise,
preshoot, overshoot, etc) from V:T curves can be useful since many
behavioral simulators cannot handle this data. Unfortunately, translations
that smooth the curves tend to disrupt the duty cycle which can cause highly
inaccurate timing reports for high speed designs. Anyone have a script with
supporting accuracy data?

Frank Kern
Intel Corporation

-----Original Message-----
From: Weston Beal [mailto:weston_beal@mentorg.com]
Sent: Monday, May 08, 2000 2:02 PM
To: 'IBIS Mailing list'
Subject: RE: Table length reduction

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.

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?

Regards,
Weston

-----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