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

Todd,

BIRD95 is not proposing that die-level power delivery elements be
simulated by an IBIS simulator.
It is proposing that die-level parasitics and bypass capacitance effects
be included when the IvsT information is derived.

In other words, if a SPICE circuit is used to derive IvsT (for BIRD95)
and VvsT (for the IBIS buffer model), in order to improve accuracy, we
think the SPICE circuit should include die-level parasitics and bypass
capacitance instead of a perfect supply.

A couple of other reasons to include die-level parasitics and bypass
capacitance in deriving IvsT, VvsT:
a) The encrypted SPICE model may include these elements, making it
difficult to remove their effects.
b) The die-level parasitics and bypass capacitance information is not
readily available to an IBIS tool/model user.

Thanks,
Vinu

Todd Westerhoff (twesterh) wrote:

>Arpad's comments make a lot of sense to me. If we're trying to make
>enhancements to IBIS to support SSN analyses and can't correctly predict the
>device's behavior in light of VDDQ modulation, then what are we really going
>to accomplish?
>
>I think BIRD95 is headed in the right direction, but that we may be trying
>to accomplish too many things at once. We're mixing together modeling of
>the die-level power delivery system (ESR, ESL, bypass capacitance), modeling
>the currents the buffer draws during operation and modeling of a device's
>core operating current. That's a really ambitious goal, and I think we
>might be better served by tackling some of these things individually (and
>sequentially).
>
>Why don't we focus first on extending the IBIS buffer model to correctly
>represent current draw from the supplies as well as I/O pin behavior? We've
>seen many times in other forums where people advocate (and are adamant
>about) the use of SPICE models for evaluating SSN behavior. If the original
>charter for IBIS was to provide a "black box" method for predicting a
>buffer's behavior at its output terminal, why shouldn't we simply extend
>that charter to include the modeling of behavior at the supply terminals as
>well? An IBIS model that produced the same supply and output terminal
>behavior as its SPICE counterpart could/should offer a significant advantage
>in computation speed.
>
>More importantly, if we define the IBIS buffer model's purpose as producing
>the same currents and voltages at its interface pins [meaning supplies as
>well as I/O pins] as its SPICE counterpart, then we have a reasonably well
>defined method of establishing and validating the IBIS model's behavior -
>namely, using the SPICE model with associated voltage and current probes.
>
>I believe that even this task will be a challenging one. Getting the
>model's behavior to scale accurately with varying supply references is new
>algorithmic ground, and getting this to correlate against SPICE will not be
>easy. Getting these algorithms implemented in commercial tools consistently
>and within a reasonable time period won't be easy either - but it's worth
>doing.
>
>If we had an IBIS model that reproduced a corresponding SPICE buffer's
>external behavior, then we should be able to drop that buffer into the same
>circuit used to evaluate SSN using a SPICE buffer model and reproduce the
>SPICE results everyone else uses as a reference. That will help IBIS
>acceptance, and that keeps the IBIS ball rolling forward.
>
>I don't believe we need to worry about modeling the die bypass capacitance
>or parasitics at this point. This is an incredibly complex problem where
>the methods are just being defined, and are sure to change over time. One
>thing is sure, though - no matter how these parasitics are extacted and
>modeled, they will probably be expressed as general purpose structure. If
>we are able to model buffer characteristics correctly and combine that with
>general purpose structure, we should be able to model whatever comes along.
>
>I think all the IBIS tools have to innate ability to model general purpose
>structure in their simulators anyway. Even those that don't provide a
>general purpose syntax like SPICE to describe the netlist have the ability
>built into their engines to support general structure - it's just a matter
>or exposing it to the user.
>
>Bottom line, I suggest we focus on getting IBIS models to accurately
>reproduce SPICE behavior at ALL of their terminals. I've heard the same
>arguments as Arpad - "yeah, but IBIS can't model this effect, or that
>effect" wwwaaaayyyyyy too many times. I don't think the argument will
>really ever end, but I'd like to win the "IBIS is equivalent" argument more
>often than I currently do.
>
>My $0.02.
>
>Todd.
>
>
>
>Todd Westerhoff
>High Speed Design Specialist
>Cisco Systems
>1414 Massachusetts Ave - Boxboro, MA - 01719
>email:twesterh@cisco.com
>ph: 978-936-2149
>============================================
>
>"Always do right.
> This will gratify some people and astonish the rest."
>
>- Mark Twain
>
>
>-----Original Message-----
>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi,
>Arpad
>Sent: Tuesday, January 04, 2005 5:04 PM
>To: ibis@eda.org; ibis-users
>Subject: [IBIS] RE: BIRD95: Power Integrity Analysis Using IBIS
>
>Mike (and Syed),
>
>Nice comments! Your main concern raises a question in my mind regarding
>on-die power delivery (passive) networks. This subject has popped up here
>and there in discussions, but so far no one has raised it as an issue so
>clearly and as importantly as you and Norio Matsui.
>
>Up until now we have considered a buffer having a single point Power and GND
>connection (unless it was using different supply voltages for clamps).
>Except for some groupings done by the good old [Pin Mapping] keyword, these
>supplies were all shorted together with all power and GND pads.
>
>It seems that if these concerns you and Norio are raising are driven by a
>common need, we would also need to consider how power is distributed between
>the buffers and their sub-blocks.
>
>However, if one of the primary purpose of doing BIRD95 is to make better SSN
>simulations possible (including the power delivery networks), we would also
>need to consider the so-called "gate modulation effect" for which I have
>heard a lot a IBIS criticism since the mid 90's. (This effect is the one
>that reduces the drive strength of the output stage due to the supply
>voltage reduction which arises with power delivery noise). If we don't
>account for that, no matter how well we know how the currents are
>distributed between power GND and the output, they are still going to be
>wrong...
>
>Now, adding more than 4 supply nodes to a buffer is not possible with
>[Model] or [External Model], only with [External Circuit].
>This implies that describing predriver currents independently could only be
>done with models using the new language extensions.
>To me it seems that Syed's proposal is an attempt to provide an interim
>solution using the legacy buffer modeling techniques.
>The level of detail you and Norio brought up could only be addressed by the
>new generation of models which will be written with those languages. I hope
>that by then we will also figure out how to use ICM with IBIS to describe
>the on-die passive interconnects to make it all work together.
>
>However, the gate modulation effect could still be described relatively well
>within the legacy IBIS framework with a few simple parameters. For an
>example we could look at how HSPICE's B-element does it with the "spu_scal"
>and "spd_scal" parameters. These were implemented on our request to do just
>that, but there are no IBIS keywords or subparameters to transfer these
>coefficients in an IBIS file. I wonder whether we should include these
>features in BIRD95?
>
>Regarding #4, current should be positive into the power node, into the I/O
>node, but OUT OF the GND node.
>
>Regarding #6, very good point, but it all depends on whether the diff pair
>is just two independent single ended buffers driven in the opposite
>directions, or a true (current source + current steering
>transistors) construction. Legacy IBIS can't do the second one, period. So
>how would someone translate a measurement done on a true diff buffer to a
>model that can only do two single ended buffers driven in opposite
>directions? I am not saying that this is impossible, but I don't see an
>immediate solution, and I didn't spend time on thinking about it yet.
>
>There is another issue that I ran into recently in connection with
>differential buffers when they are designed with bipolar transistors.
>It is a pain taking IV curves of these, because due to the nature of the
>bipolar output transistors the two outputs are much less independent as in
>the case with MOSFET outputs. (The nature of bipolar transistors is such
>that the output voltage will have a great effect of the bias levels of the
>predrivers, and thereby other half of the output). I don't know what we can
>or should do with these animals in an IBIS I-V curve sense. This is not
>necessarily a BIRD95 problem, but since you brought up your question, I had
>to mention it.
>
>Regarding #7, I feel these tables should be under subparameters inside the
>[xxx Waveform] keywords. That way there would be no confusions. (I hope).
>
>Arpad
>==================================================================
>
>-----Original Message-----
>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Mike
>LaBonte
>Sent: Wednesday, December 29, 2004 8:34 AM
>To: ibis@eda.org; 'ibis-users'
>Subject: 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
>
>-----------------------------------------------------------------
>|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
>
>
>

-----------------------------------------------------------------
|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 Jan 5 12:31:04 2005