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

From: "Beal, Weston" <[email-masked]>
Date: Mon, 7 Jun 1999 09:12:10 -0500

Michael,

I think this is a worthy endeavor and I applaud your goal.  I've been using
s2ibis2q (my Compaq version of s2ibis2) for a couple of years, and have a
few particular items that I see as weaknesses.  The three items which I
fixed were easy and didn't take much time.  First the default of 2
significant digits in the spice output was much too little.  I changed it to
5 digits and have seen good results.  In reality, this should probably be
configurable from the control file.  
The second thing that I fixed was to subtract both the power clamp and
ground clamp curves from the pullup and pulldown curves.  In general, this
is not needed, but I don't want it to bite me in the shorts when I'm not
looking.

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.

One other thing that bothers me is that the data input files (spice output
files) must have the same number of data points at the same voltage or time
values.  I realize that it would take a bit more work, but I would expect to
be able to give any three sets of data and have the IBIS creator interpolate
and extrapolate as needed in order to create complete IBIS tables.  This is
not needed when your spice models behave nicely, but how often does that
happen?  Most of the time, my spice simulations do not converge very far
outside the normal operating range and I am forced to fake data or cut off
the good data to the same range as the problem data.

Regards,
Weston Beal
Signal Integrity Engineer
Compaq Computer Corp.

		-----Original Message-----
		From:	[email-masked] [mailto:[email-masked]]
		Sent:	Friday, 04 June, 1999 4:26 PM
		To:	[email-masked]; [email-masked]
		Subject:	[SI-LIST] : IBIS Subcommittee Formed to
Review Spice to IBIS

		Hello everyone.

		On May 28, 199, the IBIS Committee, via the IBIS Open Forum
Teleconference,
		formed a subcommittee to determine the viability of taking
ownership of the
		Spice to IBIS (s2ibis2) tool, originally written at North
Carolina State
		University.  This subcommittee will eventually report back
to the IBIS Committee
		the following:
		    1.  Any known bugs with the current tool.
		    2.  Any future enhancements for the next generation tool
(s2ibis3).

		From these lists, the IBIS Committee and this subcommittee
will draft a
		"requirements" list, and pending funding, request bids from
various sources to
		update/rewrite the tool.  Like the IBIS Parser, we want to
keep the Spice to
		IBIS tool in the public domain (open source).

		As chairperson of this subcommittee, I am asking for your
help.  If you are a
		user, or one of the many programmers, of the current Spice
to IBIS tool, I am
		looking for your feedback to make the next tool better.  If
you know of any
		bugs, or have any enhancement requests, please let us know
by posting your
		comments to either the IBIS or SI reflector.  If you wish to
keep your comments
		psuedo-confidential, please feel free to send them directly
to myself at
		"[email-masked]".  Please be as specific as you can.  In
the case of bug
		reports, we may need to contact you off-line to get more
information and/or
		testcases.

		Please send your responses no later than June 18, as we will
be discussing this
		topic at the IBIS Summit Meeting, which will be held Monday,
June 21.

		Disclaimer:  all participants on this subcommittee, as well
as those on the IBIS
		Committee, are volunteers, attempting to make this tool
better.  We are not
		getting paid, nor receiving any benefits, from this work.
So please, be kind
		with your comments.

		Regards,
		Michael Cohen

		IBM Personal Systems Group
		Design Tools Department
		D-26D/B-201/R-D104H
		3039 Cornwallis Road
		Research Triangle Park, NC 27709

		Phone:  919-543-4042 (T/L 441-4042)
		FAX:  919-543-8221 (T/L 441-8221)
		Internet Address:   [email-masked]

		IBM Internal Addresses:
		    From Lotus Notes (#1):   Michael Cohen/Raleigh/IBM
		    From Lotus Notes (#2):   micohen@ibmus
		    From VM:   micohen@ibmusm21

		**** To unsubscribe from si-list: send e-mail to
[email-masked]. In the BODY of message put: UNSUBSCRIBE
si-list, for more help, put HELP.  si-list archives are accessible at
http://www.qsl.net/wb6tpu/si-list ****

---

From: Kellee Crisafulli <[email-masked]>
Date: Mon, 07 Jun 1999 12:18:33 -0700

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.

>then increase the linearity tolerance and try it again.

Best wishes...
Kellee

---

From: Syed Huq <[email-masked]>
Date: Wed, 9 Jun 1999 09:04:20 -0700 (PDT)

Hi,

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

> 
> 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
> >> >                 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.
> >> >                 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
> >> >                 >points in linear regions.  If the resulting curve
> still has
> >> > too many points,
> ---------------------------------------------------------
> 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>
> ---------------------------------------------------------
>