Re: Future directions for IBIS ... IBIS 2000

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,
>
> 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
>
> "Muranyi, Arpad" wrote:
>
> > 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
> >
============================================================================
> > =============
>
>-- 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