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

Mike,

Our responses below to your questions.
Happy Holidays,

Syed

-- 
IBIS Vice-Chair & Webmaster
Cisco Systems, Inc
On Wed, 2004-12-29 at 08:33, Mike LaBonte wrote:
> 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.
> 
Cisco:
BIRD95 only addresses the case where the pre-driver and buffer share the
same power rail.
If a bypass capacitor is shared, it has to be scaled. Pre-driver and
output current need no scaling because they will be obtained from Spice
simulation of a single buffer. Since only one power rail is modeled, a
single current profile is sufficient.
Our proposal is mainly for the last stage of I/O power
supply which we called VDDQ.  The IvsT table is only associated with
VDDQ at this time.  For the VDDQ net within one I/O buffer, We didn't
see the need to seperate the currents go through the different bypass
capactiors or different pre-drive circuit.  One lumped current should be
good enough.
This brings up the point of how even a regular IBIS buffer model is to
be derived. Should the IBIS model be derived from Spice that includes a
bypass network or a perfect supply?
If a pre-driver is connected to core Vdd, it needs to be integrated into
the ICEM core current profile model.
> 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?
> 
Cisco:
The reasons why we only provide the current from VDDQ not GND are: #1.
VDDQ noise is what we care for SSO simulation. #2.There could be other
power supplies with the I/O buffer, so the GND current is the
combination (in a certain degree) of the all power supplies current. It
is impossible to seperate the I_VDDQ from the total current when there
is only one IvsT table is provided.
> 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.
> 
Cisco:
For a majority of the cases, we think the simulator does not have to
know how much of the current is crowbar and how much is pre-driver.
If this becomes important it may have to be handled in a future
enhancement over BIRD95.
> 4) I think the text should clarify that positive values represent current
> flowing into the buffer.
> 
Cisco:
Agreed.
> 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].
> 
Cisco:
We should be able to do this.
> 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?
> 
Cisco:
If IBIS always models differential buffers as two single-ended ones, the
power modeling will do the same. If IBIS can handle true differential
buffer, we could add IvsT table for that case later. SSN impact with Diff
buffers may not be as significant compared to single-ended buffers.
> 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?
> 
Cisco:
We would prefer not to add 3 more colums to the [XXX Waveform] but we
are open to suggestions. This is more of a format/keyword placement
issue.
> 8) Can the [Series Composite Current] keyword follow only some [XXX
> Waveform] tables and not others?
> 
Cisco:
Yes. In the case of Open_Drain, some of the tables will no longer be
present.
> 9) The text describes [Series Composite Current] as current flowing through
> R_VDD, but the circuit diagram calls it R_VDDQ.
> 
Cisco:
We will fix this.
> 10) More nit picking: I had to modify the ASCII circuit diagram to make it
> line up right.
> 
Cisco:
Is this because of the width settings on your Email client. We can fix
any format issues.
-----------------------------------------------------------------
|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