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.

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
Received on Mon Nov 22 14:15:35 1999