[SI-LIST] Re: DDRAM BUS Testing

  • From: "Jim Antonellis" <janton@xxxxxxxxxxxx>
  • To: "'steve weir'" <weirsi@xxxxxxxxxx>, <erdinih@xxxxxxxxx>
  • Date: Sun, 6 Aug 2006 22:52:18 -0400

Ishan, Steve,

I too agree that blanket statements without analysis are to be viewed
with suspect. I hope I did not generalize in describing my tests a couple
years back. What I will say, at the risk of generalizing (sorry, I couldn't
resist!), is that testing showed me that we were quite possibly over
specing the decoupling caps and for certain we were not taking into 
consideration die and package level decoupling. Today, in our COT flow,
we have a better understanding of the die and pkg decoupling components
and the role they play in a complete hierarchical PDN, from DC to .....

Regards,
Jim


-
Jim Antonellis   janton@xxxxxxxxxxxx
Broadcom Corp    www.broadcom.com
Office: 978.689.1669 
Cell: 978.618.4745

This message and any attachments are Confidential and may be Legally
Privileged. It is intended solely for the addressee. If you are not 
the intended recipient, please delete this message from your system 
and notify us immediately. Any dis-closure, copying, distribution or 
action taken or omitted to be taken by an unintended recipient in 
reliance on this message is prohibited and may be unlawful.
 
 
-----Original Message-----
From: steve weir [mailto:weirsi@xxxxxxxxxx] 
Sent: Saturday, August 05, 2006 9:56 AM
To: erdinih@xxxxxxxxx; janton@xxxxxxxxxxxx
Cc: hmurray@xxxxxxxxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: Re: [SI-LIST] Re: DDRAM BUS Testing

Ishan, I agree that blanket rules that are not based on analysis are almost
totally pointless.

If we are attaching capacitors peripherally around a BGA, then the cavity
height, the pattern of the BGA Vdd/Vss array, and how close we put the caps
is going to determine the point of diminishing returns for the caps.  Larry
reiterated the point that once the attached inductance of the capacitor
array matches the spreading inductance of the planes connecting them to the
IC Vdd/Vss pins, adding more caps affords rapidly diminishing returns.

If we go to caps under the BGA it depends on how we connect them up.  If we
are going through a thick PCB, attaching a cap that has around 500-600pH
inductance 1:1 to a via pairs with 2400pH inductance each is not very
efficient.  When there is a plane cavity close to the caps, then most of the
Z axis inductance of the Vdd/Vss vias is shared by the caps and we can get
the same performance with far fewer caps than if the cavity is far from the
caps.

Let's consider for a second some popular FPGAs.  The core supply of a Virtex
4 has about five dozen Vdd pins.  It also has substantial die capacitance
and for the bigger packages caps under the lid.  We don't need a whole lot
of caps to support the core.  What about the Vddios?  Each Vdd/Vss pair
exhibits on the order of 20pH / mil in the Z axis.  By the time we get to a
plane in the board we are looking at anywhere from 1nH to 3nH or more
depending on where the Vddio cavity is located in the stack-up.  For the
case of planes high in the stack-up, 1nH means that we 1 cap per Vddio pin
is not very far off ( assume 600-700pH attached L to the plane, and
reflected plane spreading L ).  If however, we move the cavity deep into the
stack-up, that number falls off, and we would not see much benefit beyond 1
cap for every 3 Vddio pins for purposes of die power delivery.  Signal
return path is an entirely different matter.

Do we need planes at the top for I/O with one cap per Vdd?  Well, if we have
8 Vdd/Vss pairs at 1nH each, 125pH composite and 8 caps at say 640pH for
80pH total, we've got just over 200pH to the die.  In the parts without caps
under the lid, the larger I/O groups each have about 2nF capacitance.  200pH
/ 2nF is about 300mOhms impedance and peaks near 250MHz right on top of DDR2
533 signaling rates. If all 64 drivers in that bank are being used as
outputs, the reflected impedance without peaking is about 20Ohms per driver.
This should be telling us that we really do want to put as many caps as we
can stand and attach to planes as high up in the stack up as we can stand.
It probably also tells us that for those packages driving all outputs in one
bank at the same time isn't a good idea at high signaling rates.  If we look
at the larger packages, Xilinx includes IDC caps under the lid.  This drops
the cut-off frequency and the impedance.  In those parts, we have more lee
way.

Many if not most IC datasheet PDS recommendations are woefully lacking any
basis in analysis.  Those vendors leave it up to users to undertake that
engineering often without access to critical information.  While you may be
experiencing good luck with more liberal networks than your vendors
recommend, sometimes just the opposite is true:  the vendors recommendations
are inadequate or even counter productive.  This sorry state is not
universally true.  There are chip vendors out there who take power delivery
seriously and have carefully engineered same. People designing bleeding edge
parts squeeze every bit they can out of the PDS.  Their recommendations
should be taken very seriously.

Regards,


Steve.


