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

Dear Muranyi,

I agree with you about the need to identify a solution for describing
the "gate modulation effect" by legacy buffer modeling techniques.
I think this solution will increase a lot the quality and accuracy of
IBIS model simulations, expecially in the design of high-speed
systems.

About this issue, we have done internally a lot of benchmarking activities
to evaluate the accuracy of IBIS SSO simulations vs SPICE ones, because
it is a very critical bottleneck to perform accurate IBIS signal
integrity analysis
for system-in-packages design.

To reduce the mismatching IBISvsSPICE, we have identified two mandatory
steps:

1) to estimate the capacitances of the IC power nodes and back-annotate
them to IBIS models. The capacitances considered are fullchip and include
the total self and mutual capacitances between buffers (Vddq, Gndq) and
core (Vdd, Gnd) power nodes, including also the equivalent capacitances
of ESD structures and parassitic diodes connected to power nodes.
This step permits to recover the correct behaviour of the power and ground
nodes, but it doesn't solve the error due the "gate modulation effect" lack
which impacts on the delay and ringing simulations accuracy.

2) to solve the "gate modulation effect" error. For this goal we have
implemented
the Vgs modulation description using the VHDL-AMS language, starting
from the
IBIS model template suggested by you. The results seem to be very
interesting.
Our approach has been based on extrapolating some tables which describe
the current through pullup and pulldown for different values of Vgs,
keeping the
Vds values fixed.
I think this approach might be implemented also by legacy buffer
modeling techniques,
but it has to be joined to a new IBIS simulation stategy in the EDA
tools available
on the market.
I think the [Series Composite Current] keyword in the BIRD95 also
presents this need.

Best regards,

                      Antonio Girardi

Muranyi, Arpad wrote:

>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 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
>
>

|------------------------------------------------------------------
|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 05:24:25 2005