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

Hi Mike and Arpad,

Thank you all for excellent comments on BIRD95.  At one point we talked
about the applicable of BIRD95 to different buffer types.  My personal
feeling was that BIRD95 could be applied to input buffer, but it requires
some modifications in IBIS input buffer itself.  Here is a few thoughts I
have:

1. The parasitic Z_VDDQ could be easily used at input buffer.  No
modification is needed.
2.  IvsT table is a little bit difficult.  At this time, the IBIS model has
no VvsT table for the input buffer, so it is difficult to specify the timing
and other conditions under which IvsT is extracted.  Arpad recommend to use
the threshold crossing time as a reference for IvsT.  Fundamentally there
are some problems associate with it in the real EDA tool implementation due
to reason that tool needs to apply IvsT info before it detects the crossing
point.  For the simple input buffer with internal termination resistor to
both VDDQ and GND.  The IvsT current is a strong function of the input
waveform edge rate, so we need to specify the input waveform first which may
lead to adding VstT table or similar info for the input buffer.

My suggestion is that we can go with BIRD95 for output only and start a
different BIRD for input buffer.  If we add more stuffs to BIRD95, it will
take much long time to get it approved.

Comments to Aprad's two questions and Mike's replies:
1.  For some chips, we saw SSI (Simultaneous Swathing Input) noise and
timing impact are close to SSO, so it is important.
2.  In BIRD95, we mentioned that ultimate solution for Z_VDDQ is through
ICM.  The equivalent circuit elements are short-term solution since ICM is
not available at this time.

Thanks.

Zhiping

----- Original Message -----
From: "Mike LaBonte" <milabont@cisco.com>
To: "'Muranyi, Arpad'" <arpad.muranyi@intel.com>; "'ibis'" <ibis@eda.org>
Sent: Wednesday, March 30, 2005 10:21 AM
Subject: RE: [IBIS] BIRD95.3: Power Integrity Analysis using IBIS


> Arpad wrote:
>
> 1)  Are receiver switching currents important enough for SSO and PDN
> simulations to address them in this BIRD?
> Mike>>> I honestly don't know enough about receiver currents to say.
>
> 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?
> Mike>>> Replace the [R Equiv] etc. with something like [Circuit Call],
> except allow it to call an [Internal Circuit] as an alternative to calling
> an [External Circuit]. This would allow embedding simple passive circuits
in
> the IBIS file, maybe limiting the language to SPICE, or maybe not.
>
> Mike
>
> ---------------------------------------------------------------------
>
> -----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
>
> ---------------------------------------------------------------------
> -----------------------------------------------------------------
> |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