Re: YAFI

I cannot agree more with Christopher. Nobody needs to
reinvent the wheel. The extesnions or better agrees
standard extensions to Spice are not that numerous
either. Basically you need two agreed standard

1. Multi coupled lossy tlines

2. Controlled current source (table , equation driven
with provision for event triggering)

--- Christopher Reid <chris_reid@mentorg.com> wrote:
> 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
>
>

__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
Received on Mon Dec 6 03:07:52 1999