[SI-LIST] Re: Power Supply Distribution/Filtering/Decouplin g Guide]

  • From: "Michael Khusid" <mkhusid@xxxxxxxxxx>
  • To: <scott@xxxxxxxxxxxxx>, <hassan@xxxxxxxx>
  • Date: Tue, 13 Jan 2004 13:40:26 -0500

Scott,

I think this is a great list. From my experience, many device vendors =
not
only fail to provide this information, but they also don't know how to
measure/simulate it.

Mike

----------------------------------------------------------------
Michael Khusid
Ansoft Corporation
SI/HF Application Engineer
=20
25 Burlington Mall Road, 5th floor
Burlington, MA 01803-4100
=20
Tel 781-229-8900 Ext. 134=20
Fax 781-229-8624
---------------------http://www.ansoft.com ---------------------

> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx =
[mailto:si-list-bounce@xxxxxxxxxxxxx]
> On Behalf Of Scott McMorrow
> Sent: Tuesday, January 13, 2004 12:39 PM
> To: hassan@xxxxxxxx
> Cc: silist
> Subject: [SI-LIST] Re: Power Supply Distribution/Filtering/Decouplin g
> Guide]
>=20
> Hassan,
> In order to design a PDS w.r.t. the silicon and package the following
> are needed from vendors:
>=20
>     * Model for excess on-die capacitance for each power/ground rail,
>       including on-chip decoupling capacitance, average excess
>       capacitance, resistance and inductance of power meshes, with
>       frequency dependent loss modeling.
>           o This may require a full wave s-parameter model of the =
silicon.
>     * Model for core current profile.
>           o worst case profile for stop/start
>           o worst case profile for normal operation
>     * Worst case ripple margin.
>     * Accurate model for device package including:  redistribution
>       layer, bump or wire bond models, substrate and balls, which are
>       valid across the bandwidth required for the particular power =
rail.
>           o For extremely high bandwidth designs, this may even =
require
>             that the each individual bump, die pad, and ball be =
modeled
>             individually, which would require a full wave n-port
>             s-parameter model.
>     * Or ... an "in the can" design guide that specifies reasonable
>       requirements for the PCB, and a guarantee that the silicon will
>       work if the design guide is followed.
>=20
> Others who have done more power delivery work than me can certainly
> amplify this list.
>=20
> regards,
>=20
> scott
>=20
>=20
> Hassan O. Ali wrote:
>=20
> >Scott,
> >
> >Thanks for confirming my understanding on the subject. You've =
provided an
> excellent
> >summary. I certainly misunderstood what Chris was claiming. I'm sorry =
for
> that.
> >
> >Now that we are on the same bandwidth, let's talk a little bit more =
about
> the
> >information that system designers need to have to have a full control =
of
> the PDS design.
> >At present, we work with device's voltage ripple tolerance and =
current
> requirements to
> >determine PDS impedance. Why do you think that information is not =
enough?
> >
> >Thanks.
> >
> >Hassan.
> >
> >
> >
> >On Jan 13, "Scott McMorrow" <scott@xxxxxxxxxxxxx> 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
> >><a href=3D'http://www.teraspeed.com'>http://www.teraspeed.com</a>
> >>
> >>
> >>
> >>
> >>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
> >
> >
> >
> >
>=20
> --
> Scott McMorrow
> Teraspeed Consulting Group LLC
> 2926 SE Yamhill St.
> Portland, OR 97214
> (503) 239-5536
> http://www.teraspeed.com
>=20
>=20
>=20
>=20
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>=20
> or to administer your membership from a web page, go to:
> //www.freelists.org/webpage/si-list
>=20
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>=20
> List technical documents are available at:
>                 http://www.si-list.org
>=20
> 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
>=20

------------------------------------------------------------------
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: