Re: [SI-LIST] : Decoupling Capacitors and SSN

About this list Date view Thread view Subject view Author view

From: Vinu Arumugham ([email protected])
Date: Mon Aug 28 2000 - 09:53:05 PDT


Josip,

The SSO current will not be affected by the capacitive load that is 6" away. The
driver can sense the load only after the reflection comes back. The driver will
draw current for a longer interval because the reflection will be delayed by the
capacitive load. This extra charge requirement will have to be accounted for in the
power distribution calculations.

Vinu

Josip Popovic wrote:

> All,
>
> purpose of Larry's (attached) message was not to explain SSO however I
> have a quick comment related to the 3rd paragraph:
>
> wouldn't Zo od a transmission line loaded by a capacitor (Cd) change and
> be different then Zo of a line with a resistive load:
>
> Zo'=Zo/(SQRT(1+Cd/Co))
>
> where:
>
> Zo' is new characteristic impedance of the loaded transmission line,
> Cd is a capacitive load (per the transmission length).
> Co intristic capacitance (per length)
>
> I do not think that an ideal transmission line model (as is one that
> comes with HSPICE for example) would show this change in Zo.
>
> For example a generic Zo=50 ohm, 6" long microstrip line with 5 pF load
> would have Zo' app 39 ohm.
>
> So simulating SSO with output drivers driving an ideal transmission line
> with capacitive load would have driver output current:
>
> Io= Vdd/(Rs+Zo) where Rs is (static) driver output impedance
>
> that is different than
>
> Io'= Vdd/(Rs+Zo') as it should be.
>
> Comments?
>
> Josip
>
> [email protected] wrote:
> >
> > Brian - really good question! Yes, there is definitely noise
> > associated with IO circuits that is below the edge rate frequency, but
> > I would not call this part of the "SSN signal". For IO circuits, there
> > is an SSN problem and a power distribution problem. The two are
> > related but independent problems.
> >
> > For example, consider two different signaling technologies with
> > identical drivers and 3 inch transmission lines, but one has a
> > capacitive load at the far end (maybe 5 pF), and another has a 50 Ohm
> > resistor to ground.
> >
> > Let's define the SSN event as the things that happen at the driver
> > within 1 nSec of a 0.5 nSec rising edge coming out of the driver. The driver
> > has no idea what the load is. The SSN waveforms measured anywhere in
> > the vicinity of the driver will be identical for our two signaling
> > technologies. It will take at least 1 nSec for the signal to get to
> > the far end and come back to affect the driver.
> >
> > But the power distribution requirements will be completely different.
> > With 50 ohm drivers terminated with 50 ohm resistors to ground, each
> > driver may consume Vdd/100 = 3.3/100 = 33 mAmps forever after the
> > transition. The drivers connected to capacitive loads will consume 33
> > mAmps for about 2 nSec after the event and then consume no more power
> > until another clock cycle.
> >
> > The major point is that we have two problems: an SSN problem involving
> > the edge rate and a power distribution problem that has to do with the
> > average power consumed over a clock cycle. The power distribution
> > problem is well quantified by the target impedance. All you need to do
> > is find the average current consumed over the clock cycle and make sure
> > the power distribution system can handle it without too much voltage
> > drop. A flat target impedance is desirable up to the clock frequency,
> > 100 MHz in Martin's case.
> >
> > For both technologies, we need to deal with the SSN event. With edge
> > rates of 0.5 nSec, it will involve solutions between 100 MHz and 700
> > MHz, maybe a little more. To understand the SSN event, we have to
> > trace the currents on the signal transmission lines and the return
> > currents on the Vdd and Gnd planes. Current must travel in a complete
> > loop and may have to jump from a Vdd to Gnd node to complete the path.
> > This involves displacement current through some type of capacitance as
> > well as package inductance. Target impedance is a good concept for the
> > power distribution problem, but I'm afraid it is too simplistic to be
> > of much use in the SSN problem. We may attempt to define a noise
> > spectrum for the SSN problem and measure an impedance of the power
> > planes at those frequencies, but that does not really address the
> > completion of the current paths of all the SSN currents.
> >
> > regards,
> > Larry Smith
> > Sun Microsystems
> >
> > > From: "Moran, Brian P" <[email protected]>
> > > To: "'Larry Smith'" <[email protected]>, [email protected]
> > > Subject: RE: [SI-LIST] : Decoupling Capacitors and SSN
> > > Date: Thu, 17 Aug 2000 09:10:55 -0700
> > > MIME-Version: 1.0
> > >
> > > Larry,
> > >
> > > Your response to the Martin regarding making a distinction between power
> > > delivery and SSN was very well received. I agree with the basic premise, but
> > > I do have a question. I agree that layer stack optimized power/ground
> > > coupling provides a good means of high frequency decoupling, which allows
> > > you to filter the upper portions of the SSN noise signal, the overall
> > > bandwidth of which, as you say is a function of rise time.
> > >
> > > However, due to the relatively low capacitance value of this power/ground
> > > coupling, it would seem that there would still be a large component of the
> > > SSN signal below the effective range of this technique, which would still
> > > have to be handled with on-chip or on-board decoupling. So you can not
> > > really say that SSN is not a board level decoupling issue. Difficult as it
> > > is to deal with.
> > >
> > > It would seem that you may need better than the 333 mohms required for power
> > > delivery, over some portion of the spectrum, but perhaps less than the 20
> > > mohms required to address peak SSN. In a perfect world your on chip
> > > decoupling would take you down in frequiency until the rest of the SSN
> > > component was suppressed. I'm not sure this is always the case. Therefore I
> > > think some amount of SSN must be considered at the board level.
> > >
> > > One of the problems I have is figuring out the overall frequency spectrum of
> > > the SSN based on clock rate and rise time, and translating that into a power
> > > delivery impedance requirement vs frequency plot. A good rule of thumb for
> > > the amplitude vs frequency spectrum of the SSN signal, based on clock rate
> > > and edge rate would be a good start. Forgive me if I mis-stated any of your
> > > position on this. There was alot of mail going back and forth.
> > >
> > >
> > > Brian Moran
> > > Signal Integrity Engineering
> > > Intel Corp.
> > > Folsom, CA
> > >
> > > -----Original Message-----
> > > From: Larry Smith [mailto:[email protected]]
> > > Sent: Tuesday, August 15, 2000 4:57 PM
> > > To: [email protected]
> > > Subject: RE: [SI-LIST] : Decoupling capacitors (again!)
> > >
> > >
> > > Martin has a good question on decoupling and Pat has contributed some
> > > good comments on the subject. The most common complaint that I hear
> > > about this decoupling methodology is that it requires the use of too
> > > many capacitors! Please allow me to make a few comments that may
> > > help.
> > >
> > > First of all, we need to carefully distinguish between a power
> > > distribution problem and an SSN (simultaneous switch noise) problem.
> > > Anytime there are IO or transmission lines involved, it is probably an
> > > SSN problem. The two problems are closely related, but if we don't
> > > make a careful distinction, we will greatly over estimate the number of
> > > capacitors required.
> > >
> > > To determine the number of discrete decoupling capacitors required in a
> > > system, we first calculate the target impedance. For Martin's problem
> > > we can get a good estimate from the clock frequency and capacitance
> > > load. The system runs at 100 MHz and there is 1.5 nF of capacitance
> > > that may be charged up to 3.3V or discharged to ground every clock
> > > cycle. Q = CV, so we have 1.5nF*3.3V = 4.95 nCoulombs that may flow
> > > every clock cycle. I = dQ/dt, so we have 4.95 nCoul/10nSec = .495 amps
> > > average current. Most systems can tolerate a 5% supply, so the target
> > > impedance is Zt = Vdd*5%/I = 3.3*.05/.495 = 333 mOhms. (If there is
> > > more than just IO circuitry hanging on the 3.3V supply, the target
> > > impedance should be lower.)
> > >
> > > 333 mOhms is much higher than the 20 mOhm target impedance calculated
> > > below. The error has come because the power distribution problem was
> > > mixed up with an SSN problem. SSN is concerned with edge rates, but
> > > the power distribution target impedance is associated with average
> > > currents. It will be easy to maintain 333 mOhm impedance out to more
> > > than 100 MHz with about a dozen carefully chosen capacitors. This is
> > > all that is needed for this power distribution problem and is
> > > consistent with the intuition that experienced engineers have regarding
> > > the number of capacitors required. The decoupling capacitor
> > > methodology gives a good way to optimize the chosen capacitors and
> > > guarantee there are no high impedance frequencies up to several hundred
> > > MHz. This becomes necessary on larger systems where we really have to
> > > maintain 10 mOhms or less up to high frequencies.
> > >
> > > As Ray mentioned in a previous note, it is very difficult to maintain a
> > > low target impedance above 200 MHz using discrete capacitors. The 1 nH
> > > mounting inductance for a discrete capacitor contributes more than 1
> > > Ohm of impedance. You have to put 50 of them in parallel to get to 20
> > > mOhms at 200 MHz. If you want 20 mOhms at 1GHz, it takes 5x more than
> > > that! With low ESR capacitors, it is possible to target certain
> > > critical frequencies above 200 MHz using the resonance technique. But
> > > the number of discrete capacitors required to maintain a flat 20 mOhm
> > > impedance up to 1 GHz is prohibitively large, and really not necessary
> > > on any of the systems that I work on.
> > >
> > > The answer to the SSN problem is thin dielectric power planes. At 1
> > > GHz, 8nF gives an impedance of 20 mOhms (1/jwC). 36 square inches (6x6
> > > inches) of a pair of power planes separated by 4 mils of FR4 gives this
> > > capacitance. If our SSN problem is centered within this area, this
> > > capacitance will be available within a 1 nSec rise time. It really
> > > does not make sense to use discrete decoupling capacitors to deal with
> > > SSN noise associated with today's fast edge rates. Capacitance between
> > > PCB and package power planes and capacitance embedded on chip are the
> > > best defenses against SSN.
> > >
> > > One more comment, target impedance is really too simplistic of a
> > > concept to be useful for the SSN problem. To really deal with the SSN
> > > problem, you have to know which way the driver is switching (high or
> > > low) and whether the transmission line return current flows mostly on
> > > the Vdd plane or Ground plane in order to make SSN calculations (yes,
> > > it makes a big difference!). There is another paper on the same web
> > > site as the decoupling capacitor paper. Check out "Simultaneous Switch
> > > Noise and Power Plane Bounce for CMOS Technology" on:
> > >
> > > http://www.qsl.net/wb6tpu/si_documents/docs.html
> > >
> > > regards,
> > > Larry Smith
> > > Sun Microsystems
> > >
> > >
> > > > From: "Zabinski, Patrick J." <[email protected]>
> > > > To: [email protected]
> > > > Subject: RE: [SI-LIST] : Decoupling capacitors (again!)
> > > > Date: Tue, 15 Aug 2000 10:40:50 -0500
> > > > MIME-Version: 1.0
> > > >
> > > >
> > > > Martin,
> > > >
> > > > I can't offer much advice, but I can possibly offer some
> > > > comfort in that I've had the same problem. For one design
> > > > I was recently involved in, I tried to follow the same
> > > > approach/theory, and the end result was that I needed
> > > > 80 decoupling capacitors per ASIC (to maintain 10%
> > > > dV), and I had 32 ASICs per board (>2500 caps per board!).
> > > > After having others verify
> > > > my numbers/calculations, I took close look and realized
> > > > the caps would consume more board space than the ASICs.
> > > >
> > > > I could not justify, believe, or afford this, so I
> > > > ended up backing down and relying on my old rules of
> > > > thumb (BTW: I hate rules of thumb, but I sometimes
> > > > use them when I have no better way). The board works
> > > > fine with only 12 caps per ASIC.
> > > >
> > > > Looking back, I can see three possible reasons why the approach you
> > > > and I took is not quite complete:
> > > >
> > > > * component packaging effects are not taken to
> > > > account. Not definite on this, but I believe
> > > > a poor package would probably negate any capacitance
> > > > you might have on the board.
> > > > * the board's self-impedance. I believe Larry's
> > > > approach addresses this as effective increase
> > > > in inductance, but the ground/power plane itself
> > > > does offer a low-impedance capacitance. Regardless
> > > > if you have any discrete caps on or not, the planes
> > > > offer some inherent, built-in capacitance.
> > > > * most (all?) dI/dt effects are self-limiting.
> > > > For the calculations you used, they assumed
> > > > dV=0.0. However, if dV>0, then dI/dt will
> > > > be reduced all on its own. I don't have any
> > > > data or theories on how much, but dI/dt
> > > > is likely to be reduced from what you
> > > > predicted (also tied into/related to the
> > > > first issue about packaging).
> > > >
> > > > Sound reasonable? Comments?
> > > >
> > > > Anyway, I sympathize and hope you find a solution. If you
> > > > do, please share.
> > > >
> > > > Pat
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Martin J Thompson [mailto:[email protected]]
> > > > > Sent: Tuesday, August 15, 2000 9:49 AM
> > > > > To: <"[email protected]"
> > > > > Subject: [SI-LIST] : Decoupling capacitors (again!)
> > > > >
> > > > >
> > > > > Hi all, this is my first time posting here, although I've
> > > > > been lurking for a while.
> > > > >
> > > > > My problem is figuring out the decoupling requirements for
> > > > > this system:
> > > > > FPGA, DSP, 6 SDRAMS, 2 flash, DPRAM, clock frequency is 100MHz.
> > > > >
> > > > > According to my calculations, my I/O's need to drive a total
> > > > > of about 1.5nF of I/O and trace capacitance.
> > > > > To achieve the 0.5ns edges that the FPGA will drive (3.3V
> > > > > supply) it looks like I need dI=4amps. This is assuming that
> > > > > 50% (is this typical?) of the I/O's toggle each cycle. (dI=0.5Cdv/dt)
> > > > >
> > > > > To achieve a dV of < 0.1V this implies a target impedance of
> > > > > around 20mohm, flat up to 1GHz! (Z=dv/di)
> > > > >
> > > > > This then seems to need around 500-800 decouping caps spread
> > > > > around, which is an order of magnitude more than I've ever
> > > > > used in the past. This is the first time I have taken a
> > > > > 'design' approach to the problem, but the previous boards
> > > > > have worked, using various rules of thumb.
> > > > >
> > > > > Is this sort of number of caps to be expected in this sort of
> > > > > system, or can anyone see any sillies in my understanding (or
> > > > > even in the sums!)?
> > > > >
> > > > > Now, if I don't get right out to 1GHz, the edges will suffer,
> > > > > but that wouldn't necessarily matter if they stayed below
> > > > > 1-1.5ns. Or would this cause the supply to droop elsewhere?
> > > > >
> > > > > As you might gather from the analysis above I've read Larry
> > > > > Smith and co's paper on decoupling design, which states that
> > > > > a flat target impedance is indicated. If I can analyse my
> > > > > application enough, can I then shape the Ztarget vs frequency
> > > > > to make life easier?
> > > > >
> > > > > Many thanks for your time, any help greatly appreciated,
> > > > >
> > > > > Martin
> > > > >
> > > > >
> > > > >
> > > > > TRW Automotive Advanced Product Development,
> > > > > Stratford Road, Solihull, B90 4GW. UK
> > > > > Tel: +44 (0)121-627-3569
> > > > > mailto:[email protected]
> > > > >
> > > > >
> > > > >
> > > > > **** 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
> > > > ****
> > > >
> > >
> > >
> > > **** 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
> > > ****
> > >
> >
> > **** 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
> ****

**** 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
****


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Tue May 08 2001 - 14:29:21 PDT