[SI-LIST] Re: Power Supply Distribution/Filtering/Decouplin g Guide]
- From: "Michael E. Vrbanac" <vrbanacm@xxxxxxxxxx>
- To: scott@xxxxxxxxxxxxx, si-list@xxxxxxxxxxxxx
- Date: Tue, 13 Jan 2004 11:26:22 -0600
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
Other related posts:
