Subject: RE: 100-points limit discussion

From: "Muranyi, Arpad" <[email-masked]>
Date: Wed, 9 Jun 1999 11:29:55 -0700

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

---

From: Fred Balistreri <[email-masked]>
Date: Wed, 09 Jun 1999 14:31:16 -0700

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. 

-- 
Fred Balistreri
[email-masked]

http://www.apsimtech.com

---

From: [email-masked]
Date: Thu, 10 Jun 1999 08:14:35 -0700

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

---

From: "D. C. Sessions" <[email-masked]>
Date: Thu, 10 Jun 1999 16:03:44 -0700

> with no reason, or added accuracy.

I would *hope* that nobody is using raw PWL for modeling.  Not only is
it slow and bulky, but worst of all it's unnecessarily inaccurate.
Cubic spline algorithms are fast and only need to be run once (when the
model is read in) and can even be used with simple scripts supporting
SPICE simulators.  After that you use a piecewise-cubic model with a
minimum of inflection points and NO first- or second-order discontinuities.

The large number of source points is needed mainly to make sure that
there is plenty of coverage in 'interesting' regions, and secondarily
as a mechanism for judging when to remove inflection points.

-- 
D. C. Sessions
[email-masked]