Re: Future directions for IBIS ... IBIS 2000

On Nov 22, 14:14, Ted Creedon wrote:
> Subject: Re: Future directions for IBIS ... IBIS 2000
> 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.

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

>
> 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
>
>
>
> Paul Franzon wrote:
>
> > 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
>
>-- 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