From: Stephen Peters ([email protected])
Date: Thu Jan 20 2000 - 13:05:12 PST
Chris Cheng wrote:
> i think dc's comment on a previous message is a good start,
>
> frm dc's comment
> 1) There is no way to model the return path effects. IBIS lacks both the
> means for describing the supply connections of drivers and the effect
> on driver performance of nonideal supplies.
> 2) Receiver modeling is very crude, and inadequate for SS applications.
>
> but that's just the symptom of the problem. the real issue is ibis is
> not a circuit description language and is not flexible enough to handle
> the cutting edge design at any given time and the gap is widening. over
> time, the above issues may be solved (i have personally work with cad
> vendors to solve these problems) but the solution is approaching a
> circuit description language which makes it a spice like solution.
Agreed. But who says that IBIS cannot incorporate a circuit description
language? In following this thread I get the distinct impression that
folks are loosing sight of the fact that IBIS is a _data_transfer_standard_,
*not* a simulation model prototype. Now, yes, the current IBIS has grown up
supporting the abilities (or lack thereof) of the current behavioral
simulators, and the current standard reflects this. But there is absolutely
nothing that prevents IBIS from evolving into a standard that incorporates
both nodal descriptions of complex packages and on-die interconnect suitable
for a circuit simulator, while at the same time allowing a behavioral
description (i.e. I/V, V/T) of the transistor level buffer itself. In fact,
such an evolution (IBIS-X) has been proposed and is before the IBIS Forum.
I do not dispute the fact that the current IBIS specification and
behavioral tools lack the critical capabilities required for 'high speed'
(however you want to define it) source synchronous designs. However, I don't
think slinging encrypted transistor level HSPICE models of buffers from vendor
to user is the best solution either. As D.C. and other have
pointed out, there are problems with using spice as a board level SI analysis
tool -- problems with model availability, speed, convergence, name space
collisions, automated data/waveform analysis, etc. Instead of arguing IBIS
vs. SPICE we (the industry) ought to be working towards a modeling language
that supports the circuit simulators nodal descriptions while at the same time
allowing a higher level behavioral description of the buffer (or receiver)
itself.
Regards,
Stephen Peters
Intel Corp.
**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****
This archive was generated by hypermail 2b29 : Thu Apr 20 2000 - 11:34:46 PDT