RE: [SI-LIST] : IBIS vs HSpice

About this list Date view Thread view Subject view Author view

From: Bo (bo_pfc@yahoo.com)
Date: Mon Jan 22 2001 - 11:31:32 PST


Hi Todd,

Your question:
> We've run several sets of parallel analyses in HSpice and SPECCTRAQuest for
> circuits running at 200 MHz+, and most of the time, you can take the two
> sets of waveform data and they lay right on top of one another. So the
> point is, if I can run two different simulators and get almost the same
> result, when do I run which one?
 
Has a simple answer: Given that you know both will give you same results you
should use the one that gives you results faster(which is typically IBIS). I
do not how much simulations you perform but I have to do whole a lot of them
and time is of essence in my work. But so is accuracy. So if time allows me
to verify IBIS models with SPICE models than I would pick IBIS models since
they are much faster (by faster I mean the simulation engines process them
easier than SPICE models). And if the simulation waveforms are not the same
than you use the more accurate one (which is accurate one that is what you have
to decide). I have seen to many IBIS models that were done poorly that I have
lost confidence in them. But I have also seen lots of SPICE models that had
similar problems. The advantage of Spice models was that I could look at the
"inside" of the buffer and try to figure out what is wrong with the model and
try manually fixing it. That is the one thing that makes me more inclined to
use Spice models over IBIS.

Regards,
Bo

--- Todd Westerhoff <twester@hhnetwk.com> wrote:
> Thanks to everyone who replied to this thread on Friday. Sorry I didn't the
> chance to reply myself - the day just got away from me!
>
> There were a couple of threads that I wanted to comment on:
>
> The issue of timing, as discussed, seems pertinent only to common-clock
> transfer schemes - where Tco is valid and is an important of the timing
> equation. The concept of timing changes significantly when you talk about
> source synchronous transfer (or, so I think) - and you end up concentrating
> on skew between receiver signals as opposed to flight time.
>
> As an aside, we looked at various static timing tools for source-sync
> analysis, and concluded that because they treat each ssync bus as a clock
> domain unto itself, they really don't buy you much of anything at the system
> level (for ssync). Anyone have a different idea?
>
> I expected the issue of the "accuracy of IBIS" to come up - I would have
> been surprised if it hadn't. And, as was pointed out - IBIS is just a spec,
> and it's up to the tools as to what they do with it. So, we need to concern
> ourselves with both the robustness of the spec, and the quality of the
> different implementations.
>
> ... and, we got a couple of good methodology comments. Jon Dowling's
> comments concur with my own experiences - the buffer designers are happiest
> if you can give them targets to shoot at without burying them in detail.
>
> But, my original question still remains ...
>
> ... what's the *difference* ?
>
> I don't mean the difference in an theoretical sense, listing effects that
> SPICE models and IBIS does not (and yes, behavioral vs. silicon level
> analysis would probably be a better description). I mean - the difference
> on a *practical* level. And yes, I realize it's an impossible question.
>
> We've run several sets of parallel analyses in HSpice and SPECCTRAQuest for
> circuits running at 200 MHz+, and most of the time, you can take the two
> sets of waveform data and they lay right on top of one another. So the
> point is, if I can run two different simulators and get almost the same
> result, when do I run which one?
>
> Here's one for discussion - receiver modeling and noise immunity. The IBIS
> receiver model is simplistic, modeling the receiver as, effectively, a set
> of voltage comparators and a capacitance. Real receivers have different
> characteristics, and pass or filter pulses in a more complex manner. So -
> SPICE analysis of the receiver circuit at some level is prudent if I'm
> trying to understand critical die to die system timing.
>
> Other ideas?
>
> Todd.
>
> Todd Westerhoff
> SI Engineer
> Hammerhead Networks
> 5 Federal St
> Billerica, MA 01821
> (978) 671-5084
> twester@hhnetwk.com
>
>
>
> **** 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
> ****
>

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

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


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Tue May 08 2001 - 14:30:42 PDT