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

From: tomda <[email-masked]>
Date: Wed, 9 Jun 1999 11:43:47 -0700

There are several questions that beg to be asked to fuel this discussion. 
 How accurate does a model (simulation) need to be?  If the accuracy 
requirement can be nailed down then a meaningful discussion can be had on 
the number of points required.  So far we have not addressed this part of 
the problem.  Once we start down this path we will have to start 
understanding the algorithms used, different mathematics will generate 
different results given input data.

I've seen too many models that have way too much precision build into the 
model.  E.g., 43.0156898745 mA  When people insist on generating lots of 
decimal points there is a tendency to generate lots of data points to 
justify the precision in the data.  In many cases of models I have seen 
with this there are datapoints that show the difference in the 6th decimal 
point.

I agree that disk space is free and MIPS are getting there too.  Artificial 
limits on the number of points are not good for models.  But maybe there 
are other ways of solving this problem.  Equations for VI curves may be the 
way to go and let the simulator decide the voltage step is an alternative. 
 Like Jon, I use algorithms to reduce the number of points in our VI tables 
with very good results.  I've not seen VI curves that needed over 100 
points after processing.  Jon, what kinds of parts require more than 100 
points?

Tom Dagostino
Mentor Graphics

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Wednesday, June 09, 1999 8:59 AM
To:	Kellee Crisafulli
Cc:	[email-masked]; [email-masked]
Subject:	Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to	IBIS

Here is a comment from a model creator:

I have written extensive software to deal with the ideal selection of
non-redundant data. I have found that the 100 point limit is over 
restrictive for
both IV and VT curves. (that is, I have example models that cannot be 
constructed
inside the 100 point limit and still be as accurate as I want (ie. as 
accurate as
the XTK model I made at the same time)). I don't think that model size or
transmission time should really be a major consideration. Disk space if 
free.
Bandwidth is soaring. The IBIS format should be relieved of artificial 
barriers.
Our goal should be to make it easy for people to make good IBIS data sets, 
not a
big pain.

jon

Kellee Crisafulli wrote:

> Hi all,
>
>   At the risk of repeating myself there are several very good
> reasons to limit the number of points in the IV and VT tables.
> e.g. disk size, transfer time, overall accuracy improvement.
>
> The last one may surprise you but I do feel that including for
> example a 3rd VT table buys more than increasing the number of points
> for most models.
>
> I do agree the number of points could be increased to say 256 to
> pick yet another arbitrary spot on the wall.  I would prefer to
> see a model creator like Arpad propose a new limit based on
> actual demonstrated requirements where some form of data reduction is
> used.
>
> I feel we should keep this number as small as we can and still create
> accurate models to insure the files sizes and download times are 
reasonable.
>
> I think the biggest problem here is spice to ibis.  People are always
> generating models with the maximum number of points.  I see many many 
models
> that will work EXACTLY the same with 1/3 this many points if they are 
placed
> sensibly instead of using a linear spread.
>
> I am worried that if we set the limit at 1000 we will have all the new
> models with 1000 points......
> Just doesn't make sense to me sorry...  especially with more and more
> VT tables being used.
> best wishes...
> Kellee
>
> At 05:00 PM 6/8/99 -0700, Scott McMorrow wrote:
> >I second Jon's opinon.
> >
> >There is no real reason to limit the number of points in
> >IV or VT tables.  I have often used a simulator which allows
> >an arbitrary number of points over 100 to create high
> >resolution simulations.  256 to 512 is often useful to
> >capture rising edge timing information accurate to 1ps, along
> >with driver overshoot behavior to within 1 mv of HSpice
> >simulations.
> >
> >Model size makes no difference to me.  It is the result that
>
> >matters.
> >
> >Scott McMorrow
> >SiQual
> >
> >[email-masked] wrote:
> >
> >> I agree with Weston.
> >>
> >> Either that or remove the quite artificial limit of number of points 
in
> an IBIS
> >> file.
> >> 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.
> >>
> >> jon powell
> >> Viewlogic Consulting Services
> >>
> >> Beal, Weston wrote:
> >>
> >> > Kellee,
> >> >
> >> > You're disagreeing a mute point.  Your point was the same point I 
was
> trying
> >> > to state by saying, "the IBIS creator tool should have an algorithm 
to
> >> > remove points in linear regions."  We should delete all these extra 
data
> >> > points.  The problem that s2ibis has now is that all points are 
equal
> >> > difference.  They should be closer in knee points and very sparse is
> linear
> >> > regions.  The IBIS creator tool should have an algorithm to clean 
out
> extra
> >> > data.
> >> >
> >> > So, I agree with you and now you can agree with me.
> >> >
> >> > Later,
> >> > Weston Beal
> >> > Signal Integrity Engineer
> >> > Compaq Computer Corp.
> >> >
> >> >                 -----Original Message-----
> >> >                 From:   Kellee Crisafulli 
[mailto:[email-masked]]
> >> >                 Sent:   Monday, 07 June, 1999 2:19 PM
> >> >                 To:     Beal, Weston; [email-masked]
> >> >                 Subject:        RE: [SI-LIST] : IBIS Subcommittee
> Formed to
> >> > Review Spice to IBIS
> >> >
> >> >                 Hi
> >> >
> >> >                 I have a comment on Weston's comment on the number 
of
> data
> >> > points.
> >> >                 I disagree on one point.  Instead of increasing the
> number
> >> > of points generated
> >> >                 in the IBIS file the spice to IBIS tool should 
improve
> the
> >> > quality of the
> >> >                 points
> >> >                 choosen.
> >> >
> >> >                 I can hand build files with 50 points that out 
perform
> files
> >> > with 400 points.
> >> >                 The big gain is that the FILE SIZE is reduced with 
higher
> >> > accuracy.
> >> >                 Large IBIS files will take up many megabytes on 
1000's of
> >> > hard drives.
> >> >                 The V/I and V/T tables are the largest part of IBIS
> files.
> >> >                 Increasing them 4 x will generally increase the file
> size 3
> >> > x or more.
> >> >
> >> >                 >The third thing that I changed was the number of
> points in
> >> > the time
> >> >                 >waveforms from 50 to 101.  I have to remove one 
point to
> >> > comply with the
> >> >                 >golden parser, but I get better detail.  On the 
issue of
> >> > number of points in
>
> >> >                 >a curve or waveform, I think the user should be 
able to
> >> > define any degree of
> >> >                 >granularity and the IBIS creator tool should have 
an
> >> > algorithm to remove
> >> >                 >points in linear regions.  If the resulting curve
> still has
> >> > too many points,
> >> >                 >then increase the linearity tolerance and try it 
again.
> >> >
> >> >                 Best wishes...
> >> >                 Kellee
> >
> ---------------------------------------------------------
> Have a great day....
> Kellee Crisafulli
> HyperLynx, a division of Pads Software Inc.
> SI,EMC,X-talk and IBIS tools for the Windows platform
> E-mail: <mailto:[email-masked]>
> web:    <http://www.hyperlynx.com>
> ---------------------------------------------------------

---

From: Ted Creedon <[email-masked]>
Date: Wed, 09 Jun 1999 13:36:35 -0700

All,

Correctly written software would treat VI curves as objects which could be arrays of
points, fitted curve coefficients, etc.

The point is that the software should not care how you represent your data.

Mentor has developed an object oriented data model for the IBIS spec including C++
header files. The object oriented approach allows IBIS spec changes to be updated with
minimum impact on other software modules.

The IBIS committee should investigate  data modelling prior to getting too involved with
implementation details.

Ted Creedon