RE: [SI-LIST] : receiver jitter

About this list Date view Thread view Subject view Author view

From: Mellitz, Richard (richard.mellitz@intel.com)
Date: Wed Jan 19 2000 - 13:17:45 PST


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
****


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