Re: YAFI

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

"D. C. Sessions" wrote:

> 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
Received on Fri Dec 3 15:50:55 1999