RE: 100-points limit discussion

Folks,
        I have been following this discussion and will reiterate my opinion
(given in the most recent IBIS open forum). We have both an internal IBIS
format and internal tool that originally had a 100 point IV curve limit
(just like IBIS). I found it necessary to increase the number of points in
order to accurately model technologies which use high current and are
terminated (small changes in V can translate into big changes in I). I found
insufficient points in the IV curve caused DC level problems and AC
transient inaccuracies. We increased our internal limit to 1000 points which
resulted in significant improvement in model accuracy and sufficient
headroom so we don't have to visit this again.

my $0.02
Bob

Robert J. Haller
Compaq Computer Corporation
AlphaServer Product Development
Phone: (978) 493-4112
Fax: (978) 493-0941
robert.haller@compaq.com

-----Original Message-----
From: jonp@pacbell.net [mailto:jonp@pacbell.net]
Sent: Thursday, June 10, 1999 11:15 AM
To: Fred Balistreri
Cc: Muranyi, Arpad; ibis@eda.org
Subject: Re: 100-points limit discussion

Fred,

We don't use S2IBIS here at Viewlogic. We use an internal tool (that I
developed).
It is tied heavily to XTK as it uses it for auto QA and such.

We are planning on making it available as a product but right now it isn't
supportable enough to sell (or give away) to the general public. Things
like, it
only runs on certain Unix platforms.

My group does use this program (called VML for Virtual Modeling Lab) to
write and
QA the IBIS models that we generate for IC companies.

regards,
jon

Fred Balistreri wrote:

