[SI-LIST] Re: PDS analysis?
- From: steve weir <weirsi@xxxxxxxxxx>
- To: Chris Cheng <Chris.Cheng@xxxxxxxx>
- Date: Sun, 30 Mar 2008 23:17:05 -0700
Chris Cheng wrote:
> Steve,
> Let me see if I can word it in another way.
> There is partial inductance of the I/O power and partial inductance of
> the I/O ground paths on a package (steal from Al Ruehli's PEEC). They
> are both quantitative and qualitatively worst than the core power and
> ground (because there is less of C4 bumps for I/O power/ground and
> they have to escape through highly perforated planes).
Agreed.
> However, current flow between the I/O signal and its corresponding I/O
> ground when the signal goes from high to low and between I/O power and
> signal lead when it goes from low to high. NOT from I/O power to I/O
> ground (unless you have a lousy driver with large crowbar current).
Agreed.
> It is the tight coupling between the signal traces and its
> power/ground return path that will sustain your GHz signal.
No, we have two separate phenomena: The signal launch and the signal
propagation. At the signal launch ( driver ) the signal can only be
sustained when the driver power does not collapse. For the signal to
get anywhere, the signal propagation path needs to be contiguous. A
discontinuity through a junky power system will badly impair
propagation. But even the most perfect propagation path cannot fix a
starved driver.
> The overall loop inductance between the signal and its ground return,
> when connected through a driver that is driving low, determines
> whether you can sustain your I/O to go from high to low. The reverse
> for I/O power from low to high. You can't use decoupling caps to
> "decouple" your way out of this outside the package because you can't
> decouple between the signal and its reference plane !
The inductance determines whether we can initiate the edge, not whether
we can sustain it.
> Power is delivered through the I/O signal leads between I/O power for
> low to high and I/O signal leads between I/O ground for high to low
> transition.NOT between I/O power and ground (again assuming you don't
> have large crowbar current).
No this is only partially true.
The wave propagates away through whatever the transmission path is. We
can arrange the transmission path to be virtually entirely referenced to
either power rail or something else entirely. For the driver to be able
to launch a wavefront, it must be able to impress or remove charge at
the launch. If we switch from high to low and are VCC referenced, then
local capacitance connects the low side of the driver to the return side
of the launch. If we switch from low to high and are VSS referenced,
local capacitance connects the high side of the driver to the return
side of the launch. If we reference to something else, we have to
couple both VSS and VCC to whatever that something else is.
As long as the driver has a sustained energy source / sink available it
can maintain the switched level. The wiring that supplies that energy
can be made almost entirely independent of the signal propagation path.
An example is the MOLEX Z axis powering scheme.
> I think I misunderstood your previous mail saying you have observed
> 600MHz resonance between I/O power and ground at a package. The above
> clearly say that seems highly unlikely. And indeed you have clarify
> that it is a phenomenon at a PCB and not in a package.
The resonance was due to energy moving back and forth between the PCB
and the die. Both the IC package and the PCB were involved.
>
> >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.
> If you decide to run your highspeed DDR2/3 or FSB across disconnected
> power reference planes, of course it will excit the planes to
> resonate, probably over 100MHz. But that is Chris rule b violation !
Agreed! Chris's Rule B is an excellent rule. There will however be
times when violating it makes economic and engineering sense. The price
paid will be dealing with the impedance profile of the PDN, and the
impairment of the signals that pass energy through it.
> Of course a X2Y strategically connecting the two power planes near the
> signals cross the planes provide the low impedance path for the return
> to flow and magically solve your problem.
There are cases where good enough bypass whether that is achieved
through the type, quantity and strategy for the caps, and/or the type of
plane cavity that we can fix problems that might never have occurred
with better physical planning. There are cases where we can bend the
rules and get adequate results at lower cost. There are also cases
where no amount of Band-Aids are going to fix it.
I leave the illusion of magic to the floor shows in Lost Wages.
> But two wrong don't make one right. Don't run your bus across
> disconnected reference in the first place !
We have never disagreed on the value of maintaining a contiguous
transmission path.
> I have yet to see a highspeed bus app note allowing signal trace to
> cross disconnected reference planes.
> I do welcome your challenge to my rules and through out the years they
> do make me constantly re-evaluate their usefulness. And yet, at the
> end of the day, common sense rules and what I said is just common sense.
Common sense is an important place to start.
Best Regards,
Steve.
>
> ------------------------------------------------------------------------
> *From:* steve weir [mailto:weirsi@xxxxxxxxxx]
> *Sent:* Sun 3/30/2008 1:34 PM
> *To:* Chris Cheng
> *Cc:* Bowden, Ivor; Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
> *Subject:* Re: [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 <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
>
--
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
Other related posts:
