Subject: Future directions for IBIS

From: "Muranyi, Arpad" <[email-masked]>
Date: Fri, 19 Nov 1999 17:04:13 -0800

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

---

From: Ted Creedon <[email-masked]>
Date: Mon, 22 Nov 1999 10:49:35 -0800

All,

Perhaps we should revisit the need for IBIS in the first place. Couldn't
proprietary information be distributed through the simulator vendors using
public/private keying?

Regarding the "nodal simulator" discussion, there is a very fine modeling
language in the documentation for a microwave simulator used for the MMIC
program in the 90's. I have the source code under license and have read the code
extensively as well as several versions of Spice code. The MMIC simulator does a
particularly fine job of goal based parameter optimization, including
syntactical representations of typ[min,max] parameter values and also does yield
analysis based on manufacturing statistical tolerances.

It isn't clear how a behavioral simulator would "call" Spice since Spice isn't
set up to be callable. Spice wants to build the Y matrix from parsed input and
invert it in the time domain. We should recall that Spice 3f5 is an integrated
circuit simulator which does not support nonlinear devices in the frequency
domain (which are used to characterize interconnect).  And I don't see any
analysis tool vendor except one that intends to correlate calculated vs measured
results (i.e. loss tangent, Er, anisotropic Er, skin effect, surface roughness,
etc., etc.).

The discussion has left out the Boolean capabilities in WSpice which may be
required to characterize buffers.

And all this needs to run in a finite time.

The subject of analog design languages has a varied history going back to the
AHDL workshops at Dartmouth in 1985.  The analog designers abandoned the effort
to the CS majors since the need for graphical input representation couldn't be
met with a 128 key keyboard!

Anyway, this is no small effort. I agree with the basic notion that as digital
design speeds are now up to 10GHz, and PC designs are running up to 400Mhz
baseband with 50-100 ps risetimes, the need for microwave style modeling is
clear.

Ted Creedon

---

From: "Paul Franzon" <[email-masked]>
Date: Mon, 22 Nov 1999 16:13:05 -0500

I think both Arpad and Ted raise some very good issues.  I would
like to recommend that the community takes a moment to think where
they want to take IBIS in the next century....IBIS 2000???

Feedback/comments are welcome.

Some global comments:

o IBIS succeeded because it created an accepted standard for distributing
  simulatable descriptions of I/O buffers.  Prevous attempts at encrypted
  I/O model distrubution basicly failed for a variety of reasons
  (proprietary/custom spices, IP conerns, too much effort, etc.).  In
  comparison IBIS is an enourmous success.  It solved the 'I dont
  want to/cant give out the Spice netlist for my driver' problem.

o From a technical point of view, the IBIS standard is somehat arbitrary
  in terms of its makeup and is IMHO suffering
  from creeping functionalism.  For example (on the arbitrariness), when
  writing 2ibis, we had to make arbitrary decisions about how the
different
  parts of the circuit response are assigned to the different parts of the
  macromodel.
 (BTW, this does not detract from the utility of the tool at all)

o IBIS does not lead to accurate SSN prediction and IMHO no
straightforward
  extension will be able handle this or return path issues properly.  A
  fresh start is needed.  IBIS has already run out of steam for the ultra
  high speed board designer.

Some recommendations for 'IBIS 2000':

o Keep IBIS 1.
  Keep a behavioral standard that can has a large level of agreement
  and buy-in.  In fact, do not abandon IBIS as it exists now.

o Change the direction for future IBIS enhancements.
  Here could be some recommendations:
  - From a technical point of view, IBIS should be mainly be a set of
    macromodels that properly capture I/O edges and Vdd and Gnd
transients.
    (BTW, the latter is somewhat difficult.)  Table-based VI
    macro-models are appropriate.
  - It should be possible to produce this macromodel from a Spice netlist
    (S2ibis) or a measurement procedure.
  - It should be possible to translate the macromodels into the more
    popular spice flavours with a very simple 1:1 translation.

o Drop including the package.
  There is no technical reason why IBIS should be getting into package
  parasitic modeling.  Why cant vendors just distribute an RLC netlist?
  There is no reason to invent a new standard for this (vanilla Spice
  is fine) and I fail to see how such netlists can be considered
  core corporate IP and thus have to be protected (please let me know
  if this last statement is wrong).

  With proper netlists, the accuracy of SSN, package xtalk and return
  path simulation would go up.

o Keep the concept of the IBIS model also documenting SI requirements.
  This is not done properly elsewhere in the documentation, so might as
  well leave it here.

o Keep the concept of an agreed-upon-standard.  It has worked well to now.

I do feel that there is a need for fundamental and open work on what
is needed to accurately model a driver with a macromodel.  IBIS 1
worked fine just by thinking the issues through a little.  IBIS 2000
needs some experimental investigative work as to how it should approach
macromodeling.  Eyeballing a model wont work.

That work could be be done in an Industry lab or
(shameless plug follows) in an open University setting.  (SRC would
be the appropriate sponsor, by the way).

Regards,

Paul

