[SI-LIST] Re: PDS analysis?
- From: steve weir <weirsi@xxxxxxxxxx>
- To: Lee Ritchey <leeritchey@xxxxxxxxxxxxx>
- Date: Thu, 03 Apr 2008 15:07:15 -0700
Lee, and many other people used that particular FPGA / FPGA series
successfully albeit some had to go through some headaches to get there.
A lot of OEM's have ceded their responsibility to determine the
feasibility of using parts for a particular application to the component
vendor. OEMs that do this, ( and there are a lot of them ) roll the
dice hoping that the component vendor delivers a part that is going to
work as the OEM intends to use it: with the OEM's stack-up, and the
OEM's bypass scheme, and on the power rail that the OEM may or may not
be sharing with other ICs. This is a particularly dangerous practice
when using programmable parts because the potential design space is
enormous.
Every component package has limitations, and even though they are
greatly improved over older devices, the latest generation of FPGAs have
their limitations too. One might ask had the company that failed
evaluated the package capability / limitations up-front whether they
still would have failed. I doubt it. They would have realized that the
part simply was not likely to be useable the way they intended with the
implementation method they intended. Whether they could have altered
their implementation so that particular part would still be useful
remains an unanswered question. There are a number of things that can
be done to cope with packages that leave room for improvement, even a
lot of room for improvement. But if a system design is committed
ignorant of the package limitations, then the consequences are
discovered late when implementation of design alternatives is costly, if
still available at all.
My advice to OEMs is to responsibly deal with their ownership of the
system engineering. That includes risk assessment up front. Risk
assessment with ICs includes determining the PDN requirements and
functional limitations of any function critical device. If one can
reliably extract sufficient information from a vendor to establish: 1)
The part can be made to work in the application as intended, and 2) What
means are necessary to get there, then a design with that part can
proceed. Otherwise, the OEM needs to do whatever is necessary to answer
those two questions for themselves.
To me it seems absurd how often OEMs choose to ignore Ohm's Law and just
hope for the best. Way too many just assume they can use some component
without adequate specification of power requirements and corresponding
design by analysis of a suitable PDN to meet those requirements. To me
that's nothing more than a game of Russian Roulette. This thread really
began with questions about what are the odds that a loaded chamber comes
up if one uses some combination of ad-hoc practices. Ivor's informal
survey indicates that there are a number of folks who seem to believe
that since they have survived so far that it's a safe game. Others such
as myself vociferously disagree.
IMO the body count of those who played the game with that challenging
FPGA package says a lot more about the dangers of failing to do proper
system engineering than it does about any of the FPGA vendors or the
weaknesses of any given chip. Unless OEMs fancy following that start-up
into insolvency, IMO they would be wise to put the gun down. To Chris'
oft repeated point: it would be a lot easier if the vendors supplied
good models that include the effects that are significant, than for each
user to have to go out and create their own from measurements.
Best Regards,
Steve.
Lee Ritchey wrote:
> When all this unfolded I had four clients suffering from the same problem.
> One of them was a start up that failed because of it.
>
>
>
>> [Original Message]
>> From: Ken Cantrell <Ken.Cantrell@xxxxxxxxxxxxxxxx>
>> To: Lee Ritchey <leeritchey@xxxxxxxxxxxxx>; Steve Weir <weirsi@xxxxxxxxxx>
>> Cc: Chris Cheng <Chris.Cheng@xxxxxxxx>; Ivor Bowden
>>
> <ibowden@xxxxxxxxxxxxxxxxx>; Gil Simsic [IEEE] <gilsimsic@xxxxxxxx>;
> <si-list@xxxxxxxxxxxxx>
>
>> Date: 3/31/2008 11:50:48 AM
>> Subject: [SI-LIST] Re: PDS analysis?
>>
>> Lee, Steve, et. al,
>> My experience is more in line with Lee and Chris's. I was very familiar
>> with the vendor's parts and had used them extensively in the past. There
>> were no layout issues. All of the vendor's guidelines and recommendations
>> were implemented, plus more advanced techniques. However, this time
>>
> nothing
>
>> that I did on the board could touch the problem. Absolutely no effect. I
>> had never seen that happen before.
>> However, I was not treated poorly by the vendor. It just took a month of
>> intensive review and exchange to reach a conclusion. Cost my company 9
>> months and a re-design with a competitor's part (which worked on first
>>
> power
>
>> up)). Needless to say I was not a happy camper at the time.
>>
>> Ken
>>
>> -----Original Message-----
>> From: si-list-bounce@xxxxxxxxxxxxx
>> [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Lee Ritchey
>> Sent: Monday, March 31, 2008 10:09 AM
>> To: Steve Weir
>> Cc: Chris Cheng; Ivor Bowden; Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
>> Subject: [SI-LIST] Re: PDS analysis?
>>
>>
>> Steve,
>>
>> Your recollections are a bit off. The engineer did every one of the
>> manufacturers fixes to no avail. In one case, two different packages with
>> the same data bus were placed on the same PCB, ala Howard Johnson's famous
>> test PCB, and the results were very much like those that Howard got. It
>>
> was
>
>> this final test that convinced those who needed convincing that the
>>
> package
>
>> needed a redesign, and sure enough, that happened. Indeed, the vendor in
>> question hired a group of package design specialists as a result of this
>> experience as did their primary competitor.
>>
>> I've got all the measured data on those tests and plenty of bad memories
>> about how this engineer was treated by the vendor. The experience was bad
>> enough that the engineer decided to go into investment banking. Might be
>> the smartest of all of us!
>>
>> What we were not successful in doing is getting them to stop adding
>>
> ferrite
>
>> beads to the power leads of the serdes. That gave rise to another ad
>>
> blitz
>
>> in EE Times showing good eyes and bad eyes.
>>
>> Most of us have seen this ad campaign. As I recall, you did a set of
>>
> tests
>
>> showing that adding all those ferrites was not a good idea and presented a
>> paper to that effect. Don't know if that has had the desired effect.
>>
>>
>>
>>> [Original Message]
>>> From: steve weir <weirsi@xxxxxxxxxx>
>>> To: <leeritchey@xxxxxxxxxxxxx>
>>> Cc: Chris Cheng <Chris.Cheng@xxxxxxxx>; Ivor Bowden
>>>
>> <ibowden@xxxxxxxxxxxxxxxxx>; Gil Simsic [IEEE] <gilsimsic@xxxxxxxx>;
>> <si-list@xxxxxxxxxxxxx>
>>
>>> Date: 3/31/2008 8:45:29 AM
>>> Subject: Re: [SI-LIST] Re: PDS analysis?
>>>
>>> Lee, Chris's point which is well taken is that we can make the PCB
>>> quiet and if the chip is bad enough, it still won't work. But, if the
>>> case that you are talking about is that thing featured in EE Times at
>>> the end of 2004, as I recall the engineering manager was quoted as
>>> saying they had excessive noise on the PCB. If that quote was right,
>>> they killed themselves with the PCB design whether or not the chip had
>>> problems. As I recall also, the user put up considerable resistance
>>> against implementing the manufacturer's suggested fixes.
>>>
>>> Best Regards,
>>>
>>>
>>> Steve.
>>>
>>> Lee Ritchey wrote:
>>>
>>>> Chris,
>>>>
>>>> A while back we saw this in spades with a certain FPGA vendor who
>>>> stonewalled its customers when their products failed.
>>>>
>>>>
>>>>
>>>>
>>>>> [Original Message]
>>>>> From: Chris Cheng <Chris.Cheng@xxxxxxxx>
>>>>> To: <leeritchey@xxxxxxxxxxxxx>; Steve Weir <weirsi@xxxxxxxxxx>
>>>>> Cc: Ivor Bowden <ibowden@xxxxxxxxxxxxxxxxx>; Gil Simsic [IEEE]
>>>>>
>>>>>
>>>> <gilsimsic@xxxxxxxx>; <si-list@xxxxxxxxxxxxx>
>>>>
>>>>
>>>>> Date: 3/30/2008 11:12:39 PM
>>>>> Subject: RE: [SI-LIST] Re: PDS analysis?
>>>>>
>>>>> The problem is not whether you can have a crappy designed package
>>>>>
> that
>
>>>> can have hundreds of MHz of noise. If it is large enough on die, you
>>>>
>> will
>>
>>>> have fractions of the noise spilling out.
>>>>
>>>>
>>>>> Sure, you can put your plane capacitance or exotic caps to make the
>>>>>
>>>>>
>>>> external power flat like a straight line without any ripple. But does
>>>>
>> it do
>>
>>>> a single thing to damp down your core power noise at your die ? You
>>>>
> can
>
>> put
>>
>>>> a million caps or planes outside your package and make your external
>>>>
> pin
>
>>>> quiet. But it will not have any measureable effect on your on die
>>>>
>> noise.
>>
>>>>> It is the same as seeing a leaking diaper and just wipe the outside
>>>>>
>> clean
>>
>>>> or put an extra one to cover it, I guarantee it will not have any
>>>>
> effect
>
>>>> for the end user.
>>>>
>>>>
>>>>> ________________________________
>>>>>
>>>>> From: Lee Ritchey [mailto:leeritchey@xxxxxxxxxxxxx]
>>>>> Sent: Sun 3/30/2008 11:21 AM
>>>>> To: Steve Weir; Chris Cheng
>>>>> Cc: Ivor Bowden; Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
>>>>> Subject: RE: [SI-LIST] Re: PDS analysis?
>>>>>
>>>>>
>>>>>
>>>>> I've got some ICs with core frequency transients well into the
>>>>>
>> hundreds of
>>
>>>>> MHz. Looks like the on die and on package capacitance was not done
>>>>>
>> well.
>>
>>>>> Fixed with a little more plane capacitance.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> [Original Message]
>>>>>> From: steve weir <weirsi@xxxxxxxxxx>
>>>>>> To: Chris Cheng <Chris.Cheng@xxxxxxxx>
>>>>>> Cc: Bowden, Ivor <ibowden@xxxxxxxxxxxxxxxxx>; Gil Simsic [IEEE]
>>>>>>
>>>>>>
>>>>> <gilsimsic@xxxxxxxx>; <si-list@xxxxxxxxxxxxx>
>>>>>
>>>>>
>>>>>> Date: 3/29/2008 10:23:32 PM
>>>>>> Subject: [SI-LIST] Re: PDS analysis?
>>>>>>
>>>>>> Chris, I appreciate your experience w/ changing out caps.
>>>>>>
> Sprinkling
>
>>>>>> caps of some arbitrary values to cure EMI ills is a bit akin to
>>>>>>
>> hunting
>>
>>>>>> rabbits with a revolver on a dark moonless night in the desert.
>>>>>>
>>>>>> 100MHz as a high cut-off for IC core currents is often a reasonable
>>>>>> number due to limitations of both planes and IC packages. It is not
>>>>>> however a reasonable number for many I/O rails. Nor does it account
>>>>>>
>> for
>>
>>>>>> the evils of packaged ICs that include significant problematic
>>>>>> resonances. I've got examples that occur way above 100MHz. We just
>>>>>> worked one recently where the resonance was about 600MHz. We
>>>>>>
> handily
>
>>>>>> corrected it with a single X2Y capacitor.
>>>>>>
>>>>>> The IC spec deficiencies are well known evils. Getting decent specs
>>>>>>
>> is
>>
>>>>>> the starting point for a competent design.
>>>>>>
>>>>>> For the two rules, personally I like coefficients for any problem.
>>>>>>
>> Over
>>
>>>>>> design costs too much money. Under design invites disasters. Ask
>>>>>> Microsoft about their ever ballooning liabilities w/ the Xbox 360.
>>>>>>
> I
>
>>>>>> haven't seen a single problem with that fiasco yet that doesn't
>>>>>>
> trace
>
>>>>>> back to engineering deficiencies.
>>>>>>
>>>>>> The idea of using bypass caps to cover to 100MHz only is a
>>>>>>
>> demonstrably
>>
>>>>>> dubious truism. There are a number of chips out there that I can
>>>>>> demonstrate misbehave when the bypass network doesn't deal with
>>>>>> frequencies at 300MHz or higher. So, this is one time that I have
>>>>>>
> to
>
>>>>>> disagree with your advice.
>>>>>>
>>>>>> We do agree on the value and wisdom of managing the I/O return path.
>>>>>> "Ask not what your PDN can do for signal returns. Ask what your
>>>>>> physical design can do to avoid injecting unnecessary noise into the
>>>>>>
>>>>>>
>>>> PDN."
>>>>
>>>>
>>>>>> A parting comment on using a ton of 100nF caps. It used to be that
>>>>>>
>> this
>>
>>>>>> could work rather well when the overall density of the capacitors
>>>>>>
>> pushed
>>
>>>>>> the PRF between the bypass network and the planes out beyond the
>>>>>>
>> spectra
>>
>>>>>> of both the bit and edge rates. Nowadays that is just a very
>>>>>>
>> expensive
>>
>>>>>> if not just impossible approach.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>>
>>>>>> Steve.
>>>>>>
>>>>>> Chris Cheng wrote:
>>>>>>
>>>>>>
>>>>>>> My first disclaimer will be :
>>>>>>> YMMV
>>>>>>> my second will be :
>>>>>>> I still don't have the balls to do single value highspeed ceramic
>>>>>>>
>> caps
>>
>>>>>>> but I do think .1u is a good starting point to go up to 1u and down
>>>>>>>
>> to
>>
>>>>>>> .01u or even 1nf if you have a well designed flip chip package.
>>>>>>>
> For a
>
>>>>>>> el-cheapo wire bond package .1u might even be good enough as
>>>>>>>
>> "external
>>
>>>>>>> highspeed cap" to begin with.
>>>>>>>
>>>>>>> That said, I have at least two experiences that make me have second
>>>>>>> thoughts :
>>>>>>> 1) In one of my large product platforms (big server type machine),
>>>>>>> during the first proto stage on the first EMI scan, my board design
>>>>>>> guy accidentally generated the wrong BOM and stuff all the
>>>>>>>
> highspeed
>
>>>>>>> caps that were supposed to be 1u,0.1uf and 0.01uf spread to a
>>>>>>>
> single
>
>>>>>>> value 0.1uf. We actually send it through the EMI scan and it
>>>>>>>
> actually
>
>>>>>>> pass FCC scan with good margin. And the system ran through all PVT
>>>>>>> margin tests. Is it our luck or good enough to begin with ? I'll
>>>>>>>
> let
>
>>>>>>> you speculate.
>>>>>>> 2) In the workstation/server company we came from, on an occasion
>>>>>>> after we had a big screaming session with the EMI engineer on our
>>>>>>> designs, we secretly rework out all the 10pf,100pf and 100pf caps
>>>>>>>
>> that
>>
>>>>>>> she sprinkled on our board with 1u caps and send it to her to scan.
>>>>>>> And as expected it passed FCC with good margin. We lost all our
>>>>>>> respect of her and probably EMI engineers in general after that.
>>>>>>>
>>>>>>> Typical IC spec calls out the peak current demand. A more
>>>>>>> sophisticated one calls out the peak di/dt. A even more
>>>>>>>
> sophisticated
>
>>>>>>> one calls out the voltage tolerance between different frequency
>>>>>>>
>> bands.
>>
>>>>>>> No where does it tell you how it can ramp from zero current to peak
>>>>>>> during normal operation.
>>>>>>> No where can it tell you if your system architecture can actually
>>>>>>>
> pin
>
>>>>>>> the I/O buses or subsystem to maximum activities during normal
>>>>>>>
>>>>>>>
>>>> operation
>>>>
>>>>
>>>>>>> No where does it tell you your super multi-processors backplane can
>>>>>>> actually maintain peak bandwidth on all cluster ports when the per
>>>>>>> node bandwidth is choked by say your on board memory bus or real
>>>>>>>
> I/O
>
>>>>>>> sustain bandwidth on board
>>>>>>> No where does it tell you in a typical multi-giga bit SERDES, even
>>>>>>>
> if
>
>>>>>>> the I/O is idle, the idle pattern actually draws zero power vs.
>>>>>>>
> peak
>
>>>>>>> activity
>>>>>>> No where does it tell you the bandwidth of your memory refresh
>>>>>>>
> cycle
>
>>>>>>> and access activity factor variations
>>>>>>>
>>>>>>> Once again, I won't say with only .1uf will work. But with sensible
>>>>>>>
>> up
>>
>>>>>>> and down values around it, it is a good starting point.
>>>>>>>
>>>>>>> And remember the two Chris Cheng rules of SI
>>>>>>> a) Manage your core power distribution with stages from die to
>>>>>>>
>> package
>>
>>>>>>> to PCB with highspeed at die/package and medium/low speed on PCB
>>>>>>> b) Manage your I/O return current properly
>>>>>>>
>>>>>>> If you buy the above, PCB decoupling is a matter of 100MHz or below
>>>>>>> PROVIDED you manage your return current properly.
>>>>>>>
>>>>>>> Another important point is also related to rule a) is if you
>>>>>>>
> believe
>
>>>>>>> your critical PCB distribution responsibility is around a few MHz
>>>>>>>
> to
>
>>>>>>> 100MHz, can you afford to waste your limited space on your PCB to
>>>>>>> populate those junk 10pf or 100pf other people love to sprinkle ?
>>>>>>>
>> Back
>>
>>>>>>> in the days when boards are big and performance and financial
>>>>>>> budget are loose, we chose to let whoever speculate whatever is
>>>>>>>
>> needed
>>
>>>>>>> provided he/she sign the design off in a bureaucratic company. Can
>>>>>>>
> we
>
>>>>>>> afford to do that anymore ? Not in a small company like mine and we
>>>>>>> make a conscious decision to hire one type of engineer responsible
>>>>>>>
>> for
>>
>>>>>>> both SI and EMI. And it worked out great.
>>>>>>>
>>>>>>> And if you have time/resources or stupid enough like me, why not
>>>>>>>
> try
>
>>>>>>> experiment 1) or 2) :-D.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
> ------------------------------------------------------------------------
>
>>>>>>> *From:* si-list-bounce@xxxxxxxxxxxxx on behalf of Bowden, Ivor
>>>>>>> *Sent:* Sat 3/29/2008 1:31 PM
>>>>>>> *To:* steve weir
>>>>>>> *Cc:* Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
>>>>>>> *Subject:* [SI-LIST] Re: PDS analysis?
>>>>>>>
>>>>>>> Hi Steve,
>>>>>>>
>>>>>>>
>>>>>>> Thank you for your reply! This is the type of answer I was looking
>>>>>>> for. I'm not "going anywhere with this", not advocating any
>>>>>>>
>> particular
>>
>>>>>>> position, just looking for information about ramifications of
>>>>>>>
> typical
>
>>>>>>> design practices.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I know that PDS analysis tools are not as ubiquitous as simulation
>>>>>>>
> /
>
>>>>>>> crosstalk tools, and many companies, especially smaller ones, tend
>>>>>>>
> to
>
>>>>>>> skip this step, instead relying on experience with past designs. I
>>>>>>>
>> was
>>
>>>>>>> wondering how frequently these designs have problems due to
>>>>>>> sub-optimal PDS, the nature of the problems, and the resolutions.
>>>>>>>
> For
>
>>>>>>> instance, have you seen many cases where going to smaller value
>>>>>>>
>> bypass
>>
>>>>>>> caps at specific points improved a broken circuit?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I apologize for not doing more research before posting the
>>>>>>>
> question.
>
>>>>>>> I'm sure I can find a variety of examples with enough searching.
>>>>>>> Mainly I was looking for opinion, preferably backed by knowledge.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As sort of an informal survey, it was interesting to note that the
>>>>>>>
>> off
>>
>>>>>>> list replies tended more towards "for typical boards PDS isn't
>>>>>>>
> needed
>
>>>>>>> if proper rules are followed", generally backed up with statistics
>>>>>>>
> of
>
>>>>>>> successful boards not PDS analyzed, while the on list replies tend
>>>>>>>
> to
>
>>>>>>> be more of the "always do PDS analysis" flavor.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Again, not going anywhere with this. I agree that the safest design
>>>>>>> practice is to fully simulate the design, including PDS.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ivor
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: steve weir [mailto:weirsi@xxxxxxxxxx]
>>>>>>> Sent: Saturday, March 29, 2008 3:00 AM
>>>>>>> To: Bowden, Ivor
>>>>>>> Cc: Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
>>>>>>> Subject: Re: [SI-LIST] Re: PDS analysis?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ivor, you can find examples in papers by people like Larry, Istvan,
>>>>>>>
>>>>>>>
>>>> and
>>>>
>>>>
>>>>>>> books that are out there. But, I am not sure where you are going
>>>>>>>
>> with
>>
>>>>>>> this. Since terms like "well fed" are ambiguous, I don't know what
>>>>>>>
>>>>>>> example you are looking for or to what purpose. My sense is that
>>>>>>>
> you
>
>>>>>>> have a belief that if one follows some ambiguous "industry
>>>>>>>
> practices"
>
>>>>>>> that the PDN will usually "work fine". Undefined engineering leads
>>>>>>>
>> to
>>
>>>>>>> undefined results. If you want predictable results then: Define
>>>>>>>
> the
>
>>>>>>> requirements and engineer to them.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We can characterize components to determine their actual power
>>>>>>>
>>>>>>>
>>>> delivery
>>>>
>>>>
>>>>>>> requirements. Once known we can easily demonstrate failures that
>>>>>>>
>>>>>>>
>>>> result
>>>>
>>>>
>>>>>>> when we don't meet those requirements. It is also easy to
>>>>>>>
>> demonstrate
>>
>>>>>>> what different PDN practices do to the impedance profile under any
>>>>>>>
>>>>>>> particular set of controlled circumstances we wish to create.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If you want to see resonance effects for yourself then: Design
>>>>>>>
> some
>
>>>>>>> board following one of the popular ad-hoc rules. If for example
>>>>>>>
> you
>
>>>>>>> design a board with one 0402 capacitor every two square inches and
>>>>>>>
>> the
>>
>>>>>>> plane cavity is 4mil FR406 on layers 2/3, the bypass to cavity PRF
>>>>>>>
>>>>>>>
>>>> will
>>>>
>>>>
>>>>>>> land around 330MHz depending on how you do your vias. If the planes
>>>>>>>
>>>>>>>
>>>> are
>>>>
>>>>
>>>>>>> deeper in the board that frequency will just go down. Then get
>>>>>>>
>>>>>>>
>>>> yourself
>>>>
>>>>
>>>>>>> a programmable clock generator and use it to drive some device
>>>>>>>
> like a
>
>>>>>>> PLD or FPGA with a bunch of outputs simultaneously in a simple
>>>>>>>
>> 1-0-1-0
>>
>>>>>>> sequence while you monitor the power supply planes with a decent
>>>>>>>
>>>>>>>
>>>> scope.
>>>>
>>>>
>>>>>>> Just step frequency until the bit rate / 2 excites the lowest
>>>>>>>
>> parallel
>>
>>>>>>> resonance in the power system. After that experiment see if your
>>>>>>>
>>>>>>> feelings about what works fine are still the same.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bowden, Ivor wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Gil,
>>>>>>>>
>>>>>>>> Thanks for sharing.
>>>>>>>>
>>>>>>>> By "real world" I do not mean rules of thumb and shortcuts, I mean
>>>>>>>>
>>>>>>>>
>>>>>>> examples. I expect that most folks on this list, especially those
>>>>>>>
> for
>
>>>>>>> whom SI is primary activity, can demonstrate examples of
>>>>>>>
> operational
>
>>>>>>> failures due to bad board layout. I also know that a large number
>>>>>>>
> of
>
>>>>>>> designs never get PDS analysis, yet work fine. I'm interested in
>>>>>>> typical modern technology designs that are laid out in standard
>>>>>>> industry practice: contiguous ground planes, tandem heavy split
>>>>>>>
> power
>
>>>>>>> planes not used as return reference, plenty of properly located
>>>>>>>
>> bypass
>>
>>>>>>> caps, etc that have operational failures which could have been
>>>>>>> pre-determined by PDS analysis, and if so, how did that operational
>>>>>>> failure manifest? For example, it would be interesting to see a
>>>>>>>
> scope
>
>>>>>>> (or simulation) snap shot of the voltage measured directly across
>>>>>>>
>> vias
>>
>>>>>>> to contiguous well fed planes as a device current requirement
>>>>>>> approaches the planes resonant frequency. And I mean a real device,
>>>>>>> not a hypothetical entity tuned to instig
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> e the problem.
>>>>>>>>
>>>>>>>> -Ivor
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>>
>>>>>>>> From: Gil Simsic [IEEE] [mailto:gsimsic.ieee@xxxxxxxxxxxxx]
>>>>>>>>
>>>>>>>> Sent: Friday, March 28, 2008 1:08 PM
>>>>>>>>
>>>>>>>> To: Bowden, Ivor; si-list@xxxxxxxxxxxxx
>>>>>>>>
>>>>>>>> Subject: Re: [SI-LIST] Re: PDS analysis?
>>>>>>>>
>>>>>>>> Ivor
>>>>>>>>
>>>>>>>> I am involved in design since 1993, and have numerous of
>>>>>>>>
> successful
>
>>>>>>> designs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> under my belt. (I know - not very humble...)
>>>>>>>>
>>>>>>>> In one way or another I worked and learned from SI leaders (aka -
>>>>>>>>
>>>>>>>>
>>>>> gurus)
>>>>>
>>>>>
>>>>>>>> like Lee Ritchey, Istvan Novak, Eric Bogatin, Scott McMorrow and
>>>>>>>>
>>>>>>>>
>>>>> Howard
>>>>>
>>>>>
>>>>>>>> Johnson (and others that due to a senior moment I did not mention
>>>>>>>>
>>>>>>>>
>>>>> here -
>>>>>
>>>>>
>>>>>>>> sorry) I gratefully owe my knowledge to them.
>>>>>>>>
>>>>>>>> by the way - all I tried to do is to learn about "real world
>>>>>>>>
>>>>>>>>
>>>> picture".
>>>>
>>>>
>>>>>>>> My greatest lesson is - there are no short cuts and no rule of
>>>>>>>>
>>>>>>>>
>>>>> thumbs. I
>>>>>
>>>>>
>>>>>>>> read daily emails on this list that prove this point over and over
>>>>>>>>
>>>>>>>>
>>>>>>> again.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> And than again I might misunderstand you...
>>>>>>>>
>>>>>>>> If the by 'real world' you refer to 'rules of thumbs' and 'short
>>>>>>>>
>>>>>>>>
>>>>>>> cuts', I
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> will strongly recommend you to shy away from that 'real world'. I
>>>>>>>>
>>>>>>>>
>>>>> really
>>>>>
>>>>>
>>>>>>>> think that any design as hypothetic or rhetorical as it is, needs
>>>>>>>>
>>>>>>>>
>>>>>>> analysis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> (the subject of your email is PDS analysis...).
>>>>>>>>
>>>>>>>> Most of the SI phenomena are frequency depended.
>>>>>>>>
>>>>>>>> You said - * I'm more interested in answers like "you might see a
>>>>>>>>
>>>>>>>>
>>>>>>> waveform
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> of xxx characteristics across the bypass capacitor". *
>>>>>>>>
>>>>>>>> My answer - "you might see a waveform of xxx characteristics
>>>>>>>>
> across
>
>>>>> the
>>>>>
>>>>>
>>>>>>>> bypass capacitor". ;-)
>>>>>>>>
>>>>>>>> How can one attempt giving you any 'ball-park' numbers for a
>>>>>>>>
>>>>>>>>
>>>> frequency
>>>>
>>>>
>>>>>>>> dependent component with out knowing what the frequency parts are?
>>>>>>>>
>>>>>>>> Good luck!
>>>>>>>>
>>>>>>>> Gil
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>
>>>>>>>> From: "Bowden, Ivor" <ibowden@xxxxxxxxxxxxxxxxx>
>>>>>>>>
>>>>>>>> To: <si-list@xxxxxxxxxxxxx>
>>>>>>>>
>>>>>>>> Sent: Friday, March 28, 2008 12:11 PM
>>>>>>>>
>>>>>>>> Subject: [SI-LIST] Re: PDS analysis?
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'd like to thank everyone who replied so far, off and on the
>>>>>>>>>
>>>>>>>>>
>>>> list. I
>>>>
>>>>
>>>>>>>>> emphasize that this is a rhetorical question, it doesn't
>>>>>>>>>
> represent
>
>>>>> any
>>>>>
>>>>>
>>>>>>>>> specific product. I also emphasize that I'm interested more in
>>>>>>>>>
> the
>
>>>>>>> "real
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> world observation" part. Instead of answers like "your power
>>>>>>>>>
> plane
>
>>>>> may
>>>>>
>>>>>
>>>>>>>>> have a resonance at xxx frequency", I'm more interested in
>>>>>>>>>
> answers
>
>>>>> like
>>>>>
>>>>>
>>>>>>>>> "you might see a waveform of xxx characteristics across the
>>>>>>>>>
> bypass
>
>>>>>>>>>
>>>>>>>>> capacitor". Also, this question is more about power distribution
>>>>>>>>>
>>>>>>>>>
>>>> than
>>>>
>>>>
>>>>>>>>> signal return path. All answers appreciated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Ivor
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ________________________________
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: Bowden, Ivor
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Steve Weir
>>>>>> Teraspeed Consulting Group LLC
>>>>>> 121 North River Drive
>>>>>> Narragansett, RI 02882
>>>>>>
>>>>>> California office
>>>>>> (408) 884-3985 Business
>>>>>> (707) 780-1951 Fax
>>>>>>
>>>>>> Main office
>>>>>> (401) 284-1827 Business
>>>>>> (401) 284-1840 Fax
>>>>>>
>>>>>> Oregon office
>>>>>> (503) 430-1065 Business
>>>>>> (503) 430-1285 Fax
>>>>>>
>>>>>> http://www.teraspeed.com <http://www.teraspeed.com/>
>>>>>> This e-mail contains proprietary and confidential intellectual
>>>>>>
>> property
>>
>>>>> of Teraspeed Consulting Group LLC
>>>>>
>>>>>
> ----------------------------------------------------------------------------
>
>>>>> --------------------------
>>>>>
>>>>>
>>>>>> Teraspeed(R) is the registered service mark of Teraspeed Consulting
>>>>>>
>>>>>>
>>>> Group
>>>>
>>>>
>>>>> LLC
>>>>>
>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> 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.net <http://www.si-list.net/>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> --
>>> Steve Weir
>>> Teraspeed Consulting Group LLC
>>> 121 North River Drive
>>> Narragansett, RI 02882
>>>
>>> California office
>>> (408) 884-3985 Business
>>> (707) 780-1951 Fax
>>>
>>> Main office
>>> (401) 284-1827 Business
>>> (401) 284-1840 Fax
>>>
>>> Oregon office
>>> (503) 430-1065 Business
>>> (503) 430-1285 Fax
>>>
>>> http://www.teraspeed.com
>>> This e-mail contains proprietary and confidential intellectual property
>>>
>> of Teraspeed Consulting Group LLC
>>
> ----------------------------------------------------------------------------
>
>> --------------------------
>>
>>> Teraspeed(R) is the registered service mark of Teraspeed Consulting
>>>
> Group
>
>> LLC
>>
>>
>> ------------------------------------------------------------------
>> 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.net
>>
>> 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.net
>>
>> 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.net
>
> 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
>
>
>
>
--
Steve Weir
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
California office
(408) 884-3985 Business
(707) 780-1951 Fax
Main office
(401) 284-1827 Business
(401) 284-1840 Fax
Oregon office
(503) 430-1065 Business
(503) 430-1285 Fax
http://www.teraspeed.com
This e-mail contains proprietary and confidential intellectual property
of Teraspeed Consulting Group LLC
------------------------------------------------------------------------------------------------------
Teraspeed(R) is the registered service mark of Teraspeed Consulting
Group LLC
------------------------------------------------------------------
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.net
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:
