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

Thanks Zhiping,

Your comments and the recent discussion by all has been very
constructive and informative.

I believe Todd is right. When we can drop an IBIS model into a design
and get the same results as the SPICE model we're basically there for
starters. We'll improve as we go. We'll have to as design continues to
get more challenging and varied.

If we meet Todd's test when do we get in trouble on the accuracy issue?
Not when we meet our design margins easily -- don't waste any more time
on that one. Not when we don't have a chance of meeting our design
margins -- change the design. It's when we're close but not quite there
and have run out of options. Modeling and simulation isn't perfect and
when we've run out of options we have to prototype. Even there we
usually have few options, but I'd rather go into that situation with the
guidance of modeling and simulation than without.

Best Regards,

Roy

Zhiping Yang wrote:

>Hi Roy,
>
>Very well said about the IBIS model.
>
>For current BIRD95, our intention was not to completely solving the power
>integrity problem in one proposal. As a first step to improve the IBIS
>model capability and accuracy in SSO simulation, we proposed to add IvsT
>information of the I/O power pin into existing IBIS model. We think this
>IvsT table will provide enough info on Xbar current, Pre-driver current from
>VDDQ, internal termination current and embedded decoupling current within
>I/O cell which are neglected in current IBIS model. We really not expect
>IBIS model with added IvsT info could complete replace the SPICE model in
>SSO simulation, but we do think it can greatly reduce the simulation
>accuracy gap between the SPICE model and IBIS model.
>
>About the "gate modulation effect" Arpad and Todd mentioned, I think it is
>more like a problem which can be correctly addressed by EDA tool vendor.
>Certainly in order to correctly solve this problem in IBIS, the IBIS model
>should provide enough information for the EDA tool vendor to use them. For
>the current IBIS, the power is assumed to be perfect, so there is no correct
>way to consider this effect in the EDA tool. With the introduction of
>BIRD95, EDA tool vendors could think how to simulate power noise due to I/O
>switching (as a first step, the mutual impact between the I/O network and
>power network may not be able to fully considered). I think it is
>relatively easily to implement the impact of I/O noise to the power network,
>but it is relatively hard to implement the impact of power noise to the I/O
>network by using IBIS model. I may be wrong. There are a lot of smart
>people in the EDA industry and they may be able to figure out how to
>implement it correctly (or closer to the SPICE model).
>
>Best regards,
>
>Zhiping
>
>
>----- Original Message -----
>From: "Roy Leventhal" <Roy.Leventhal@ieee.org>
>To: <twesterh@cisco.com>; <ibis@eda.org>; "'ibis-users'"
><ibis-users@eda.org>
>Sent: Wednesday, January 05, 2005 1:54 PM
>Subject: RE: [IBIS] RE: BIRD95: Power Integrity Analysis Using IBIS
>
>
>
>
>>All,
>>
>>I've been reading this thread with interest. At the outset let me agree
>>
>>
>with
>
>
>>Todd and Arpad, and then talk a bit out of the other side of my mouth.
>>
>>First, the whole point of "black box" modeling is that you don't quite
>>
>>
>know
>
>
>>what is really going on inside the black box, but you don't care as long
>>
>>
>as
>
>
>>the model is adequate for doing design. Or, what's macromodeling for -- a
>>close cousin to behavioral modeling -- anyway?
>>
>>Especially, design with some safety margin. Engineers have always had to
>>
>>
>be
>
>
>>satisfied with some level of approximation in modeling and deal with it.
>>
>>
>The
>
>
>>test of "goodness" was always -- can the model bring me within an
>>engineering approximation (+/-20%?) of reality? This assumes that all
>>
>>
>other
>
>
>>sources of error and variation are known and accounted for. It seems to me
>>that this is the approach of IBIS to begin with and should be the
>>
>>
>objective
>
>
>>of the extension into SSN/SSO that we are undertaking. Face it, we've got
>>nothing out there now and the need is acute.
>>
>>The question is, can we come up with an acceptably accurate model for
>>
>>
>design
>
>
>>purposes? The push on the envelope of technology says that our modeling
>>effort may always lag the need somewhat. There will always be a need for
>>physical level (SPICE) modeling when you are working with new technologies
>>and critical applications.
>>
>>IBIS is "a work in progress," so is modeling. We know about "gate
>>
>>
>modulation
>
>
>>effects," and we know that board stackup placement of supply planes
>>
>>
>affects
>
>
>>mounting inductance, bypassing and other factors. Thus, solving some
>>problems really require an unprecedented level of cooperation and modeling
>>between semiconductor supplier and OEM user. For most users and suppliers
>>that level of effort and cooperation is beyound their means. This level
>>
>>
>of
>
>
>>effort cannot be afforded across an entire product design even for those
>>with the the means to perform it on really critical circuits. A good
>>
>>
>design
>
>
>>process flow helps you focus an appropriate level of resources at an
>>advantageous point in the design cycle. Not to bludgeon every design to
>>death with analysis and accuracy when you can simply make clever choices
>>
>>
>of
>
>
>>architecture and desensitization.
>>
>>Can we provide power integrity modeling and guidance that will raise early
>>warnings as to where a design might be getting into trouble with SSN/SSO?
>>When the design is tight and the options are few will the designer know
>>
>>
>when
>
>
>>to go to physical level modeling?
>>
>>I don't believe we should be purists about the IBIS black box approach,
>>either. At times it's appropriate to go to SPICE modeling and we should
>>facillitate this. We've already taken steps by supporting other HDLs.
>>
>>Before we say that SPICE modeling is the answer to everything - it ain't
>>necessarily so. Most SPICE models I've seen are:
>>
>>Not fully parameterized -- to many idealized and default parameters in a
>>typical model
>>Do not include the relevant process variation information
>>Do not include the full relevant IC structure that needs to be analyzed
>>
>>And, most of SPICE is itself parameterized and linearized. Not derived
>>directly and dynamically from the underlying physics equations.
>>
>>If you say that all of my objections about SPICE are answerable and
>>
>>
>accurate
>
>
>>data is available -- for what? 10% of design problems? Perhaps the most
>>important/challenging 10%, but what of the other 90%?
>>
>>IBIS does an excellent job addressing the 90% problem in signal integrity.
>>Let's see if we can begin extending it into power integrity. Because, the
>>same issues that started IBIS in signal integrity exist in power
>>
>>
>integrity:
>
>
>>Unwillingness of suppliers to provide information enabling reverse
>>engineering of their products.
>>
>>Technical inability to provide the information. Aside from Intel and a few
>>others, who has staff with the necessary expertise?
>>
>>No relevance to process control (versus circuit characterization) only.
>>
>>
>When
>
>
>>did you last look at a SPICE diode clamp with resistance set to zero
>>
>>
>because
>
>
>>that's OK in process control? Don't clamps crowbaring into the power bus
>>structure figure in? Who is going to pay the semiconductor supplier for
>>
>>
>all
>
>
>>this extra modeling for a circuit design problem?
>>
>>Simulations would run too long at the board level with all the extra model
>>detail for most needs and provide reams of data that would never be used
>>
>>
>in
>
>
>>most instances.
>>
>>Lack of a standard data exchange format. How many versions of SPICE, SPICE
>>models and SPICE simulators are there? Who has even addressed power bus
>>modeling in most of SPICE?
>>
>>Best Regards,
>>
>>
>>Roy
>>
>>
>>
>>
>>-----Original Message-----
>>From: owner-ibis@eda.org [mailto:owner-ibis@eda.org]On Behalf Of Todd
>>Westerhoff (twesterh)
>>Sent: Tuesday, January 04, 2005 10:18 PM
>>To: ibis@eda.org; 'ibis-users'
>>Subject: RE: [IBIS] RE: BIRD95: Power Integrity Analysis Using IBIS
>>
>>
>>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
>>
>>
>
>
>

-----------------------------------------------------------------
|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 17:04:26 2005