Re: [SI-LIST] : modeling languages (was: receiver jitter)

About this list Date view Thread view Subject view Author view

From: C. Kumar (kumarchi@yahoo.com)
Date: Fri Jan 21 2000 - 10:32:42 PST


Folks:

There seems to be lots of misunderstanding and
confusion over spice, modeling etc. Let me add my
comments. Hopefully it will not add to the confusion.

1. IBIS should remain as a data standard. It should
not be going in the direction of "node description
language" because one already exists viz spice. It is
powerful, flexible and time tested. No good will come
out of reinventing the wheel. IBIS should be focusing
on things like adding thing time-current curves which
will aid greatly SSN modeling and resolve the silly
ambiguties inherent in time-voltage curves.

Fir die/pkg/connectors the langauage to store and pull
in appropriate subcircuits should be standardized at
the cad tool level.

2. Some crucial element types in spice need to be
standardized/added.

For starters a IBIS behavior block element needs to be
added/standardized.

Coupled lossy transmission line elements
added/standardized.

A class of controlled current/voltage sources needs to
be standardized. These sources lie at the heart of a
circuit simulator and the present selection available
in most spice simulators is both unncessarily varied
(like CCVS CCCS etc etc) and yet insuffficient.

3. If item 2 is addressed anything can be modeled.
period. Things like receiver models become merely
standardized subcircuits which will show the same
behavior in different simulators.
--- Jim Freeman <freeman@broadcom.com> wrote:
> Hi Stephen,
> 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.
>
> Jim Freeman
> 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)
> > itself.
> >
> > Regards,
> > Stephen Peters
> > Intel Corp.
> >
> > **** To unsubscribe from si-list: send e-mail to
> majordomo@silab.eng.sun.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
> majordomo@silab.eng.sun.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
> ****
>
>
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

**** To unsubscribe from si-list: send e-mail to majordomo@silab.eng.sun.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
****


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Apr 20 2000 - 11:34:47 PDT