[IBIS] Re: [IBIS-Users] BIRD 95.2 on-die decap

Hi John,

Thanks for your comments on BIRD95.2.   Please see my replies in your
e-mail.  Please let me know if you have any further questions.  Thanks.

Best regards,

Zhiping
----- Original Message -----
From: "Angulo, John" <john_angulo@mentorg.com>
To: <shuq@cisco.com>
Cc: <ibis@eda.org>; <ibis-users@eda.org>
Sent: Friday, March 11, 2005 11:07 AM
Subject: [IBIS-Users] BIRD 95.2 on-die decap


> Syed,
>
> At today's teleconference, I tried to clarify the suggestion I made for
> BIRD 95.2 yesterday.  The BIRD does not explicitly state that it is not
> intended for modeling the I/O power distribution network on-die.  The

On-die power distribution network is a very complicated issue.  Since we
have splited the original BIRD95 into 3 different BIRDs, the BIRD95.2 will
only cover the on-die power distribution network within the I/O cell
(whatever is included in I/O SPICE model) in a per-buffer level.  The the
rest of on-die power distribution will be covered by ICM model at per chip
level.

> actual intent is to document the power node currents and provide an
> impedance model for the power nodes of the transistor-level buffer
> model.  The goal, as Todd Westerhoff put it, is to substitute an IBIS
> behavioral description for the transistor-level buffer subcircuit inside
> whatever power distribution and packaging network you have available.

I didn't see any issue with BIRD95.2.  Our intention for BIRD95.2 is to
extract all useful info from SPICE level I/O model.  Ideally we should be
able to replace the Spice I/O model (drop-in solution) in more complicated
simulations.  The packaging or any other power distribution outside of I/O
Spice model are not intented to be included in BIRD95.2.

> However, the description for the C_p+b, ESR and ESL elements in the
> second diagram:
>
> |                 C_p+b    - Bypass + Parasitic Capacitance
> |                 ESR      - Equivalent Series Resistance for on-die
> Decap
> |                 ESL      - Equivalent Series Inductance for on-die
> Decap
>
> and the presence of these elements apart from the pre-driver circuit
> might make it hard for a lot of readers to appreciate that these
> elements are a behavioral model of the decoupling within the driver and
> pre-driver.

Please treat all the elements in the second diagram as illustration purpose
only.  We just want to show all major current elements within a I/O buffer.
As we mentioned in BIRD95.2, it is a black box.  We don't need to know any
details about the elements within the Spice model.

>
> Surely, for accurate SSO simulation, we will sometimes have to consider
> the additional decoupling in the on-die power distribution network.  The
> decoupling here is shared among multiple buffers, and of course it would
> not make sense to embed it into ZVDDQ elements, which are meant to be
> replicated at every instance of the buffer, i.e. "scaled" with the size
> of the SSO simulation.  You already made this point in slide 7 of your
> DesignCon presentation with Vinu and Zhiping.  My suggestion is to make
> this distinction between what we're doing in BIRD 95 and what we leave
> to other BIRD's or techniques more explicit in the text.

I agreed with what you said to a certain degree.   Ideally we should not mix
the decouplings in a per-butter level with per-chip level.  At this time,
there is no defined way to include the additional decouplings outside of the
I/O buffer in IBIS standard.  Some users may think it is easy to split these
additional decouplings into per-buffer level for their own using.  For this
reason, we may not want to explicitly opposite it in the BIRD proposal.  We
may be able to add more details on this topic in the cookbook.





>
> Thanks,
>
> John Angulo
> Software Development Engineer
> Hyperlynx Products
> Mentor Graphics Corp.
>
> |------------------------------------------------------------------
> |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 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