Kellee makes a good point here. Many times, within s2ibis2, the [Sim time]
is left as 15.0ns when you are just trying to get the Rising waveform or
Falling waveform. Since most devices will switch within the first 3ns, the
rest of the datapoints after 3ns becomes quite useless.
If the model developer uses the proper [Sim time] for the technology being
simulated, a lower number of V/T points can server the purpose very well.
[Sim time] in s2ibis2 dictates the transient simulation time.
Regards,
Syed
Cisco Systems, Inc
>=20
> Hi all,
> =20
> 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.
>=20
> 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.
>=20
> 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=20
> actual demonstrated requirements where some form of data reduction is
> used.
>=20
> 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=20
reasonable.
>=20
> 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=20
models
> that will work EXACTLY the same with 1/3 this many points if they are=20
placed
> sensibly instead of using a linear spread.
>=20
> 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
>=20
>=20
> 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
>=20
> >matters.
> >
> >Scott McMorrow
> >SiQual
> >
> >[email protected] wrote:
> >
> >> I agree with Weston.
> >>
> >> Either that or remove the quite artificial limit of number of points i=
n
> 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 wa=
s
> trying
> >> > to state by saying, "the IBIS creator tool should have an algorithm=
=20
to
> >> > remove points in linear regions." We should delete all these extra=
=20
data
> >> > points. The problem that s2ibis has now is that all points are equa=
l
> >> > difference. They should be closer in knee points and very sparse is
> linear
> >> > regions. The IBIS creator tool should have an algorithm to clean ou=
t
> 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=20
[mailto:[email protected]]
> >> > Sent: Monday, 07 June, 1999 2:19 PM
> >> > To: Beal, Weston; [email protected]
> >> > Subject: RE: [SI-LIST] : IBIS Subcommittee
> Formed to
> >> > Review Spice to IBIS
> >> >
> >> > Hi
> >> >
> >> > I have a comment on Weston's comment on the number o=
f
> 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=20
improve
> the
> >> > quality of the
> >> > points
> >> > choosen.
> >> >
> >> > I can hand build files with 50 points that out=20
perform
> files
> >> > with 400 points.
> >> > The big gain is that the FILE SIZE is reduced with=
=20
higher
> >> > accuracy.
> >> > Large IBIS files will take up many megabytes on=20
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=20
point to
> >> > comply with the
> >> > >golden parser, but I get better detail. On the=20
issue of
> >> > number of points in
>=20
> >> > >a curve or waveform, I think the user should be abl=
e=20
to
> >> > define any degree of
> >> > >granularity and the IBIS creator tool should have a=
n
> >> > algorithm to remove
> >> > >points in linear regions. If the resulting curve
> still has
> >> > too many points,
> >> > >then increase the linearity tolerance and try it=20
again.
> >> >
> >> > Best wishes...
> >> > Kellee
> >=20
> ---------------------------------------------------------
> Have a great day....
> Kellee Crisafulli=20
> HyperLynx, a division of Pads Software Inc.
> SI,EMC,X-talk and IBIS tools for the Windows platform
> E-mail: <mailto:[email protected]>
> web:=A0=A0 <http://www.hyperlynx.com>
> ---------------------------------------------------------
>=20