Subject: YAFI

From: "D. C. Sessions" <[email-masked]>
Date: Fri, 03 Dec 1999 16:15:24 -0700

Yet Another Future IBIS

I've been looking at this from the point of enumerating IBIS' strengths
and weaknesses.  As follows:

1)      IBIS strengths
        Good at simulation of classical CMOS drivers
        Adequate for TTL receivers
        OK for passing device pinouts
        OK for uncoupled package parasitics
        OK for selectable drive strength
2)      IBIS weaknesses
        No return-path models
        Poor receiver modeling
        No coupled parasitics
        No coupled drivers (e.g. Open-drain current-mode differential)
        No present method to model source modulation (gate starvation)

The trouble is, the very things that IBIS doesn't do well (e.g. return
path modeling) are exactly the things that are turning out to be the
limiting factors in newer systems (e.g. source-synchronous systems.)

As several others have pointed out, a lot of this isn't so much a problem
with IBIS _per_se_ as it is a matter of IBIS taking on a job which isn't
fundamentally behavioral and where a structural interconnect model works
quite well.  After all it's not as though manufacurers are worried about
giving out metal-interconnect data that can be found by anyone with a
DVM.  Which argues, to me, that we should quit trying to reinvent the wheel.

3)      Proposed future course
        Use IBIS [Model] for drivers and receivers
        Enhance IBIS as needed to model input behavior
        Enhance IBIS as needed to model gate starvation
        Use EDIF netlist to model on-chip return paths
        Use connector syntax or netlist to model package parasitics

I'm not religious about the EDIF part.  An extended SPICE format that
allows distributed parasitics would be just fine by me; maybe we should
provide for both in the same way that HDLs can be both behavioral and
structural.  The main thing is that a netlist-like format is really
necessary to define the return-path and coupling effects that are taking
over our applications.

Now the radical part to me is the question of whether the result will
be IBIS-calling-other-formats or other-formats-calling-IBIS.  From
a heirarchical point of view, IBIS is at the lowest level of detail
and you get all kinds of inversions trying to do it any other way.
If there isn't presently some appropriate system-interconnect language
that still doesn't mean that we should somehow make IBIS extend to both
ends of the scale; it means that an appropriate top-level language needs
to be created.  IBIS -- whatever it becomes -- stays at the bottom of
the abstraction stack.

Decoupling the need for a system-interconnect language from IBIS per se
allows us to solve the problem without burdening the effort with the
addition of another, perhaps nonbeneficial, constraint.  The connector
group seems to have done just that with good results.

-- 
D. C. Sessions
[email-masked]

---

From: Christopher Reid <[email-masked]>
Date: Fri, 03 Dec 1999 15:49:44 -0800

Hello,

Mostly I agree with D.C.  A netlist type structure is the only
sensible route forward; otherwise IBIS will be burdened with
frequent changes to take account of the latest ideas of how
to model these effects (which we are already seeing in the
proposals to split up C_comp.)

I'll vote for an extended SPICE syntax because I think that
is most natural for this problem.  We could make IBIS devices
that already exist into subcircuits callable by this syntax,
or we could redefine the current structures using the new
syntax.  I don't agree that IBIS is at the bottom of the abstraction
hierarchy because it already contains some fairly complicated
constructions.  The bottom of the hierarchy is the IV curves,
threshold detectors, etc.

Chris