[SI-LIST] Re: Power Supply Distribution/Filtering/Decouplin g Guide]
- From: steve weir <weirsp@xxxxxxxxxx>
- To: "Michael E. Vrbanac" <vrbanacm@xxxxxxxxxx>, Lfresearch@xxxxxxx,Ken.Cantrell@xxxxxxxxxxxxxxxx, scott@xxxxxxxxxxxxx
- Date: Wed, 14 Jan 2004 22:01:32 -0800
Michael,
I agree with your concerns. I think that we likely agree that it is
completely possible and totally impractical to define a component that no
realizable system can support. That doesn't work for either the chip
maker, or the system integrator.
So, the way that I am trying to approach this is to take a set of commonly
used geometries as representative of what is possible in manufacturing from
cost sensitive consumer at one end, to completely performance driven, sic
cost is no object at the other. These are then offered as the models any
one of which a chip vendor may choose to fit their design against. As
examples, PHY's for LAN / telecom line cards are going onto much more cost
sensitive boards, than network processors, or top-end multi-CPU server
chipsets. If it takes exotic construction to support such a PHY, the chip
maker has made a dire mistake. Any customers they get will go broke as
their competitors field market effective product.
Now given a limited state-space for the physical attachment environment, a
chip maker can explore the trade-offs of their package and internal power
distribution design. They can then define the impedance profile versus
frequency, and current profile versus time to be supplied to the mounted
configuration(s) that they elect to support as makes sense to their market
and their technical needs. The mounted configuration provides a common
manufacturable basis that is not arbitrarily dictated by the wants or whims
of either the chip maker or the system integrator.
Now suppose for a moment that we try and go about this another way by
specifying impedance profile and current demand at the package independent
of the attachment. To do so properly I believe requires essentially all of
the information elements that Scott previously listed. Impedance magnitude
isn't enough because the attachment is part of the complex impedance seen
by the PDN of the component when mounted, and the internal needs of the
part can be intricate. As an integrator, I would need to know with fairly
high precision reactances that could vary by each package termination. And
even given all of that information, at the end of the day, the chip maker
may have defined an impossible to integrate part.
Then finally consider, how does a chip vendor validate to their customers
that the chip meets the specifications represented. Reference designs suck
at this, because all too often the reference design is built only to prove
that the part can work in some limited and contrived configuration.
So just to summarize:
1) Create a common, quantified environment that includes the device attachment.
2) Allow sufficient variations in the defined environments to serve the
majority of markets served by the chip and system vendors.
3) Define the impedance vs frequency profiles, and current versus time
profiles in the attached environment.
If anyone has an idea they like better, I am happy to hear it.
Regards,
Steve.
At 11:34 PM 1/14/2004 -0600, Michael E. Vrbanac wrote:
>Steve,
>
>Ok. At least at PCB end of things, the first criteria could be considering
>the "board stackup power environment/impedance".
>
>Or is it? While what you mentioned is certainly vital, it may be the
>wrong end
>of the problem on which to start out ... and I'm seeing you and several others
>touching on the other end of the problem in their posts or hinting at it
>but not
>directly saying it.
>
>The device requires whatever peak current it needs during its switching
>intervals
>regardless of what environment we place it in. Perhaps our environment
>will support it,
>perhaps not. We'll need the proper information to make those decisions
>though i.e.
>with device transient current requirements.
>
>Bottom line...
>We cannot design properly without appropriate specifications. The device
>transient
>current demand is necessary to determine just how much decoupling is
>needed and
>what type of power structure is necessary to support it. When we finally
>get this sort
>of information, it'll be time to more intelligently design our decoupling
>systems. Until
>then, everyone of us might as well be guessing.
>
>Isn't that what C = ( i * dt) / dv has suggested to us all along?
>
>Does this make any sense at all?
>
>Best Regards,
>
>Michael E. Vrbanac
>
>
>
>At 09:58 PM 1/13/2004 -0800, steve weir wrote:
>>Mike,
>>
>>I am willing to participate, even drive ( if people put up with me ) effort
>>to establish standards for chip to board power, and I/O return current
>>requirements. I'll repeat my first suggestion which is one of creating one
>>or a series of references based on common real-life boards. A short list
>>would be:
>>
>>1) .062 board, commercial service, 6 layer S/G/S/S/P/S, I suggest .014 from
>>L2 to L5, others may differ.
>>2) .031 board, commercial service as in 1), sic PC-CARD / memory module
>>3) .096 board, "high performance", 12 layer
>>
>>Assuming that we could reach a consensus on a limited number of reference
>>substrates, then that nails down the characteristics of the "bridge"
>>between the PCB engineer's world and the chip vendors'.
>>
>>What do you think?
>>
>>Steve.
>>
>>At 11:32 PM 1/13/2004 -0600, Michael E. Vrbanac wrote:
>> >Ken,
>> >
>> >re: "I don't know about "laying it to rest" since nothing will be achieved
>> >that
>> >way."
>> >
>> >I've heard all sorts of ideas over nearly three decades and we haven't
>> >gotten really any farther except there are more of us who know more about
>> >it better now. Could we all try to develop a set of design criteria so
>> we can
>> >speak the same on this? All the problems that have been brought up are the
>> >same ones from long ago.
>> >
>> >I hear what Chris is saying and agree. If you won't listen to me then
>> please
>> >listen to him.
>> >
>> >re: bully pulpit
>> >I say what I think and sometimes I get too direct (and longwinded) but I
>> >always try
>> >to do so to help. Its a fault of mine. I'm just growing up to be a
>> >"cranky old, guy". <grin>
>> >Avoid it yourself if you can. If I've missed the mark, then I'm sorry to
>> >all who felt that way.
>> >
>> >re: "Defining the requirements is not an issue; we have the expertise."
>> >I actually think we have it now. Some time ago, however, I didn't think
>> >so. But I
>> >think you missed my point. The whole discussion revolves around us NOT
>> >defining
>> >the requirements comprehensively even though we think we CAN. We, on the
>> >whole and as a
>> >group, have not gone the final step to fully describe the problem, its
>> >potential variations, its
>> >remedies, and its applications for the multitude of design engineers out
>> >there who need the answers.
>> >I still have my moments when I wonder if anyone on this forum could truly
>> >answer the "when can
>> >I safely relax the decoupling design?" question. I think this because I've
>> >never seen any sort
>> >of definitive design criteria related to this subject in the public domain.
>> >
>> >re: the lack of time or abilities... its a political thing
>> >Well, I guess that sort of sums up why we are where we are. We are just
>> >innocent victims
>> >of the political environment, aren't we? Perhaps we like to argue
>> >more? <grin>
>> >
>> >re: bottom line
>> >Its a sad thing to see the confusion especially when you see the effects of
>> >it on the design
>> >engineers charged with making the design decision. I see that a
>> >lot. These folks need
>> >good clear answers, not more and more debate. We need a consistent set of
>> >criteria
>> >for making good solid engineering decisions for decoupling that encompasses
>> >the "good"
>> >and the "bad" parts, the insensitive systems and the very sensitive
>> systems.
>> >
>> >The time is now. There's enough experts. There's enough known. What's
>> >holding it back?
>> >
>> >My second challenge to the forum: Anyone up to it?
>> >
>> >I'd do it but doing it alone only makes for more arguments. This would
>> >have to be a collaborative
>> >thing.
>> >
>> >Best Regards,
>> >
>> >Michael E. Vrbanac
>> >
>> >
>> >At 06:14 PM 1/13/2004 -0500, Lfresearch@xxxxxxx wrote:
>> > >In a message dated 1/13/2004 2:29:18 PM Central Standard Time,
>> > >Ken.Cantrell@xxxxxxxxxxxxxxxx writes:
>> > >Mike,
>> > >I don't know about "laying it to rest" since nothing will be achieved
>> that
>> > >way. Using the list as a bully pulpit seems to be ineffective so
>> far. You
>> > >have some good ideas, and Scott/Chris/Steve are playing the same tune.
>> > >Defining the requirements is not an issue; we have the
>> expertise. However,
>> > >none of us have the time or abilities to fight the political battles
>> > >involved, i.e., forming a committee to establish the requirements, and
>> > >following through to completion. Perhaps Mark Montrose might have some
>> > >ideas on how to proceed since he's been the torch bearer for making SI a
>> > >separate discipline (TC-10), or some of the folks working on the IBIS
>> > >committee (Lynn Green pops to mind).
>> > >Ken
>> > >Hi Chaps,
>> > >I was one of the founders of TC-10, along with Mark. When we were
>> discussing
>> > >TC-10, this was one of the very issues that motivated us. I strongly
>> > >encurrage
>> > >anyone interested to forward ideas, concers to TC 10 for discussion.
>> TC-10
>> > >was not intended to be solely SI, but also the EMC aspects that go
>> hand in
>> > >hand
>> > >with SI
>> > >
>> > >Cheers,
>> > >
>> > >Derek N. Walton
>> > >Owner, L F Research EMI Design and Test Facility
>> > >Poplar Grove,
>> > >IL 61065
>> > >
>> > >
>> > >------------------------------------------------------------------
>> > >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:
