Re: [SI-LIST] : receiver jitter

About this list Date view Thread view Subject view Author view

From: Jim Freeman (freeman@broadcom.com)
Date: Wed Jan 19 2000 - 14:37:48 PST


Haven't we all

Jim Freeman

"Mellitz, Richard" wrote:

> I've got one thing to say about spice.
>
> I've grown to hate the following line:
>
> **error**: internal timestep too small in transient analysis
>
> Rich Mellitz
> Intel
>
> -----Original Message-----
> From: Chris cheng [mailto:hycheng@3pardata.com]
> Sent: Wednesday, January 19, 2000 1:12 PM
> To: si-list@silab.eng.sun.com
> Subject: RE: [SI-LIST] : receiver jitter
>
> >The first was brought up as a major issue at the IBIS forum in June of 1998
> >(San Francisco) meeting. It's been simmering as a back-burner issue since
> >then due to the higher-priority issues of bringing out the 3.2 spec and
> >the connector modeling proposal. Since the connector modeling proposal
> >solves many of the package-modeling problems that were holding up the SSO
> >effort this was a good decision. It looks like the SSO issue is moving
> >back to the front now.
>
> it may be in the front row but it doesn't mean it will be solved. while
> the
> snail of ibis standard is moving, the world of high speed design has
> and will move on. sso has already degenerated into much more complicated
> than just a simple connector or power/gnd inductance model. you have
> multiple power and gnd domain, different return current paths in a
> package,
> core noise and driver switching at different time. none of which a
> generic
> behavioral language can handle.
>
> >The receiver modeling problem is the subject of a request from JEDEC to
> >IBIS and there are three BIRDS addressing it. BIRDs 62 and 63 are fairly
> >noncontroversial and will address many of the worst problems. BIRD 61 has
> >been the subject of some disagreement. These are also moving to a higher
> >priority.
>
> is there any bird to standardize receiver design in the industry? :-)
>
> >None of the obstacles to modeling really fast interconnect systems are
> >inherent to behavioral modeling _per_se_. They *do* point up shortcomings
> >in the present behavioral modeling standard (IBIS 3.2) I would suggest
> that
> >instead of demanding full transistor-level models and process libraries for
> >all of the ICs in your system (which ain't a-gonna happen) or complaining
> >about IBIS' shortcomings that you join the IBIS committee and help solve
> >the problems.
>
> believe it or not if there is a will, there is a way. most of the issue
> of
> not supplying spice model is related to the ignorance of the tech
> support
> people (they simply don't know how to run spice) and not because ip or
> accuracy as they told u. if there is technically capable people on the
> other side of the table, you can get spice model most of the time. i am
> always under the impression spice is a standard circuit and transistor
> language and the only thing that's lagging is an industrial standard of
> encrypting it. why can't we have spice encryption committee instead of
> ibis committee ?
> i have to say for the last time i am not against ibis. it's a perfect
> tool
> for designing mickey mouse buses like pci or jtags etc. its just not
> good
> enough for highspeed design.
>
> **** 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
> ****

**** 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:44 PDT