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