[SI-LIST] Re: DDRAM BUS Testing

  • From: steve weir <weirsi@xxxxxxxxxx>
  • To: erdinih@xxxxxxxxx,janton@xxxxxxxxxxxx
  • Date: Sat, 05 Aug 2006 06:56:20 -0700

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: