RE: [IBIS] Re: [IBIS-Users] BIRD95: Power Integrity Analysis Using IBIS

BIRD95 reminds us of the difficulties associated with the current profile
issue, but hopefully this time we can work it through to a conclusion. My
comments:

1) Norio Matsui may have raised the most important issue, the fact that
there may not be exactly one bypass capacitor and one pre-driver section
associated with one buffer, all sharing current from one supply. In fact
this case seems quite unlikely. Scaling the total bypass capacitance,
pre-driver current and output current for an arbitrary slice of a component
down to one of it's buffers should a model that is likely not very accurate
for any single buffer, or for any collection of buffers unless the
collection happens to be equal to those in the slice. And a single current
profile still doesn't solve the correct apportionment of current to paths
from distinct power supply voltages.

2) Accepting for the moment that we are attempting to represent multiple
current paths with a single table here, why not specify ground current
instead of power current? Isn't it more likely that all of these currents
flow through a single ground plane than through a single power plane?

3) Although the IBIS specification limits itself with regard to explaining
how a simulator might use the data, I feel that some effort might be
warranted here to advance the cause of consistency among simulators. For
starters, should we have some words of wisdom explaining that the current
out of the pad can be determined, and represents the difference between the
current into the power supply (if there is only one) and out through ground
(if there is only one). Digging deeper, how will the simulator decide how
much of the current passing through ground is "crowbarred" through the
pullup and pulldown, versus passing through the other current path formed by
the bypass capacitors and pre-drivers? This has a bearing on the turn-on/off
rates chosen for the pullup/pulldown. Mainly I would like to see some
discussion of this from simulator people, to validate that the simulation
outcome is deterministic. Even if there has been discussion already within
the IBIS committee, it would be good to make a record in the IBIS
specification for future implementers.

4) I think the text should clarify that positive values represent current
flowing into the buffer.

5) Although it may seem obvious, maybe the specification should clarify that
in the case of open_XXX models, where current is supplied by the test
fixture, that current is not to be accounted for in the [Series Composite
Current].

6) What would the [Series Composite Current] profile look like for a
differential output buffer? Presumably these must be taken as a pair, and
the total current for the pair ideally remains nearly static. Should we
require the measurements to be taken this way, or should we allow model
makers to provide separate P and N models with different current profiles?

7) The proposed [Series Composite Current] keyword associates itself with a
preceding [XXX Waveform] keyword, and is thus position dependent. Some
existing IBIS keywords are position dependent. For example, [Ramp] is part
of a second level of hierarchy under [Model]. But I think [Series Composite
Current] would be a third level of hierarchy, being under [XXX Waveform],
which is under [Model]. Is this OK, or would it be better to simply add 3
more columns to the [XXX Waveform] tables?

8) Can the [Series Composite Current] keyword follow only some [XXX
Waveform] tables and not others?

9) The text describes [Series Composite Current] as current flowing through
R_VDD, but the circuit diagram calls it R_VDDQ.

10) More nit picking: I had to modify the ASCII circuit diagram to make it
line up right.

It's great to be discussing this important issue again. Overall I am left
wondering if the various current paths can reasonably be merged into a
single table.

Mike LaBonte

-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Syed Huq
Sent: Tuesday, December 28, 2004 1:31 PM
To: Michael Mirmak; ibis@eda.org; ibis-users
Cc: Bob Ross; Lance Wang; Randy Wolf
Subject: [IBIS] Re: [IBIS-Users] BIRD95: Power Integrity Analysis Using IBIS

Hi Matsui-san,

Thanks for your questions/comments on BIRD95. We are including our responses
below. Pls feel free to let us know if you have more questions.

Regards,
Syed--
IBIS Vice-Chair & Webmaster
Cisco Systems, Inc

On Sun, 2004-12-26 at 09:00, Mirmak, Michael wrote:
> Comments from Matsui-san on BIRD95.
>
> - MM
>
> ______________________________________________________________________
> From: matsui [mailto:matsui@apsimtech.com]
>
> My comments and thoughts on SSO and EMI models are below.
>
> 1. If I_bypass is described as a current source, it may not be
> right.
> Series current source always feed the same current to out side.
> I think the I_bypass and C_p+b may be in parallel. Or voltage
> source
> is OK. All current source models must have admittance or
> device models
> in parallel. The current waveforms will be varied by loads and
> admittance/
> impedance of switching transistors. The admittance/impedance
> consists
> of linear power rails and nonlinear transistors. I remember
> Arpad has
> presented nonlinear model of C_comp.

Cisco:(1)
I_bypass is not a current source. I_bypass simply represents current
that flows through the bypass components.

> 2. There are two types of core models. One is shown in the bird.
> The other (I think this is more popular) type of core logic is
> not connected
> to I/O buffer. I/O core logic may be connected to lower
> voltage sources
> with no I/O.

Cisco:(2)
We have internally discussed that I/O and core voltages can be different
and the pre-driver can be supplied with either.

> 3. SSO needs time domain model. EMI needs frequency domain model
> and time
> domain model. The frequency domain model means linearized
> model and it
> is an approximation. Current sources should be described in
> real and imaginary
> parts at various frequencies. The parallel admittance, if it
> is a macro model, may
> be approximated as real and imaginary parts at various
> frequencies.
> Time domain model of cores is more preferable for SSO and EMI,
> because
> switching transistors have strong non linearity. Current
> source model is a kind of
> linear approximation. Current waveforms are results. Constant
> external voltage
> sources are switched by nonlinear transistors. Only current
> sources can't describe
> load effects. They need nonlinear admittance / impedance.
> Transistor or behavioral
> model may describe these effects.

Cisco:(3 and 6)
Again BIRD95 has no current sources. BIRD95 based simulations will have
more accurate EMI results than pre-BIRD95 simulations. However, BIRD95
is not specifically directed towards EMI simulations. EMI simulations
are best addressed with the ICEM model.

> 4. How to simplify the models of power rails on a chip and a
> package is another
> serious issue. Even for a package, number of die pads and
> balls for power/ground
> I/O. ICM and SPICE may be OK, but too complex model with too
> many terminals are
> not good for simulation.
> 5. All the core logic is connected to common power rails with some
> different DC levels
> and the power/ground rails are connected to number of die pads
> and package balls.
> A figure of Bird 95 seems to consist of one I/O and one core
> logic. I think the starting
> point may be more realistic structures of an LSI chip.

Cisco:(4 and 5)
Common Spice package models are scaled down to a slice of the package
with a handful of drivers. It should be possible to scale the model down
to a single buffer.

> 6. I think there is a big difference between SSO and EMI models. A
> simple EMI simulation
> does not need individual power I/O pin models. But accurate EMI
> simulation may not
> accept this model.
>
> Best Regards,
> Norio Matsui
>
>

-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
Received on Wed Dec 29 08:33:51 2004