I have attempted in the past to include the effects of other traces in my
SPICE runs. Up to now my analysis has been on differential pair
transmitters and receivers. I have tried to model two pairs, using the W
model internal field solver. It is a bit tough getting all the dimensions
in correctly and requires some knowledge of PCB physics but I got the model
built. Unfortunately I did not run much on the order of analysis. I ran
out of time. I am now running some analysis again on a higher speed serial
link at 2.5Gb/s. I have not yet run any adjacent nets on this one either.
I have another week to work on this and then it is back to board design
unfortunately. I probably will on get to make some runs on the one
differential pair net.

I have extracted the W Type Transmission model using the Star-HSPICE
internal field solver. I specify the construction of the net on the board
through physical dimensions and properties and then let HSPICE do the rest.
There are two other ways of specifying the W model; one is to use RLGC
matrices and the other is to use the U model as part of the W model
specification.

I am currently in the throws of performing some pre-routed simulations on a
design I am working on. In the past I have stuck to running my analysis
using HSPICE. Typically this analysis has been limited to reflection SI
and not crosstalk or simultaneous switching. We work mostly with serial
data link verification so following the net from output driver through the
interconnect to the receiver is the topology of choice. We then evaluate
the data eye by simulating and measuring data jitter. HSPICE has been
working fairly well, the W model for transmission lines has improved in the
recent future and therefore improved our hardware to simulation
correlation.

We are currently trying to work with our Cadence EDA tool SpecctraQuest to
take a different approach to simulation. The tool has advertised the
ability to per from Crosstalk and SS analysis as well as Reflection. This
sounds great and we are trying to use it. The problem is that Cadence
ultimately uses their own proprietary model type (DML) which they derive
from IBIS models. The trouble is that our IO folks for the TX and RCVs
create SPICE models. So I must translate the models from SPICE to IBIS.
This has been fairly painful, the models for our components are fairly
complex. I have yet to get an accurate IBIS model for a given SPICE model.
I am fairly sure that with enough time we could get close but we don't have
the time. So for now we stick with net by net simulation with HSPICE. It
sure would be nice if Cadence imported the SPICE model directly.

Conclusion is that SPICE to IBIS conversion is painful and time consuming,
not even considering model accuracy.

When we eventually need to attack other types of simulation (SS and
Crosstalk) we are looking at very complex multinet HSPICE decks .... Oh no
:)

**** To unsubscribe from si-list or si-list-digest: send e-mail to
majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****

**** To unsubscribe from si-list or si-list-digest: send e-mail to
majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****