RE: [SI-LIST] : IBIS datasheets for PCI and DDR

About this list Date view Thread view Subject view Author view

From: Muranyi, Arpad ([email protected])
Date: Tue Nov 16 1999 - 14:05:14 PST


Fred,

Very good comments, and I would like to put an emphasis on the
assumption you make, IF the models are correct (big IF). It is
also true that SPICE models can or usually have a lot more detail
so they can be more accurate (if done correctly). But detail does
not equal accuracy. And, it is very true that they both have their
appropriate places for use. A circuit designer will not get anything
done with IBIS models, but a system designer will probably never get
his/her work done with SPICE models either.

I want to point out another thing that kind of hit a nerve. You
mentioned the number of BIRDs (64 and counting) in the IBIS case.
To be fair, you should have also mentioned the number of SPICE
flavors that exist. These exist mostly because each vendor has some
(unfortunately incompatible) "value added" feature. In addition, look
at the number of "levels" each SPICE has for the various models, some
of which are, again, incompatible. BSIM alone has at least three levels,
and BSIM3 of one tool does not necessarily work with another tool
supporting BSIM3. You don't even have to use different flavors of SPICE,
just think about one of the comments someone made about the scaling factors.
You simply can't simulate with two SPICE models, if one of them uses
certain scaling factors that another model doesn't need unless you rewrite
the model (good luck). (Of course this is only a problem for those who do
system level simulations where you must have more than just your own
design's SPICE model).

I don't claim that IBIS is perfect, it is an evolving standard, mostly
done by volunteer efforts. I also wish that it would have a lot more
badly needed features, that it would be more consistent and more general.
We have serous talks now about these issues among the "IBIS officials".
We want to fix the shortcomings. However, if we point these problems
out for IBIS as negatives or drawbacks, we should also be honest and
admit that SPICE DOES have similar problems, even if it may seems to be
a more stable language...

Arpad Muranyi
Intel Corporation
======================================================================

I agree strongly with most of the statements but disagree with the
accuracy issue. Assuming that the SPICE model is correct and the IBIS
model is correct, there is no way that an IBIS model can be more
accurate than a SPICE model. This is regardless of where the IBIS
model came from. Keep in mind that MOST IBIS models are produced from
the SPICE model using s2ibis. That means by default MOST IBIS models
cannot be more accurate than the source. For one thing SPICE is a
different animal and contains much more information regarding both the
topology and process of the design. Secondly there have been and
continue to be accuracy as well as other issues with IBIS. If this were
not the case there would not be 64 birds to date and counting.

Both the IBIS and SPICE model are prone to incorrect data. Being not
correct is NOT the same as model accuracy. In my view both SPICE and
IBIS models have their application. There is some overlap in the SI
community. You probably should not use SPICE models to simulate a
whole board. But accuracy is a different issue. For most SI applications
IBIS will do. But there are cases where one may need the SPICE model.

Best Regards,

-- 
Fred Balistreri
[email protected]

http://www.apsimtech.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/si-list ****

**** 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/si-list ****


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 11:39:50 PST