Thanks Vinu - I think I see what you're getting at, but let me try to
clarify my original point:
If we're talking about the parasitics within the scope of the buffer model
itself, then I agree entirely. In some of the designs I've seen, the area
between the buffers was used to create bypass capacitance shared arcoss the
buffers in an given area. That was the bypass case I was speaking about -
when I advocated omitting the effects of the bypass capacitance and
associated parasitics during model creation.
As you've pointed out, the tricky part is understanding what is considered
part of the buffer model and what is not. I'm suggesting that the IBIS
model cover whatever parasitics and bypass capacitances are included in the
extracted SPICE model.
I think the model charter remains the same - an SSN-enabled IBIS buffer
model should produce the same voltages and currents at all of its terminal
pins as its SPICE counterpart. If you can take the SPICE buffer out of a
complex circuit that models both interconnect and PDS, drop in its IBIS
counterpart and predict the same SSN, I think that constitutes success.
Having the IBIS model match the SPICE behavior gives us something we can
test and verify. If we allow the IBIS model to include anything the SPICE
model doesn't, we have no basis of reference for comparison, and, quite
frankly, I don't think we'll come up with something anyone will really
trust.
I'm suggesting that modeling of bypass capacitance/parasitics external to
the buffer and modeling of core currents - be left out of the IBIS spec.
This can be addressed by combining the IBIS buffer with general purpose
structural elements in the simulator netlist. I believe you're correct in
saying that die level parasitics and bypass capacitance are not readily
available to the IBIS user. In actual practice, I don't see they're even
that readily available to the chip circuit designers ... which is my point.
The process of designing on-die bypass structutures is in a state of flux,
and I don't see the infrastructure in place to express on-chip bypassing
accurately on an equivalent per-buffer basis. Thus, I suggest we get the
IBIS buffer to replicate the SPICE buffer's behavior, and let the
package/die PDS structure sort itself out at its own pace.
That means combining the IBIS buffer with its associated PDS parasitics
would require a simulator that can instantiate the unpackaged buffer and
combine it with general purpose elements. In practice, it means a simulator
with a SPICE-like syntax and modeling both interconnect and PDS directly in
the simulator netlist, as opposed to, using package info from the IBIS file
to model the package and die level interconnect/PDS structures. Personally,
I think by the time people get to running SSN analyses, pretty much
everything is being modeled directly in the simulator netlist. If we wanted
to have info in the IBIS file to model the package/die level PDS, I would
still recommend tackling that as a separate issue.
Thanks,
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 Vinu
Arumugham
Sent: Wednesday, January 05, 2005 3:29 PM
To: twesterh@cisco.com
Cc: ibis@eda.org; 'ibis-users'
Subject: 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
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 written 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 14:11:48 2005
This archive was generated by hypermail 2.1.8 : Wed Jan 05 2005 - 14:15:35 PST