From: Jim Freeman (firstname.lastname@example.org)
Date: Fri Jan 21 2000 - 09:24:36 PST
If "a _data_transfer_standard_, *not* a simulation model prototype." as you say below, then the term of art "models" that is used in the industry and
first promoted by Intel as such should NOT be used in connection with the term IBIS.
P.S. I have refrained from any further comments on this thread but revisionist history really syeams me. Intel is practicing the basic bait and switch
tactic with the attitude propounded below.
Stephen Peters wrote:
> 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)
> Stephen Peters
> Intel Corp.
> **** To unsubscribe from si-list: send e-mail to email@example.com. 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
**** To unsubscribe from si-list: send e-mail to firstname.lastname@example.org. 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:47 PDT