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
> ============================================================================
> =============
Received on Mon Nov 22 10:52:20 1999