RE: [IBIS] BIRD95.3: Power Integrity Analysis using IBIS

Mike,

Thanks for your response.  So I have two questions:

1)  Are receiver switching currents important enough for SSO and PDN
simulations to address them in this BIRD?

2)  What do you suggest we should do when you say: "It's just a shame
that we are still going down that path and not prescribing flexible
circuit models" if not AMS?

Thanks,

Arpad
---------------------------------------------------------------------

-----Original Message-----
From: Mike LaBonte [mailto:milabont@cisco.com] 
Sent: Wednesday, March 30, 2005 9:34 AM
To: Muranyi, Arpad; 'ibis'
Subject: RE: [IBIS] BIRD95.3: Power Integrity Analysis using IBIS

Actually I was not even thinking of the dynamic current draw when a
receiver switches. That's a good point, but not only is [Composite
Current] totally tied to the presence of output waveforms, IBIS does not
have any convention for triggering the start of any kind of waveform in
response to an input event.

My thought was simply that other buffers in the package and even
elsewhere on the PCB can swing the power voltage that supplies an input
buffer; SSO reaches receivers. Indeed, the simulator may even choose to
model the power source with ripple! The receivers will cause dynamic
current flow in response to any voltage change at the power terminal,
even if the voltage change comes from elsewhere on the PDS.

About Arpad's "sinking feeling" question, I have been involved with the
macromodel approach since 1994. At Cadence I saw how versatile the set
of primitives defined by Kumar is, able to handle all post-2.1 IBIS
additions, complex receivers, pattern equalization, etc., just by
translating IBIS syntax to a simple macromodel template. Most IBIS
simulators already have everything or almost everything needed to do it,
and you get a lot of bang for the buck. As someone with a software
background I would love to play with AMS languages, but having been
successful with the macromodel approach all along I see no need. Also,
as far as I know AMS involves a lot of buck$ and would leave all but 2
simulator companies with a big disadvantage.
Sorry, Arpad :)

Mike

-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of
Muranyi, Arpad
Sent: Wednesday, March 30, 2005 11:46 AM
To: ibis
Subject: RE: [IBIS] BIRD95.3: Power Integrity Analysis using IBIS

Hello,

I think Mike raises a good point.  This comment actually reminded me to
something else that I have seen in the past.  When the incoming signal
causes the input receiver to switch, there will be some current flowing,
similar to the pre-driver current we have seen in the Sigrity
presentation in the last Summit.

This BIRD's I-t tables are all supposed to be time correlated with the
V-t curves of drivers.  There is no provision in this BIRD for inputs.
Are we ignoring something that may rotationally be an important effect
for power delivery noise simulations?

If we decided to address this, what should the I-t curves be time
correlated with for receivers?  The only thing I can think of right now
is the threshold crossing.

Does anyone feel that we should make provisions for accounting for the
switching currents of receivers also?

Regarding the "sinking feeling" comments on the bottom, are you saying
that you are an *-AMS advocate vs. macro modeling?

Arpad
====================================================================

-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Mike
LaBonte
Sent: Wednesday, March 30, 2005 8:14 AM
To: 'ibis'
Subject: RE: [IBIS] BIRD95.3: Power Integrity Analysis using IBIS

I find this paragraph of BIRD95.3 worthy of discussion:

|               These keywords might not have any effect for the
Model_type
|               settings of Input, Input_diff, Terminator, Series, and
|               Series_switch.  These settings do not have a driver mode
of
|               operation.

The analysis that lead to it is given:

6) Z_VDDDQ subparams and placement under Model_type - Bob Ross/John
Angulo Added statement that the new keywords might not be used for
Input, Terminator,  Series, Series Switch, Input_diff model_type.  The
positioning of [Composite  Current] under the [Rising Waveform] and
[Falling Waveform] keywords already  constrain that it is used only
where the waveform tables are used.

This implies that the RLC+G circuit connecting the power and ground
rails inside the black box might not be present in an input model. I
don't see why. That predriver and bypass circuitry exists in inputs, and
will cause power and ground currents when the power-to-ground voltage
changes due to external influence, even in an input. Is the simulator
expected to selectively ignore the elements based on whether or not an
IO or 3-state buffer is enabled?

My opinion is that the IBIS specification should not use the word
"might" in any place that "might" cause 2 simulators to behave
differently. The elements should be absolutely present for almost any
model type if they are specified. The only exceptions would be the
Series types, which do not have power and ground connections; all BIRD95
keywords should be illegal for those.

My apologies if I am jumping in late on something that has already been
discussed. I saw nothing about this change on the reflector.

While I'm at it I just have to mention the sinking feeling I get when I
read of new IBIS keywords that predefine structural elements that are
simply R, L, C, and G. It's just a shame that we are still going down
that path and not prescribing flexible circuit models, especially
considering that simulators will probably just apply the keyword values
to a template in the tool's own flexible macromodel-type language.

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