Future directions for IBIS

Hi IBIS folks,

I decided to write this EMAIL on the future directions for IBIS to air some
of
my thoughts on this subject. I would like to get you thinking and stimulate
a conversation so that we could make good decisions. I will try to talk in
general
terms so that we can see things in a broader view, but I will also give some
examples to illustrate the issues.

The spec starts getting out of hand mostly because of the inflexible keyword
structure and inconsistencies. Keywords have very specific functions and
assumptions,
that's what makes them so inflexible. Inconsistencies prevent the reuse of
the same
syntax and/or keyword in different situations. For example, I just wrote
BIRD 64, and
found out that what I thought was a very simple addition was impossible. I
wanted to
make a package selector keyword that is identical to the model selector
keywords, but
it couldn't be done, because the rules are different for the package model
names and
buffer model names. One allows 40, the other allows 20 characters. One
allows spaces,
the other doesn't.

I also started to write a BIRD on (what I thought) a simple keyword that
would have
allowed the on-die power distribution and return path modeling. It would
have
resembled the [Pin Numbers] keyword from the package section, except it
would have
described the interconnect between die pads and buffer models on the die.
The idea
is great, but syntactically does not work out as simple as it could. Why?
Because
the [Pin Numbers] keyword depends on a few other keywords ([Number of Pins],
[Number
of Sections], [Model Data], etc). They could all be reused, but two changes
would
have to be made in two of those keyword's usage rules. Besides, these
keywords are
all called "package" something, and it would be too confusing to describe
die-interconnects
with keywords that are called "package" something. So the next option would
be to
basically copy the whole package chapter with these minor name and rule
changes into
a brand new chapter called "Die Interconnect Modeling". This, however,
increases the
size of the specification, duplicates a lot of things but also increases the
number
of inconsistencies.

Thinking about this problem I started to wonder whether I could use the EBD
or new
connector proposal, but I realized that each one of these have some specific
characteristics which result in the same situation.

To sum it up, we have four areas for interconnect modeling, each of which
needs a separate
chapter in the spec. This is ridiculous, because each of these are
interconnect models!
We should be able to come up with a syntax that is general enough to handle
them all!

I don't want to hold back the approval of the new connector spec. We need
it badly,
and it is way too late. I am just talking about all this so we can make a
better plan
for the future.

Now, we have an option to take the spec and rigorously look at all these
syntactical
problems and clean it up and make it more efficient. However, at the same
time we
are beginning to feel the need for nodal connectivity. The new connector
spec proposal
introduces nodal connectivity in the [Begin_Cn_Pin_Map] keyword into IBIS.
Stephen's
IBIS-X proposal revolves heavily around nodal structuring, and I was going
to use
something similar to the [Begin_Cn_Pin_Map] in my unfinished
die-interconnect BIRD
also. So we all agree that this is a must. The question is whether we
should do it
through "mapping" keywords, or the good old SPICE way (or any other newly
invented
syntax).

Regarding buffer modeling: Stephen's proposal of an API is essentially a
hook to
SPICE simulators from behavioral tools which would be used mostly when there
are new
features that can't be described by existing IBIS keywords. Can't do it in
IBIS, so
do it in SPICE (from an IBIS simulator). Again, it seems that we want SPICE
capabilities. But why? Because IBIS is inflexible. What if IBIS could do
what
IMIC can do? Describe a buffer on a transistor level with behavioral
transistors.
Or take an intermediate level, describe a buffer with a building-block
architecture,
using primitives. A primitive could be as low as an IMIC behavioral
transistor,
but could be a basic inverter, or a block of the whole buffer, such as
predriver,
output stage, receiver, etc. This way one could put together a model
behaviorally,
using any level of abstraction according to the need of the buffer's
characteristics.
However, this would also require nodal connectivity.

Oh yes, I almost forgot about equations. These are a special kind of
controlled
sources. Yes, behavioral. Allowing any node to be connected to another
node by
any function (S-parameter, and you name it). In a general case they let you
reference any node voltage and/or branch current a part of the equation (not
all
SPICE tools do this well). These animals can't exist without a nodal
approach
either.

So we want nodal connectivity a netlist type approach for any level of
abstraction,
behavioral and possibly full SPICE description capabilities. Doesn't this
sound
like a SPICE with enhanced behavioral elements?

Let's turn around the picture. What does SPICE not have that IBIS has?
Most SPICE
flavors do not do too well on behavioral modeling, and board level
simulation hooks.
Board file readers are missing, measure statements are stone age style. The
simulation
results are in raw data format, and there are no good post processing tools
to interpret
the results.

What if we added IMIC style behavioral transistors to SPICE tools? What if
we added
IBIS style behavioral buffers (building blocks) to SPICE tools? What if we
added
nice and useful measurement statements? Add a front end tool that reads PCB
layout
files. Add a 3D graphical output visualization tool to interpret the
results. (Some
IBIS tools could learn more about this too).

No matter how we look at it, it seems to that we are experiencing the need
for a merger
between the SPICE world and the behavioral tool's world. It seems to me
that SPICE
addresses buffer design, while behavioral tools address system design with
their
main features. With the emerging needs in system design, BOTH kinds of
tools are
lacking, even though SPICE is still good for buffer design. The real
question in my
opinion is: How can we improve on our system design tools?

What is easier to do? Clean up IBIS and invent a nodal language, advance
the behavioral
black box approach with a possible merger with IMIC, add SPICE support into
them though
an API, or take the existing SPICE tools and add those "system design"
features that
IBIS tools have and are good at?

I would like to read a lot of replies to this one...

Arpad
============================================================================
=============
Received on Fri Nov 19 17:04:51 1999