> A few points need to be clarified in Arpad's statements. The 100 point
> limit did not
> come from the SPICE world. It came from a restriction in the particuliar
> brand of
> SPICE being used by ????? at the time. As an example my company is a
> SPICE vendor with
> no restriction on PWL number of points. Our derivitive is Berkeley SPICE
> 3C1 circa
> 1980's something. Basing a standard on third party EDA vendor
> restrictions is @#*%#$#@!
> in my opinion. My point here is don't blame this on SPICE. There is
> enough blame going
> around the SPICE world. This is an IBIS problem. B source may be new in
> some SPICE
> programs but its been around at least since Berkeley 3C1 SPICE.
>
> Secondly as a model builder my two cents are that 100 points were fine
> in the original
> IBIS when there was no v/t information. If done correctly 100 points
> for I/V
> information is more than enough. The addition of v/t information may
> have changed all
> that.
>
> Thirdly, s2ibis is a public program written by students at UNC, and at
> that its
> origin is now maybe 3 or 4 years ago. Why is the whole IBIS world
> relying on this
> tool? There are a few multi hundreds of million of dollar in sales EDA
> companies and
> at least one over 1 billion in sales EDA company that claim support for
> IBIS. Yet all
> of these companies I am led to believe rely on an old public domain
> software program.
> Oddly enough there is enough complaints and questions brought up by
> s2ibis that an
> innocent bystander would have plenty of doubts about this program! My
> point here is that IBIS is the standard NOT s2ibis....and there are
> alternatives to
> s2ibis albiet not free.
>
> In my opinion the 100 point limit can be lifted as it seems that its a
> problem
> already.
>
> Muranyi, Arpad wrote:
> >
> > All,
> >
> > I agree with all of you, and at the same time a also disagree with some
of
> > the points raised (no pun intended).
> >
> > 1) I believe that we are mixing at least two issues here. One is on
the
> > subject of the number of points limit in the IBIS specification, the
other
> > is regarding how s2ibis generates points. The third one relates to the
> > intelligence and experience of the model maker. (There is no need to
run
> > a waveform simulation for 20 ns at 1 ps step time generating 20k points
> > when the edge reaches steady state in 2-3 ns and 3k points would be
> > sufficient,
> > as someone already mentioned it).
> >
> > IBIS does not need uniformly spaced data, in fact, in Section 3 the spec
> > says
> > the following:
> >
> > | 9) The V/I data tables should use enough data points around sharply
> > curved
> > | areas of the V/I curves to describe the curvature accurately. In
> > linear
> > | regions there is no need to define unnecessary data points.
> >
> > It is not stated, but this also applies to V-t curves. The problem is
that
> > s2ibis doesn't know how to pick the best 100 points, so it generates
> > uniformly
> > spaced data with a bunch of redundant, unnecessary points in the linear
> > regions.
> > This uses up the 100 points quickly without much benefit, just because
the
> > software doesn't have a best 100 point picker routine. We should not
blame
> > the IBIS spec for this deficiency.
> >
> > 2) On the other hand, YES, I do agree that we need to raise the points
> > limit
> > in IBIS because the way things are now DOES limit much needed accuracy
in
> > some
> > cases. I demonstrated this in a test case when I overlaid the waveforms
of
> > a
> > SPICE and its equivalent IBIS model. The question is what should be the
new
> > magic number.
> >
> > 3) History / current situation: The real reason for the 100 points
came
> > from
> > the 100 point limits of the PWL sources in the SPICE world. We didn't
want
> > to
> > exclude SPICE vendors and users from behavioral simulations. To make
that
> > possible without having to ask each SPICE vendor to rewrite all of their
PWL
> > sources, we had to introduce the 100 point limit. There were no
technical,
> > engineering reasons behind this rule.
> >
> > We found the first problem when I was writing my "Best 100-points"
algorithm
> > (for my IBIS Center program that we use internally to make IBIS models).
I
> > realized in this process, that there is a difference in the outcome when
we
> > count the X-axis points, or the Y-axis points because the typ., min.,
and
> > max.
> > tables use a common X-axis. When the three sets of Y-axis data are
curved
> > in
> > different areas of the X-axis, in the theoretical extreme we could end
up
> > with
> > 300 X-axis points while each of the Y-axis has only 100 points. The
IBIS
> > 1.1
> > specification did not say anything about how the 100 points were
supposed to
> > be
> > counted. We did discuss this in the Open Forum Teleconference, but
choose
> > not
> > to do anything about it in terms of changing or clarifying the IBIS
spec.
> > It
> > was verbally said, however, that we should count X-axis points to be
safe.
> >
> > I don't remember whether I found this before IBIS 2.1 was ratified or
later,
> > but
> > somehow the most important IBIS 2.1 addition, the V-t curves ([...
Waveform]
> > tables) inherited the same problem.
> >
> > IBIS 3.x has a few I-V curve related additions. It seems that in effort
to
> > make
> > the spec clearer we not only defined it better for the new keywords, but
for
> > the
> > sake of consistency we also changed the wording in the usage rules
section
> > of the
> > old keywords, such as the [Pulldown], [Pullup], [GND Clamp] and [POWER
> > Clamp].
> >
> > | ...first and last voltage points on any V/I table. Each
V/I
> > | table must have at least 2, but not more than 100,
voltage
> > | points.
> >
> > where "voltage points" defines that the counter should count 100 X-axis
> > points.
> > It is interesting to note that the [... Waveform] keywords were still
left
> > vague
> > in the IBIS 3.x spec:
> >
> > | ...parses down the table. The waveform table can contain a
> > | maximum of 100 data points. A maximum of 100 waveform
> > tables
> > | are allowed per model. Note that for backward
> > compatibility,
> >
> > 4) Now, why did I write this all down? Well, to give some sense for
the
> > proposal
> > that I am about to make here. It can be seen from the above history
that,
> > for one,
> > the spec is still inconsistent regarding how to count the points in the
> > waveforms
> > and I-V curves, but more importantly, there is no technical reason for
the
> > X-axis
> > counted 100 points in the I-V curves.
> >
> > There is another piece of information that is necessary before I make my
> > proposal.
> > I have not seen any generic PWL source in any SPICE flavor which can
handle
> > one
> > X-axis column with multiple Y-axis columns. So if someone uses generic
> > controlled
> > sources in SPICE for building behavioral models which use IBIS data,
they
> > will have to
> > separate the typ., min., and max. columns of the IBIS model into three
> > separate PWL
> > sources. Therefore, if we still want to support any SPICE tool by
observing
> > their 100
> > point limits in the PWL sources, it is sufficient to count the points in
the
> > Y-axis.
> >
> > On the other hand, if there are newer implementations in SPICE that
support
> > IBIS data
> > directly, such as the new B-element in HSPICE, chances are that being
new,
> > they can
> > easily implement any (new) IBIS rule.
> >
> > 5) So, based on all this, I propose that we should allow for counting
100
> > points
> > in the Y-axis. This will still work with any old SPICE PWL source, yet
> > would
> > significantly raise the accuracy of the curves. By doing this, we are
> > really
> > not changing the original intent of the spec.
> >
> > One problem that Bob raised in a private conversation to me is that this
> > will force
> > NA-s into the Y-columns, which is not desirable, even though it is
perfectly
> > legal.
> > For this reason he suggested that we should just allow 300 points as
counted
> > in the
> > X-axis, which essentially yields the same level of accuracy. The
problem I
> > see with
> > this method is that this way the Y-axis can also end up with 300 points,
> > which may
> > prevent the data be used in old SPICE PWL sources.
> >
> > 6) On the other hand, if we do not care about SPICE PWL sources, we can
> > raise the
> > limit to practically any number. The things we need to consider then
are
> > what some
> > already brought up in this discussion, file size, distribution, but I
would
> > add
> > speed of simulation also. My understanding is that the larger the
tables
> > get, the
> > more if-then-else evaluations will need to be done which can slow down
the
> > simulator.
> >
> > 7) I tend to agree that unlimited points may not be a good idea,
because
> > (forgive me)
> > there is no cure for laziness and stupidity. We may end up with a lot
of
> > large files
> > with no reason, or added accuracy.
> >
> > Please comment.
> >
> > Arpad Muranyi
> > Intel Corporation
> >
============================================================================
> > =======
>
> --
> Fred Balistreri
> fred@apsimtech.com
>
> http://www.apsimtech.com
Received on Thu Jun 10 08:43:58 1999