From: Todd Westerhoff (email@example.com)
Date: Thu May 03 2001 - 11:28:07 PDT
You're being generous. At 3,5 and 10 GHz, I think the ice has long since
melted. For that matter, it's not obvious to me than any of the traditional
time-domain tools will correctly predict what interconnect does at those
But you're right - examples do help, and I should have offered some.
Below 200 MHz, and with regular I/O's, I think IBIS will do just fine.
Above 200 MHz, or when when the edge rates get down to 200pS or less, I'd
suggest backing the IBIS analysis with SPICE, though.
Our recent experiences show another problem - cases where IBIS models
represent the I/O adequately, but where the device timing is so loosely
spec'd that integrating SI and timing analysis becomes difficult. As an
example, we have a whole set of parts where Tco timing is spec'd into a 50
pF load - not representative of loading in an actual system. Using a
conventional approach, we found the drivers would violate both setup and
hold margins at the receiver.
Only when we went back to the vendor's buffer designers did we find out that
Tcomax was spec'd into a 50pF load, while Tcomin was spec'd into a no-load
condition. Needless to say, neither the datasheet nor IBIS model reflected
this. As a result, Tcomin into the actual system load was much larger (>1
nS more) than the previous analysis led us to believe, and the hold-time
problems were provably non-existant.
But it gives rise to the question - how useful is it to chase 50pS of timing
accuracy in SI analysis, when your device timing specs have close to 1nS of
slop to start with?
Admittedly, this case was unusual, and only occurred because these (older)
parts were spec'd into large capacitive loads, and the datasheet specs were
only partially documented. But my point is - you have to know where all
your inaccuracies are, and keep everything in perspective.
As far as power/ground bounce analysis with IBIS goes, there are some
serious questions there. The data in the IBIS model doesn't tell the
simulator what currents are flowing through each transistor during the
switching event, and it has to make assumptions. The nominal assumptions
are probably close - but the point is, the information is not
deterministically supplied by the model. This was a pet peeve of Kumar's,
and he advocated changing the V-T data in IBIS to V-T-I data to correct
this. My suggestion would be - if you're going to try and do power analysis
with an IBIS model - correlate current flow against SPICE before you spend a
lot of time running IBIS analysis. Otherwise, you're _assuming_ the results
correlate, and we all know what happens when we _assume_ ....
From: Mark Alexander [mailto:Mark.Alexander@xilinx.com]
Sent: Thursday, May 03, 2001 11:48 AM
To: Todd Westerhoff
Subject: IBIS or SPICE examples
Todd et al,
Many of us are familiar with the fundamental differences between SPICE and
-- one is difficult and highly accurate, the other is simple and moderately
accurate. What might be more useful in this discussion is information from
personal design experience about when you would use one versus the other.
For example, up until recently my department used IBIS exclusively for our
design and simulation. These boards involved single-ended signals running
0 to 200 Mhz and differential signals up to 840 Mhz. However as we move
the world of high-speed serial channels at 3, 5 and 10 Ghz, the ice on the
pond gets a bit thin.
Right now we're running both SPICE and IBIS simulations of our systems in
to make sure we're seeing everything we need to. Our concerns stem both
the general aspect of IBIS's approximate nature, as well as the specific
of package modeling. Detailed package modeling within the confines of the
spec is difficult. We see differences in our simulation results (between
and IBIS), though we're just beginning to draw conclusions as to what's
them and how we can improve the IBIS model.
Others have commented that in order to model systems with a non-ideal power
plane, you have to use SPICE because no one yet makes an IBIS simulator that
handle non-ideal power planes. I'm not very deep in this realm... can
Todd Westerhoff wrote:
> The answer to your question is: it depends.
> IBIS is actually a language for characterizing I/O behavior that has a
> defined structure and syntax. That's the long way of saying it models a
> defined subset of all possible I/O behavior. SPICE, on the other hand,
> model anything. Want to model viscous fluid flow through a pipe? Sure -
> come up with the correct electrical equivalent model, and SPICE can handle
> it for you.
> So, "it depends", means that you have to understand the interconnect and
> you want to analyze, and whether or not behavioral analog simulation will
> model enough of the effects properly to give you a reasonable answer. If
> IBIS provides an adequate answer, then by all means, use it. And, if IBIS
> won't give you the detailed answer you want, you still may be better off
> running IBIS up-front to get you in the ballpark, before you run a SPICE
> analysis. This is especially true if you're running pre-route analysis
> looking at a number of different scenarios. We regularly analyze hundreds
> and thousands of "variations" at a time using IBIS models, receiving
> within minutes. You can imagine what the turnaround time would be if we
> were doing things differently.
> But for I/O structures that IBIS cannot address, SPICE may be your only
> choice. And for critical applications, it's almost always worth the
> to look at structures with both forms of simulation, to make sure the
> answers correlate.
> I view simulators as tools. They help you get a job done, but you have to
> understand what their limitations are, how to use them, and to which
> problems they are best applied. Please don't expect a simulator or SI
> to give you an answer - because it won't. Its purpose is to give you
> on which you can base design decisions.
**** To unsubscribe from si-list or si-list-digest: send e-mail to
firstname.lastname@example.org. 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
This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:50 PDT