On Nov 22, 10:49, Ted Creedon wrote:
> Subject: Re: Future directions for IBIS
> All,
>
> > =============
>
>-- End of excerpt from Ted Creedon

-- 
---Paul Franzon, Professor, North Carolina State University
919 515 7351, fax. 919 515 2285, www.ece.ncsu.edu/erl/faculty/paulf.html
Rm. 443, Engineering Graduate Research Center, Centennial Campus
smail: ECE, Box 7914, NCSU, Raleigh NC 27695-7914
Fedex: Rm. 419, EGRC, 1010 Main Campus Dve, NCSU, Raleigh NC 27695-7914

---

From: Ted Creedon <[email-masked]>
Date: Mon, 22 Nov 1999 14:14:28 -0800

Absolutely agree on using university types to help on the language definition
and need for funding.

RLC will not be satisfactory for all packaging. Need lossy coupled transmission
lines.

Let's think in the reverse direction - top down.

Suppose we have the perfect language, what would it do?

Accept IBIS
Accept Spice
Accept a N port network description language (NDL)
Accept graphical input
Accept measurement based tables of S parameters (or Y or Z) by frequency or NDL
equations
Others I haven't thought about

The common thread I see here is network description objects. An object being
defined as data and methods in its own container. That is, an object knows
enough about itself to be able to describe itself to you.

The theory here is that if an object oriented language can be fashioned, we
don't care about the implementation details which is where we're hung up.

I can share the Agile user manual with whoever, it's not in machine readable
form. It would be possible to stick Agile on a server somewhere so interested
parties could play. Its a Motif/unix app. that uses the linpack nonlinear pde
solvers and it was written in C by 2 RF electrical engineers. Took about 8 man
years including comparing calculated vs. measured results.

Perhaps a Smalltalk parser and Matlab solver would work for protyping.

Ted

---

From: "Paul Franzon" <[email-masked]>
Date: Mon, 22 Nov 1999 18:22:13 -0500

On Nov 22, 14:14, Ted Creedon wrote:
> Subject: Re: Future directions for IBIS ... IBIS 2000

Sorry, Ted, I was not clear.  I meant an RLC matrix in Spice format.
This handles losses and coupling.  It can also handle frequency-dependent
losses in a practical sense (ie. up to a cutoff frequency).

The advantages are that the format is well known, widely used and
can handle just about anything (though sometimes a little clumsilly
e.g.  S-parameter information has to be fitted to an RLC ladder network).
The disadvantages is needing a smart parser for other formats, e.g.
S parameters.

It sounds like you are leading towards the concept of the 'Universal
parser' for packaging-related info and with some common format.  ie. Take
in format X, produce simulatable format Y for simulator Z.   A lot of
these pieces already exist, scattered around various vendors.  Also,
Verilog-AMS
and VHDL-AMS most likely has standards for some of these formats.   A
Universal parser would be a significant development effort.  Many parts
of this would have definite value as some of the vendor stuff is very
buried in one simulator or expensive.

Regards,

Paul

> > > program in the 90's. I have the source code under license and have
read
> > the code
> > > syntactical representations of typ[min,max] parameter values and
also
> > does yield
> > > It isn't clear how a behavioral simulator would "call" Spice since
Spice
> > isn't
> > > domain (which are used to characterize interconnect).  And I don't
see
> > any
> > > analysis tool vendor except one that intends to correlate calculated
vs
> > measured
> > > The discussion has left out the Boolean capabilities in WSpice which
may
> > be
> > > The subject of analog design languages has a varied history going
back
> > to the
> > > AHDL workshops at Dartmouth in 1985.  The analog designers abandoned
the
> > effort
> > > Anyway, this is no small effort. I agree with the basic notion that
as
> > digital
> > > baseband with 50-100 ps risetimes, the need for microwave style
modeling
> > is
> > > clear.
> > >
> > >
> > > Ted Creedon
> > >
> > > "Muranyi, Arpad" wrote:
> > >
> > > > Hi IBIS folks,
> > > >
> > > > I decided to write this EMAIL on the future directions for IBIS to
air
> > some
> > > > a conversation so that we could make good decisions.  I will try
to
> > talk in
> > > > The spec starts getting out of hand mostly because of the
inflexible
> > keyword
> > > > structure and inconsistencies.  Keywords have very specific
functions
> > and
> > > > syntax and/or keyword in different situations.  For example, I
just
> > wrote
> > > > 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
> > > > with keywords that are called "package" something.  So the next
option
> > > > 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
> > > > To sum it up, we have four areas for interconnect modeling, each
of
> > which
> > > > 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
> > > > problems and clean it up and make it more efficient.  However, at
the
> > same
> > > > 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
> > > > 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
> > > > 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
> > > > any function (S-parameter, and you name it).  In a general case
they
> > let you
> > > > behavioral and possibly full SPICE description capabilities.
 Doesn't
> > this
> > > > results are in raw data format, and there are no good post
processing
> > tools
> > > > IBIS style behavioral buffers (building blocks) to SPICE tools?
 What
> > if we
> > > > 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
> > > > black box approach with a possible merger with IMIC, add SPICE
support
> > into