[SI-LIST] Re: Power Supply Distribution/Filtering/Decouplin g Guide]
- From: steve weir <weirsp@xxxxxxxxxx>
- To: swldstn@xxxxxxxxxxxx, <vrbanacm@xxxxxxxxxx>,<scott@xxxxxxxxxxxxx>
- Date: Tue, 13 Jan 2004 20:20:26 -0800
Steven,
Then I think the best thing to do is to pick a benchmark PCB configuration
and use that as the basis of what your chips have to work with. When you
do your chip designs, what interface requirements do you impose/assume for
power delivery at the component to PCB interface? Do you verify against
those requirements, and do you publish them to your customers?
Regards,
Steve.
At 11:03 PM 1/13/2004 -0500, Steven M. Waldstein wrote:
>To all,
>
>As a component designer we also struggle with the best trade-offs
>of power delivery and how they impact component cost. Often times
>we are forced to find the lowest cost solution that is sub optimum
>because we continually pressured on price. Eliminating on package
>capacitor saves money as well as smaller die with less on die
>decoupling.
>
>An other example of this is package size. I think larger, easier
>to route ( in the package and on the board ) are a better trade off
>but customers push on cost the forces us into smaller BGA substrates
>that offer poorer signal quality and more PCB layers so the component
>cost, not system cost, can be optimized.
>
>Even with this we have adopted a philosophy that the die/package/PCB
>power delivery must work and we do reference designs we think are
>representative of end user systems and technology. That's the best way
>we know of the deliver a quality product. The faster end users can
>design and field their systems the sooner we see volume purchases.
>We want to lower or eliminate the system integrators barriers.
>
>Steve
>swldstn@xxxxxxxxxxxx
>
>-----Original Message-----
>From: si-list-bounce@xxxxxxxxxxxxx
>[mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Michael E. Vrbanac
>Sent: Tuesday, January 13, 2004 12:26 PM
>To: scott@xxxxxxxxxxxxx; si-list@xxxxxxxxxxxxx
>Subject: [SI-LIST] Re: Power Supply Distribution/Filtering/Decouplin g
>Guide]
>
>
>Scott,
>
>I've been at this a long time, too, and concur with each of those points.
>
>So when are we going to do something about it? So we know what we
>needs to be done and have known that for a many years, how do we
>change our "rant" into real change? If we who know what to do don't do
>something, it'll wait until very last minute and we'll have to tolerate the
>"good" vs. "poor" chip problem until then.
>
>I would propose this:
>
>A benchmark for power rail performance and power rail induced signal
>aberrations is required. Until we have that, we'll be arguing the best
>way to do this till we all retire. Without a standard, we have nothing to
>complain about because its "not a requirement" yet and nothing can be
>"measured".
>
>Define the elements of that benchmark and carefully define the measurements
>such as to make an engineering standard by which to judge when a chip is
>"good" vs. "poor" as far as power rail performance, etc.. The standard
>might
>have various compliance levels to meet the needs of different types of
>equipment
>i.e. all digital systems might have less stringent requirements and mixed
>signal
>designs perhaps more. We have specs for everything else. Why not
>"min/typ/max"
>specs for power rail and power rail induced signal aberrations?
>
>But don't stop there. Demand the performance you need from the
>manufacturers.
>Money talks you know. So does the problem physics presents them as they
>attempt
>to increase performance. Those two very convincing issues will spark some
>ingenuity somewhere and with the internal pricing pressures the
>manufacturers
>will eventually figure out how to do quite well on price and
>performance. Its almost
>as predictable as Moore's Law.
>
>At that point, we can certainly move on to other technical issues and
>attempt to
>solve those instead. I've seen countless posts on decoupling since this
>forum
>started and nothing has happened yet. To me, the subject is so old, its
>time to
>lay it to rest.
>
>Anyone up to it?
>
>Best Regards,
>
>Michael E. Vrbanac
>
>
>
>At 07:01 AM 1/13/2004 -0800, you wrote:
> >Hassan,
> >Huh! I think you ought to go back and read Chris's postings (which go
> >back for years) a bit more carefully. I would sum up his points like this:
> >
> >1) High frequency core and I/O power should be decoupled on-chip, since
> >it is the only place to effectively place capacitance that can decouple
> >something switching in the 500+ MHz range.
> >
> >2) This can be augmented, if necessary, by appropriate decoupling on the
> >package.
> >
> >3) Signal return paths should be matched from die, through package, and
> >out onto the PCB, to eliminate noise injection from mode conversion.
> >
> >4) Lower frequency decoupling, 100 MHz and below, can be accomplished on
> >the PCB.
> >
> >If decoupling is not accomplished in this manner, then inductance and
> >response time get in the way of any attempts to decouple a device using
> >a PCB. (Ultimately only the pads or bumps on the silicon matter.)
> >
> >As far as your comments regarding power being delivered by backplane
> >connectors and traces, or fat traces on PCBs, this is just plain silly.
> >Only the lowest frequency power delivery is accomplished in this
> >fashion. High frequency power delivery is accomplished by local
> >capacitance and thin power/ground plane pairs.
> >
> >Chris's comment , "if you have poorly design chip and package, you need
> >a hell of a lot of decoupling and BC planes to fix it at the system
> >level", is hardly a generality. It is a statement of fact. We face
> >this every day with large FPGAs. These devices were designed with
> >horrible power decoupling problems at the die and package. To "fix"
> >these devices, or to get them to run with even the slightest of margins,
> >requires extremely over-designed PCBs and decoupling networks.
> >
> >The reality is that there are well designed chips and packages out
> >there, and those that are poorly designed. We as system designers have
> >no way of objectively knowing which is which, without placing them on a
> >PCB and in a system and measuring them.
> >
> >regards,
> >
> >scott
> >
> >--
> >Scott McMorrow
> >Teraspeed Consulting Group LLC
> >2926 SE Yamhill St.
> >Portland, OR 97214
> >(503) 239-5536
> >http://www.teraspeed.com
> >
> >
> >
> >
> >Hassan O. Ali wrote:
> >
> > >I'm afraid this discussion is getting into over-generalization and
> > >over-simplification of the problem in question.
> > >
> > > Chris Cheng says:
> > >
> > > > if you have
> > >
> > >
> > >> poorly design chip and package, you need a hell of a lot of decoupling
>and
> > >> BC planes to fix it at the system level
> > >>
> > >>
> > >
> > >That is one example of generalization. Not every device-level power
> > >distribution flaw can be solved at the board level. As a matter of fact,
> > >many papers/documents I've read so far on this subject do clearly
> > >indicate the limitations of the PDS at the board level. The board-level
> > >PDS design only focuses on providing the power quality at the device's
> > >power pins/balls.
> > >
> > >Contrary to what Chris Cheng wants us to believe, you cannot
> > >realistically meet all power distribution requirements by focusing only
> > >on the device level. For one thing, the power comes from outside the
> > >device, right? How can you then ignore the path through which the power
> > >goes through before entering the device! Will the power delivered
> > >through two backplane connectors and a 60-in backplane trace be of the
> > >same quality as that delivered through an inch of fat PCB trace?
> > >Certainly not.
> > >
> > >Hassan.
> > >
> > >
> > >
> > >Scott McMorrow wrote:
> > >
> > >
> > >
> > >>Chris is correct.
> > >>
> > >>This was exactly my point previously. Without knowledge of the silicon
> > >>and package power distribution it is impossible to perform an analysis
> > >>of the entire power distribution system. But a well designed piece of
> > >>silicon and package will require very little support from the PCB.
> > >>
> > >>scott
> > >>
> > >>
> > >>Chris Cheng wrote:
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>>I disagree. No one should be surprised. I have said many times, there
>is
> > >>>never a need for fancy decoupling scheme on PCB for properly design
> > >>>processor and package. Nothing should be need for >100MHz core noise
>and
> > >>>signal return is a case of reference plane management (does that sound
> > like
> > >>>a broken record yet ?)
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> > >
> > >------------------------------------------------------------------
> > >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.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
> > >
> > >
> > >
> > >
> >
> >
> >--
> >Scott McMorrow
> >Teraspeed Consulting Group LLC
> >2926 SE Yamhill St.
> >Portland, OR 97214
> >(503) 239-5536
> >http://www.teraspeed.com
> >
> >
> >
> >
> >------------------------------------------------------------------
> >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.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 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 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 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:
