Re: [SI-LIST] : receiver jitter

About this list Date view Thread view Subject view Author view

From: Scott McMorrow ([email protected])
Date: Wed Jan 19 2000 - 10:50:04 PST


Chris,

Chris cheng wrote:

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

You obiviously have not read the latest IBIS connector proposal.

Multiple power domains are not precluded from behavorial descriptions.
One describes interconnect "behavior" in SPICE using nodal
connectivity language. I am not sure the even SPICE is appropriate for
some of the non-TEM modes of propagation within package structures.

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

Unfortunately, when SPICE models are encrypted it it next to impossible
to resolve fundamental simulator issues, such as convergence, without
support from the vendor. If a vendor's models were to exist in a vacuum
then this might not be a bad thing. However, many of my SPICE issues
stem from interoperability of multiple vendor supplied models within
the same simulation.

Perhaps SPICE would be more useful if there were some standards
to provide better encapsulation of necessary information about the model
such as the extraction assumptions, and subcircuit interface documentation.

regards,

scott

--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com

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


About this list Date view Thread view Subject view Author view

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