YAFI

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
dc.sessions@vlsi.com