[SI-LIST] Re: PDS analysis?
- From: "Grasso, Charles" <Charles.Grasso@xxxxxxxxxxxx>
- To: "steve weir" <weirsi@xxxxxxxxxx>, "Chris Cheng" <Chris.Cheng@xxxxxxxx>
- Date: Sun, 30 Mar 2008 21:04:53 -0600
Spot on Steve!
I had PDN resonances that occurred (lucky me!) from 400-700MHz due to a subtle
problem in the PWB. Cannot agree more!
Chas
________________________________
From: si-list-bounce@xxxxxxxxxxxxx on behalf of steve weir
Sent: Sun 3/30/2008 2:34 PM
To: Chris Cheng
Cc: Bowden, Ivor; Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: PDS analysis?
Chris, filter poles are the result of L and C. I/O rails that have low
on die C will still have a much higher frequency L/C cut-off even though
the package L is much higher than for the core. This happens all the time.
Excuse me, would you kindly elaborate on these two sentences. They seem
incongruent to me:
And yet we have 1G+ FSB or 800MT/s DDR3 I/O so clearly there is a way to
deliver the I/O power to the die through the package. How ? Through the
tightly coupled path between the signals and their return path.
Chris aside from stored energy in the interconnect inductance that
drives back into both the Gnd and VCCIO rails when an output switches
from high to low, where is the current path to support the above statements?
1G+ FSB and other fast I/O busses work when the impedance of the PDN up
to and including the die is sufficiently low to support the switching
current demands. For any practical number of power connections to the
PCB this means substantial capacitance on the die side of that
interconnect inductance. When the IC / package designer fails to
include enough combined interconnect and capacitance, the IC cannot
perform as intended. When they only include enough that the PCB PDN has
to have a ridiculously low Z at the IC / PCB attach then we get forced
into higher cost PCB implementations to make the whole thing work.
The return path is a different issue. That is a matter of current
injection into the PDN. Here we largely agree: When either the IC
designer, and/or the PCB designer arrange the return path such that it
injects into the PDN, then that imposes an otherwise unnecessary burden
on the PDN in order to maintain basic I/O signal quality that a
contiguous return path does not suffer. Chris's Rule B is the same as
my quote.
The 600MHz resonance that I refer to is in a PCB design. The details
are scheduled for publication in the next few months. It could have
been cured by other means than a single X2Y cap. However, each of those
alternative means have their own problems. My points from this example
are: 1) Resonances do occur in PDNs well above 100MHz. 2) They can be
handily corrected at low cost. 3) There are readily measurable
performance benefits to doing so.
The plane resonance paper is the Ansoft demonstration of the effect of
stitching vias. The effect is real, and the remedy is real: use enough
vias.
I do admire your consistency and greatly respect your work. I simply
caution against the use of truisms. Understand fully how and why things
work and then it is usually pretty straightforward to engineer for what
we want. When we substitute guesses or rules of thumb for any: 1)
Knowledge of what performance we really need, 2) Characteristics of the
elements that we use, then we are crossing our fingers instead of
engineering. For example: maintaining a contiguous return path avoids
injecting noise between I/Os and the PDN. It's a good practice. If the
package doesn't have enough returns we will still end-up w/ SSO
problems. If on the other hand there are enough signal returns so that
SSO is under control, but maintaining an idealized return path on the
PCB requires extra layers, then it is worthwhile to determine whether
selectively impairing the return path can get rid of the extra layers
while still meeting the performance requirements. If so, then the
latter approach makes money.
Best Regards,
Steve.
Chris Cheng wrote:
> Steve,
> If we accepted the core current has a "reasonable number" at 100MHz,
> let's review how the core current vs. I/O current gets delivered in
> even the most well designed package.
> The core current gets delivered through a tight on die power grid that
> almost cover the entire die with C4 bum delivering current straight
> from the vertical package via, the lowest possible impedance path.
> The I/O power only gets delivered at the die peripheral edge (unless
> you have an IBM die that can spread all across the die) and has to run
> through the gauntlet of a highly perforated I/O signal redistribution
> area where signal escapes Swiss cheese the power/ground plane that
> have to deliver the power and return to the die. How could your I/O
> power and ground has lower loop inductance than those of the core both
> in terms of shear number (the entire die is almost cover with core
> power/ground bumps vs. only the peripheral bumps) and the loop
> inductance per port (straight via vs. highly Swiss cheese plane before
> even getting to vias) ?
> And yet we have 1G+ FSB or 800MT/s DDR3 I/O so clearly there is a way
> to deliver the I/O power to the die through the package. How ? Through
> the tightly coupled path between the signals and their return path.
> CHRIS RULE B. Any time there is a disturbance between the signal
> and the return path, there is performance degradation. Call it SSO,
> I/O power resonance or even return path induced crosstalk, they are
> examples of the same problem. When your return path is interrupted
> either by incorrect reference planes, insufficient return via or even
> poorly placed return via locations. When that happens, you have no
> choice but to throw in alternative paths such as thin core or fancy
> caps like X2Y. But I have said it many times, if you shoot yourself in
> the foot and scream for an expensive stretcher, I can't go on with
> that kind of discussion. The same problem can be solve with proper
> reference planes, via number and placement.
> The devil is in the details. And here is where we are stuck. Unless
> you are going to do dirty laundry of your client out in the public,
> how are we going to judge whether that 600MHz I/O resonance can not be
> solved by fixing the return paths rather than throwing in exotic caps
> ? The same goes to your 300MHz demonstrated problem ?
> Remember the plane resonance paper you mentioned a few months ago ?
> Even one author chimed in saying how real it is. Well, as we all now
> know that was just a matter of insufficient ground return vias (CHRIS
> RULE B violation) coupled with deliberate ill configured I/O. I am not
> saying you are wrong, just a different perspective.
> SI-list exist for over ten years. I have been saying the same thing
> for that ten years. And in between I have delivered reasonable amount
> of systems. Call me stubborn but I do practice what I preach. You
> don't have to agree with me, but at least appreciate my consistency ;-D.
> Regards,
> Chris
>
> ------------------------------------------------------------------------
> *From:* steve weir [mailto:weirsi@xxxxxxxxxx]
> *Sent:* Sat 3/29/2008 10:23 PM
> *To:* Chris Cheng
> *Cc:* Bowden, Ivor; Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
> *Subject:* Re: [SI-LIST] Re: PDS analysis?
>
> Chris, I appreciate your experience w/ changing out caps. Sprinkling
> caps of some arbitrary values to cure EMI ills is a bit akin to hunting
> rabbits with a revolver on a dark moonless night in the desert.
>
> 100MHz as a high cut-off for IC core currents is often a reasonable
> number due to limitations of both planes and IC packages. It is not
> however a reasonable number for many I/O rails. Nor does it account for
> the evils of packaged ICs that include significant problematic
> resonances. I've got examples that occur way above 100MHz. We just
> worked one recently where the resonance was about 600MHz. We handily
> corrected it with a single X2Y capacitor.
>
> The IC spec deficiencies are well known evils. Getting decent specs is
> the starting point for a competent design.
>
> For the two rules, personally I like coefficients for any problem. Over
> design costs too much money. Under design invites disasters. Ask
> Microsoft about their ever ballooning liabilities w/ the Xbox 360. I
> haven't seen a single problem with that fiasco yet that doesn't trace
> back to engineering deficiencies.
>
> The idea of using bypass caps to cover to 100MHz only is a demonstrably
> dubious truism. There are a number of chips out there that I can
> demonstrate misbehave when the bypass network doesn't deal with
> frequencies at 300MHz or higher. So, this is one time that I have to
> disagree with your advice.
>
> We do agree on the value and wisdom of managing the I/O return path.
> "Ask not what your PDN can do for signal returns. Ask what your
> physical design can do to avoid injecting unnecessary noise into the PDN."
>
> A parting comment on using a ton of 100nF caps. It used to be that this
> could work rather well when the overall density of the capacitors pushed
> the PRF between the bypass network and the planes out beyond the spectra
> of both the bit and edge rates. Nowadays that is just a very expensive
> if not just impossible approach.
>
> Best Regards,
>
>
> Steve.
>
> Chris Cheng wrote:
> > My first disclaimer will be :
> > YMMV
> > my second will be :
> > I still don't have the balls to do single value highspeed ceramic caps
> > but I do think .1u is a good starting point to go up to 1u and down to
> > .01u or even 1nf if you have a well designed flip chip package. For a
> > el-cheapo wire bond package .1u might even be good enough as "external
> > highspeed cap" to begin with.
> >
> > That said, I have at least two experiences that make me have second
> > thoughts :
> > 1) In one of my large product platforms (big server type machine),
> > during the first proto stage on the first EMI scan, my board design
> > guy accidentally generated the wrong BOM and stuff all the highspeed
> > caps that were supposed to be 1u,0.1uf and 0.01uf spread to a single
> > value 0.1uf. We actually send it through the EMI scan and it actually
> > pass FCC scan with good margin. And the system ran through all PVT
> > margin tests. Is it our luck or good enough to begin with ? I'll let
> > you speculate.
> > 2) In the workstation/server company we came from, on an occasion
> > after we had a big screaming session with the EMI engineer on our
> > designs, we secretly rework out all the 10pf,100pf and 100pf caps that
> > she sprinkled on our board with 1u caps and send it to her to scan.
> > And as expected it passed FCC with good margin. We lost all our
> > respect of her and probably EMI engineers in general after that.
> >
> > Typical IC spec calls out the peak current demand. A more
> > sophisticated one calls out the peak di/dt. A even more sophisticated
> > one calls out the voltage tolerance between different frequency bands.
> > No where does it tell you how it can ramp from zero current to peak
> > during normal operation.
> > No where can it tell you if your system architecture can actually pin
> > the I/O buses or subsystem to maximum activities during normal operation
> > No where does it tell you your super multi-processors backplane can
> > actually maintain peak bandwidth on all cluster ports when the per
> > node bandwidth is choked by say your on board memory bus or real I/O
> > sustain bandwidth on board
> > No where does it tell you in a typical multi-giga bit SERDES, even if
> > the I/O is idle, the idle pattern actually draws zero power vs. peak
> > activity
> > No where does it tell you the bandwidth of your memory refresh cycle
> > and access activity factor variations
> >
> > Once again, I won't say with only .1uf will work. But with sensible up
> > and down values around it, it is a good starting point.
> >
> > And remember the two Chris Cheng rules of SI
> > a) Manage your core power distribution with stages from die to package
> > to PCB with highspeed at die/package and medium/low speed on PCB
> > b) Manage your I/O return current properly
> >
> > If you buy the above, PCB decoupling is a matter of 100MHz or below
> > PROVIDED you manage your return current properly.
> >
> > Another important point is also related to rule a) is if you believe
> > your critical PCB distribution responsibility is around a few MHz to
> > 100MHz, can you afford to waste your limited space on your PCB to
> > populate those junk 10pf or 100pf other people love to sprinkle ? Back
> > in the days when boards are big and performance and financial
> > budget are loose, we chose to let whoever speculate whatever is needed
> > provided he/she sign the design off in a bureaucratic company. Can we
> > afford to do that anymore ? Not in a small company like mine and we
> > make a conscious decision to hire one type of engineer responsible for
> > both SI and EMI. And it worked out great.
> >
> > And if you have time/resources or stupid enough like me, why not try
> > experiment 1) or 2) :-D.
> >
> >
>
--
Steve Weir
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
California office
(408) 884-3985 Business
(707) 780-1951 Fax
Main office
(401) 284-1827 Business
(401) 284-1840 Fax
Oregon office
(503) 430-1065 Business
(503) 430-1285 Fax
http://www.teraspeed.com
This e-mail contains proprietary and confidential intellectual property of
Teraspeed Consulting Group LLC
------------------------------------------------------------------------------------------------------
Teraspeed(R) is the registered service mark of Teraspeed Consulting Group LLC
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
