RE: FW: FW: Spice Model of IBIS

Jon,

You raise a good point. I raised this point originally to question the need
to develop a unique syntax for IBIS, when an existing syntax would prevail.
In my opinion, IBIS should describe a template using existing SPICE syntax
(or XSPICE syntax) so that the engineering community can choose the best
tool for their simulation and analysis, i.e. IBIS simulator or SPICE
simulator.

Pre PCB layout simulation could be simulated quite effectively in SPICE,
with the added advantage that more extensive analysis could be done if
required. IBIS simulators on the other hand have a particular purpose and
hence the analysis as I understand it is limited to time domain waveforms
(rise/fall time, ringing, reflections) and a simple spectral plot. For
instance, I'm not sure how you would calculate the power in a termination
resistor, a simple example, but you get the point.

Regarding crosstalk, I'm not sure how the IBIS simulators work, but I'm sure
that they don't consider crosstalk from one trace to all other traces, but
instead consider only the closest traces (one or two traces). Considering
that some EDA vendors IBIS simulators are actually SPICE simulators with an
IBIS to SPICE translator, I would expect that this problem could also be
solved in SPICE directly. I'm not sure I need to make this point, but I put
it in for further discussion.

My point really is that I may like to use SPICE to do more extensive
analysis than is available with an IBIS simulators. I can take any IBIS
model today and translate it into a SPICE model to examine various issues,
SI, EMC and others. I just find the translation process time consuming and
error prone. In essence, why does it have to be an either or, why can't
SPICE simulators be an extension of IBIS simulators?

Regards

John Synesiou jsynesio@us-power.com
U.S. Power, Inc Phone (612)826-1111
6497 City West Parkway Fax (612)826-1003
Eden Prairie Date: 03/31/98
MN, 55344 Time: 11:45 AM

-----Original Message-----
From: Jon Powell [mailto:jonp@pacbell.net]
Sent: Tuesday, March 31, 1998 11:01 AM
To: jsynesio@us-power.com; ibis@vhdl.org
Subject: Re: FW: FW: Spice Model of IBIS

Well, I just couldn't resist.

I certainly wouldn't argue with anyone that SPICE (actually some SPICE
commercial derivative) is the premier circuit simulation technology that
is currently publically available. I also wouldn't argue with anyone who
said that IBIS has some problems that need to be addressed.

However, the market has shown that there is a need for a PCB SI
simulation technology that offers features that transcend the current
SPICE node based syntax. Think of the bigger problem. You need to
simulate the SI and Crosstalk effects of every net on a PCB. You need
MIN MAX timing from every driver to every receiver. You need SI and
Noise margin numbers for every net. And you need them quickly enough so
that you can use the data to turn the design a couple of times. I
believe these issues are difficult to solve using SPICE as it (they)
exists on the market today.

Of course, I use SPICE every day. I think it is great. I just believe in
using the right tool for the right job and I have more than one job to
do.

Here is a conceptual example:
you have a 32 wire bus. Each wire couples to it's neighbors. You need to
simulate every wire and the effects on that wire by it's immediate
neighbors. You do not want to waste simulation time by simulating
effects of the wires that are more than a couple of conductors away.

How would you solve this problem using SPICE?
Can it be solved automatically?
How would spice represent the names of the different nets? (ie. what is
the crosstalk on D13?).

As for accuracy:
Leave the argument of which approach is more accurate for the moment.
what is the accuracy of your inputs? (PCB stack-up, SPICE model data,
Dielectric constant, trace width).
If you are simulating to a higher accuracy than your data inputs then
you are wasting time and deceiving yourself. I think that a teacher told
me this in 5th grade but I never really believed it until I started
doing SI simulation.
Received on Tue Mar 31 10:34:05 1998