[SI-LIST] Re: PDS analysis?

Chris,

A while back we saw this in spades with a certain FPGA vendor who
stonewalled its customers when their products failed.


> [Original Message]
> From: Chris Cheng <Chris.Cheng@xxxxxxxx>
> To: <leeritchey@xxxxxxxxxxxxx>; Steve Weir <weirsi@xxxxxxxxxx>
> Cc: Ivor Bowden <ibowden@xxxxxxxxxxxxxxxxx>; Gil Simsic [IEEE]
<gilsimsic@xxxxxxxx>; <si-list@xxxxxxxxxxxxx>
> Date: 3/30/2008 11:12:39 PM
> Subject: RE: [SI-LIST] Re: PDS analysis?
>
> The problem is not whether you can have a crappy designed package that
can have hundreds of MHz of noise. If it is large enough on die, you will
have fractions of the noise spilling out. 
> Sure, you can put your plane capacitance or exotic caps to make the
external power flat like a straight line without any ripple. But does it do
a single thing to damp down your core power noise at your die ? You can put
a million caps or planes outside your package and make your external pin
quiet. But it will not have any measureable effect on your on die noise. 
> It is the same as seeing a leaking diaper and just wipe the outside clean
or put an extra one to cover it, I guarantee it will not have any effect
for the end user. 
>
> ________________________________
>
> From: Lee Ritchey [mailto:leeritchey@xxxxxxxxxxxxx]
> Sent: Sun 3/30/2008 11:21 AM
> To: Steve Weir; Chris Cheng
> Cc: Ivor Bowden; Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
> Subject: RE: [SI-LIST] Re: PDS analysis?
>
>
>
> I've got some ICs with core frequency transients well into the hundreds of
> MHz.  Looks like the on die and on package capacitance was not done well.
> Fixed with a little more plane capacitance.
>
>
> > [Original Message]
> > From: steve weir <weirsi@xxxxxxxxxx>
> > To: Chris Cheng <Chris.Cheng@xxxxxxxx>
> > Cc: Bowden, Ivor <ibowden@xxxxxxxxxxxxxxxxx>; Gil Simsic [IEEE]
> <gilsimsic@xxxxxxxx>; <si-list@xxxxxxxxxxxxx>
> > Date: 3/29/2008 10:23:32 PM
> > Subject: [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.
> > > 
> > >
> > >
------------------------------------------------------------------------
> > > *From:* si-list-bounce@xxxxxxxxxxxxx on behalf of Bowden, Ivor
> > > *Sent:* Sat 3/29/2008 1:31 PM
> > > *To:* steve weir
> > > *Cc:* Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
> > > *Subject:* [SI-LIST] Re: PDS analysis?
> > >
> > > Hi Steve,
> > >
> > >
> > > Thank you for your reply! This is the type of answer I was looking
> > > for. I'm not "going anywhere with this", not advocating any particular
> > > position, just looking for information about ramifications of typical
> > > design practices.
> > >
> > >
> > >
> > > I know that PDS analysis tools are not as ubiquitous as simulation /
> > > crosstalk tools, and many companies, especially smaller ones, tend to
> > > skip this step, instead relying on experience with past designs. I was
> > > wondering how frequently these designs have problems due to
> > > sub-optimal PDS, the nature of the problems, and the resolutions. For
> > > instance, have you seen many cases where going to smaller value bypass
> > > caps at specific points improved a broken circuit?
> > >
> > >
> > >
> > > I apologize for not doing more research before posting the question.
> > > I'm sure I can find a variety of examples with enough searching.
> > > Mainly I was looking for opinion, preferably backed by knowledge.
> > >
> > >
> > >
> > > As sort of an informal survey, it was interesting to note that the off
> > > list replies tended more towards "for typical boards PDS isn't needed
> > > if proper rules are followed", generally backed up with statistics of
> > > successful boards not PDS analyzed, while the on list replies tend to
> > > be more of the "always do PDS analysis" flavor.
> > >
> > >
> > >
> > > Again, not going anywhere with this. I agree that the safest design
> > > practice is to fully simulate the design, including PDS.
> > >
> > >
> > >
> > > Ivor
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: steve weir [mailto:weirsi@xxxxxxxxxx]
> > > Sent: Saturday, March 29, 2008 3:00 AM
> > > To: Bowden, Ivor
> > > Cc: Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
> > > Subject: Re: [SI-LIST] Re: PDS analysis?
> > >
> > >
> > >
> > > Ivor, you can find examples in papers by people like Larry, Istvan,
and
> > >
> > > books that are out there.  But, I am not sure where you are going with
> > >
> > > this.  Since terms like "well fed" are ambiguous, I don't know what
> > >
> > > example you are looking for or to what purpose.  My sense is that you
> > >
> > > have a belief that if one follows some ambiguous "industry practices"
> > >
> > > that the PDN will usually "work fine".  Undefined engineering leads to
> > >
> > > undefined results.  If you want predictable results then:  Define the
> > >
> > > requirements and engineer to them.
> > >
> > >
> > >
> > > We can characterize components to determine their actual power
delivery
> > >
> > > requirements.  Once known we can easily demonstrate failures that
result
> > >
> > > when we don't meet those requirements.  It is also easy to demonstrate
> > >
> > > what different PDN practices do to the impedance profile under any
> > >
> > > particular set of controlled circumstances we wish to create.
> > >
> > >
> > >
> > > If you want to see resonance effects for yourself then:  Design some
> > >
> > > board following one of the popular ad-hoc rules.  If for example you
> > >
> > > design a board with one 0402 capacitor every two square inches and the
> > >
> > > plane cavity is 4mil FR406 on layers 2/3, the bypass to cavity PRF
will
> > >
> > > land around 330MHz depending on how you do your vias. If the planes
are
> > >
> > > deeper in the board that frequency will just go down.  Then get
yourself
> > >
> > > a programmable clock generator and use it to drive some device like a
> > >
> > > PLD or FPGA with a bunch of outputs simultaneously in a simple 1-0-1-0
> > >
> > > sequence while you monitor the power supply planes with a decent
scope.
> > >
> > > Just step frequency until the bit rate / 2 excites the lowest parallel
> > >
> > > resonance in the power system.  After that experiment see if your
> > >
> > > feelings about what works fine are still the same.
> > >
> > >
> > >
> > > Steve
> > >
> > >
> > >
> > > Bowden, Ivor wrote:
> > >
> > > > Hi Gil,
> > >
> > > >
> > >
> > > >
> > >
> > > > Thanks for sharing.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > By "real world" I do not mean rules of thumb and shortcuts, I mean
> > > examples. I expect that most folks on this list, especially those for
> > > whom SI is primary activity, can demonstrate examples of operational
> > > failures due to bad board layout. I also know that a large number of
> > > designs never get PDS analysis, yet work fine. I'm interested in
> > > typical modern technology designs that are laid out in standard
> > > industry practice: contiguous ground planes, tandem heavy split power
> > > planes not used as return reference, plenty of properly located bypass
> > > caps, etc that have operational failures which could have been
> > > pre-determined by PDS analysis, and if so, how did that operational
> > > failure manifest? For example, it would be interesting to see a scope
> > > (or simulation) snap shot of the voltage measured directly across vias
> > > to contiguous well fed planes as a device current requirement
> > > approaches the planes resonant frequency. And I mean a real device,
> > > not a hypothetical entity tuned to instig
> > >  at
> > >
> > > >  e the problem.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > -Ivor
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > -----Original Message-----
> > >
> > > > From: Gil Simsic [IEEE] [mailto:gsimsic.ieee@xxxxxxxxxxxxx]
> > >
> > > > Sent: Friday, March 28, 2008 1:08 PM
> > >
> > > > To: Bowden, Ivor; si-list@xxxxxxxxxxxxx
> > >
> > > > Subject: Re: [SI-LIST] Re: PDS analysis?
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > Ivor
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > I am involved in design since 1993, and have numerous of successful
> > > designs
> > >
> > > >
> > >
> > > > under my belt. (I know - not very humble...)
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > In one way or another I worked and learned from SI leaders (aka -
> gurus)
> > >
> > > >
> > >
> > > > like Lee Ritchey, Istvan Novak, Eric Bogatin, Scott McMorrow and
> Howard
> > >
> > > >
> > >
> > > > Johnson (and others that due to a senior moment I did not mention
> here -
> > >
> > > >
> > >
> > > > sorry) I gratefully owe my knowledge to them.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > by the way - all I tried to do is to learn about "real world
picture".
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > My greatest lesson is - there are no short cuts and no rule of
> thumbs. I
> > >
> > > >
> > >
> > > > read daily emails on this list that prove this point over and over
> > > again.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > And than again I might misunderstand you...
> > >
> > > >
> > >
> > > > If the by 'real world' you refer to 'rules of thumbs' and 'short
> > > cuts', I
> > >
> > > >
> > >
> > > > will strongly recommend you to shy away from that 'real world'. I
> really
> > >
> > > >
> > >
> > > > think that any design as hypothetic or rhetorical as it is, needs
> > > analysis
> > >
> > > >
> > >
> > > > (the subject of your email is PDS analysis...).
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > Most of the SI phenomena are frequency depended.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > You said - * I'm more interested in answers like "you might see a
> > > waveform
> > >
> > > >
> > >
> > > > of xxx characteristics across the bypass capacitor". *
> > >
> > > >
> > >
> > > > My answer - "you might see a waveform of xxx characteristics across
> the
> > >
> > > >
> > >
> > > > bypass capacitor". ;-)
> > >
> > > >
> > >
> > > > How can one attempt giving you any 'ball-park' numbers for a
frequency
> > >
> > > >
> > >
> > > > dependent component with out knowing what the frequency parts are?
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > Good luck!
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > Gil
> > >
> > > >
> > >
> > > > ----- Original Message -----
> > >
> > > >
> > >
> > > > From: "Bowden, Ivor" <ibowden@xxxxxxxxxxxxxxxxx>
> > >
> > > >
> > >
> > > > To: <si-list@xxxxxxxxxxxxx>
> > >
> > > >
> > >
> > > > Sent: Friday, March 28, 2008 12:11 PM
> > >
> > > >
> > >
> > > > Subject: [SI-LIST] Re: PDS analysis?
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > 
> > >
> > > >> Hi,
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >
> > >
> > > > 
> > >
> > > >
> > >
> > > > 
> > >
> > > >> I'd like to thank everyone who replied so far, off and on the
list. I
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >> emphasize that this is a rhetorical question, it doesn't represent
> any
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >> specific product. I also emphasize that I'm interested more in the
> > > "real
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >> world observation" part. Instead of answers like "your power plane
> may
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >> have a resonance at xxx frequency", I'm more interested in answers
> like
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >> "you might see a waveform of xxx characteristics across the bypass
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >> capacitor". Also, this question is more about power distribution
than
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >> signal return path. All answers appreciated.
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >
> > >
> > > > 
> > >
> > > >
> > >
> > > > 
> > >
> > > >
> > >
> > > > 
> > >
> > > >> -Ivor
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >
> > >
> > > > 
> > >
> > > >
> > >
> > > > 
> > >
> > > >
> > >
> > > > 
> > >
> > > >> ________________________________
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > > >
> > >
> > > > 
> > >
> > > >> From: Bowden, Ivor
> > >
> > > >>   
> > >
> > > >
> > >
> > > > 
> > >
> > >
> > >
> >
> >
> > --
> > 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
> >
> > ------------------------------------------------------------------
> > 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:
> > http://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 <http://www.si-list.net/> 
> >
> > List archives are viewable at:    
> >               http://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:
http://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:     
                http://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: