From: Josip Popovic ([email protected])
Date: Tue Jun 13 2000 - 05:19:29 PDT
Speaking about VLSI circuits:
During some SSO (or SSN) and cross talk simulations I realized that
internal decoupling (Cdi) would actually increase probability of false
triggering input buffers (IOs from the same device). Overall rail noise
was lower but rails, since Cdi was added, would follow each other -
noise on gnd rail was distributed by Cdi to pwr rail and vice versa. I
see two difficulties with added Cdi:
1. Since rail noise is in phase input buffers are more susceptible to
false triggering due to dynamic thresholds (P and N transistors could
change their states in the same time: if input voltage is fixed and
high, P is closed (doesn't conduct) and N is open. If gnd rail due to
SSO goes high, pwr rail follows the gnd rail with a positive voltage
bump due to Cdi - the P can get open and N can get closed. Of course
there are different input buffer configurations.)
2. Oscillations on power rails due to Cdi and L_package_leads that form
a resonant circuit with very high Q (long setup times and high
voltages).
Any thoughts?
Josip
[email protected] wrote:
>
> there seems to be a lot of discussions about using pcb capacitance
> or spreading bypass caps value for flat response. i would like to
> offer some counter points to the discussions.
>
> for core noise decoupling
> in all of my analysis for core power decoupling, whether using wire
> bond or c4 packages, the package inductance (bond wire or c4 bump/
> distribution, core via and package pin) is so high that no external
> decoupling can help or contribute to the initial transient. you
> can connect an ideal source to the pin and it still won't help
> the initial transient voltage drop. it seems to me other than
> on die decoupling and on package decoupling capacitors, any
> attempt to use external decoupling caps for >500MHz core noise
> is not effective.
> if you buy into the above observation, the function of external
> caps are only used for resupply the depleted charges of the
> on die or package decoupling caps. a mere few hundred pf from
> the plane capacitance is not going to cut it. what you really
> need is the bulkiest and lowest esl/esr cap you can place and
> manufacture near your package. followed by even larger and
> bulky cap further away until the power supply wakes up. i
> have not seen any benefit from caps that is lower than 0.01uf
> in suppressing core noise at all. think about it in another way,
> if external decoupling can do the magic, why does sso happens ?
> hint, the package inductance gets in the way.
>
> for i/o noise decoupling
> i believe its is more important to have tight coupling between
> the signal traces and the power/ground return plane for its
> return current NOT tight coupling between the power and ground
> plane. remember, i/o current flow from power through the signal
> trace or from signal trace to ground return NOT between i/o power
> and ground plane.
> if you buy into the above, for a finite number of layer stack
> up in pcb, it makes more sense to sandwich the signals between
> the power/gnd plane than pairing up the power plane and leave
> the signals to dual strip layers.
>
> as for the 1/4 wavelength placement etc. what you need to
> realize is that by the time the noise goes through the package,
> it is no longer a high speed single point source but rather a
> lower speed drupe spread out across the package. 1/4 wavelength
> and distance is meaningless given the size of the package.
>
> chris
>
> **** To unsubscribe from si-list or si-list-digest: send e-mail to
> [email protected]. In the BODY of message put: UNSUBSCRIBE
> si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
> si-list archives are accessible at http://www.qsl.net/wb6tpu
> ****
**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected]. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****
This archive was generated by hypermail 2b29 : Wed Nov 22 2000 - 10:50:35 PST