At 05:03 AM 8/5/2006, Ihsan Erdin wrote:
>Jim,
>I share your opinion about the local decoupling caps to a large extent.
>Still, I shied away from casting a blanket statement about them due to 
>some unorthodox PDS designs. The local caps were really a big issue in 
>eighties and earlier where PDS were constructed from only power and ground
traces.
>Despite the wide-spread use of planes today, the design practices 
>haven't changed much and overkill rule-of-thumbs like one cap per Vdd 
>still prevail thanks to fear-mongering device datasheets prepared with 
>little or no analysis. I usually use a fraction of the recommended caps 
>for CPUs, network processors, etc. and my schematic reviews have raised 
>the eyebrows of those chip experts on several occasions. What they miss 
>is how those few caps are placed in the layout. I have yet to observe a 
>single functional failure -including jitter spec violation- despite 
>disregarding the datasheet recommendations.
>Contrary to common belief, local decoupling capacitors are expensive 
>devices; not because of their prices per se but the real estate. They 
>should be placed in congested BGA areas closing routing channels and 
>eventually affecting layer count.
>Having said that, I'm not advocating any PDS design with a nonsense 
>recommendation like no local decoupling caps and such. Even with the 
>planes they're still an essential part of the PDS design. As I put it 
>in this thread earlier, for tight timing margins and high-frequency 
>jitter specs they're crucial. My point is rather than throwing them in 
>the design in bulk numbers, they should be used judiciously .
>
>Regards
>
>Ihsan
>
>On 8/4/06, Jim Antonellis <janton@xxxxxxxxxxxx> wrote:
> >
> >
> > Hi Hal,
> >
> > Agreeing with all of the previous points in regards to locale, i.e.
> > Vdd-core, Vdd-io on die, pkg and PCB, I would like to share a "war 
> > story"....
> >
> > At one point, in our lab, I measured a system (many layers, many 
> > decaps) plane and tracked the system performance (logical operation) 
> > and the plane noise (diff plane measurements at decap site) as I 
> > removed caps on a particular rail. The local noise (as measured diff 
> > at the decap) did increase with the removal of decaps but 
> > interestingly the system did not "fail" (functional errors, I did 
> > not track the jitter or timing) until almost all of the decaps were 
> > removed. We were extrememly over zealous with the decaps.
> >
> > In closing, I do not assert that the experiment was well controlled, 
> > but at a gross level it confirmed that at a local level the decaps 
> > were doing something. If I have the time I'll dig out the report (I 
> > did document the work) and can send it to interested parties 
> > off-line.
> >
> > Jim
> >
> > -
> > Jim Antonellis   janton@xxxxxxxxxxxx
> > Broadcom Corp    www.broadcom.com
> > Office: 978.689.1669
> > Cell: 978.618.4745
> >
> > This message and any attachments are Confidential and may be Legally 
> > Privileged. It is intended solely for the addressee. If you are not 
> > the intended recipient, please delete this message from your system 
> > and notify us immediately. Any dis-closure, copying, distribution or 
> > action taken or omitted to be taken by an unintended recipient in 
> > reliance on this message is prohibited and may be unlawful.
> >
> >
> > -----Original Message-----
> > From: si-list-bounce@xxxxxxxxxxxxx 
> > [mailto:si-list-bounce@xxxxxxxxxxxxx]
> > On
> > Behalf Of Hal Murray
> > Sent: Friday, August 04, 2006 8:49 AM
> > To: si-list@xxxxxxxxxxxxx
> > Cc: hmurray@xxxxxxxxxxxxxxx
> > Subject: [SI-LIST] Re: DDRAM BUS Testing
> >
> >
> > > Ihsan, in most systems we have many capacitors.  In many of the 
> > > more expensive systems, we also tend to have relatively thin power 
> > > cavities tying capacitors and loads together.  So, removing one 
> > > cap for the sake of measurement yields a tolerable error that we 
> > > can pretty much calibrate out once we consider the capacitor and 
> > > IC distribution, and the composition of the plane cavity(s).
> >
> > How often do people get in trouble because the manufacturing line 
> > misses a bypass cap or several?  (I don't remember any war stories 
> > on that topic.)
> >
> > Is there any simple way to check for that sort of thing in a 
> > production testing environment?  I'd expect the system to keep 
> > working, but with reduced noise margins.  That is it will work well 
> > enough to pass all the tests but might fail occasionally after it gets
to the customer.
> >
> > --
> >
> > The suespammers.org mail server is located in California.  So are 
> > all my other mailboxes.  Please do not send unsolicited bulk e-mail 
> > or unsolicited commercial e-mail to my suespammers.org address or 
> > any of my other addresses.
> > These are my opinions, not necessarily my employer's.  I hate spam.
> >
> >
> >
> > ------------------------------------------------------------------
> > 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 FAQ wiki page is located at:
> >                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> >
> > List technical documents are available at:
> >                 http://www.si-list.org
> >
> > 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 FAQ wiki page is located at:
> >                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> >
> > List technical documents are available at:
> >                 http://www.si-list.org
> >
> > 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 FAQ wiki page is located at:
>                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
>List technical documents are available at:
>                 http://www.si-list.org
>
>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 FAQ wiki page is located at:
                http://si-list.org/wiki/wiki.pl?Si-List_FAQ

List technical documents are available at:
                http://www.si-list.org

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: