[SI-LIST] Re: PDS analysis?
- From: <art_porter@xxxxxxxxxxx>
- To: <weirsi@xxxxxxxxxx>, <Dan.Smith@xxxxxxxxx>
- Date: Tue, 1 Apr 2008 07:31:50 -0600
From an old metrology guy: It would have been really interesting to ask =
the vendor how they suggest you measure the 40 uV p-p! And where - =
inside a Faraday cage room?=20
Art Porter
Agilent Technologies
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] =
On Behalf Of steve weir
Sent: Monday, March 31, 2008 10:41 PM
To: Dan Smith
Cc: Lee Ritchey; Chris Cheng; Ivor Bowden; Gil Simsic [IEEE]; =
si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: PDS analysis?
Dan that's an interesting story. Under different circumstances it would =
be funny.=20
If someone has a different experience with the same or different vendors =
than I do, it is no skin off my nose. I know of one company ( not an=20
FPGA vendor ) that routinely screwed over its customers. Every two=20
years or so salespeople would show up with pledges that management had=20
turned a new leaf. Anyone taken in by their lies promptly got treated=20
to the same stunts, like unannounced spec changes, buried errata, etc. =20
People learned to steer clear of that company.
40uVpp is a truly amazing demand for noise. I don't suppose the=20
geniuses who concocted that value gave you any hint as to where it was=20
to be measured, and under what conditions did they? How many people=20
laughed them out of the meeting when they made such a crazy demand?
If any vendor shows up with absurd demands or is unresponsive, my=20
opinion is that is time to run the problems up the ladder. Vendors=20
respond to revenue. If they behave badly someone with enough juice to=20
be taken seriously needs to let them know that is a sure fire way to=20
guarantee they won't be getting new design wins, and are at risk of=20
losing what they have. If the BS is the result of a rogue manager the=20
vendor will fix it. If it's policy set by top management, IMO it's time =
to dump the vendor.
Regards,
Steve.
Dan Smith wrote:
> One comment to "surprise" Steve....
>
> The following is absolutely true....
>
> I have dealt with a vendor that has absolutely disappointed me =
technically in the past and I was baffled in their responses to try and =
solve a problem. Later (at a different company I worked for) I ran into =
that vendor again and they recognized me. They took a proactive =
approach and profusely apologized for the behavior of their company in =
regards to the prior relationship I had with them. I was told that they =
had been trumped by their management and told to lie about an exiting =
problem with their design they were selling to customers. In their =
words, they said "We were in the meeting (e.g. the meeting was referring =
to the one I was in in this prior company) and wanted to say what we =
knew was technically correct but could not due to a directive from out =
management team".
>
> Steve, this is NOT an attack against you - I would like to say =
something to all of us fellow engineers. Do not let a vendor put their =
politics above their technical expertise. I have witnessed this in the =
past and this is UGLY! In my case, due to this politics I heard words =
like "40uv is the noise tolerance you need to design to on your power =
supply pins". Read that again.... 40uv!!!!
>
> To all you lawyers out there.... GET THE HELL OUT OF OUR BUSINESS! =
Let us engineers debate and solve problems with a technical mindset and =
facts. Sure, we still won't all agree but it is way beyond anything =
that you can provide to a talented design team.
>
> Dan
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx =
[mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of steve weir
> Sent: Monday, March 31, 2008 9:43 AM
> To: Lee Ritchey
> Cc: Chris Cheng; Ivor Bowden; Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: PDS analysis?
>
> Lee I would have to go back and reread the piece. I do believe the
> manager was quoted as saying something like "we had a lot of noise on
> the PCB". But Alzheimer's and general dementia will take me =
eventually
> if they haven't already! The story you tell is very different than =
what
> has been represented to me. Since I did not see the design first hand =
I
> am at a disadvantage to sort out who's representations are the most
> faithful, especially with respect to how a vendor treated a given =
design
> engineer. I would however find it very surprising that in the very
> competitive world of FPGAs to find that any of the big players were
> abusive to customers. My experience with all of the big players is =
that
> they try very hard to help their customers succeed.
>
> Given a fixed function ASIC the user is stuck with what they get. =
With
> a programmable part the situation is different. There are definitely
> means to reduce noise in a a programmable part package that require
> trade-offs at the PCB and system design level. Whether there are =
enough
> avenues available to achieve a desired result with a given package is =
a
> matter of design specifics.
>
> Ferrites have their places. They can and are often improperly used
> which is unfortunate. The paper you refer to is from DesignCon 2007. =
I
> used ferrites to full advantage. They were engineered properly and
> consequently only a very few were needed. They definitely did the job
> they were intended to.
>
> Best Regards,
>
>
> Steve.
>
> Lee Ritchey wrote:
> =20
>> 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.
>>
>>
>>
>> =20
>>> [Original Message]
>>> From: steve weir <weirsi@xxxxxxxxxx>
>>> To: <leeritchey@xxxxxxxxxxxxx>
>>> Cc: Chris Cheng <Chris.Cheng@xxxxxxxx>; Ivor Bowden
>>>
>>> =20
>> <ibowden@xxxxxxxxxxxxxxxxx>; Gil Simsic [IEEE] <gilsimsic@xxxxxxxx>;
>> <si-list@xxxxxxxxxxxxx>
>>
>> =20
>>> 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:
>>>
>>> =20
>>>> Chris,
>>>>
>>>> A while back we saw this in spades with a certain FPGA vendor who
>>>> stonewalled its customers when their products failed.
>>>>
>>>>
>>>>
>>>>
>>>> =20
>>>>> [Original Message]
>>>>> From: Chris Cheng <Chris.Cheng@xxxxxxxx>
>>>>> To: <leeritchey@xxxxxxxxxxxxx>; Steve Weir <weirsi@xxxxxxxxxx>
>>>>> Cc: Ivor Bowden <ibowden@xxxxxxxxxxxxxxxxx>; Gil Simsic [IEEE]
>>>>>
>>>>>
>>>>> =20
>>>> <gilsimsic@xxxxxxxx>; <si-list@xxxxxxxxxxxxx>
>>>>
>>>>
>>>> =20
>>>>> 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
>>>>>
>>>>>
>>>>> =20
>>>> can have hundreds of MHz of noise. If it is large enough on die, =
you
>>>>
>>>> =20
>> will
>>
>> =20
>>>> have fractions of the noise spilling out.
>>>>
>>>>
>>>> =20
>>>>> Sure, you can put your plane capacitance or exotic caps to make =
the
>>>>>
>>>>>
>>>>> =20
>>>> external power flat like a straight line without any ripple. But =
does
>>>>
>>>> =20
>> it do
>>
>> =20
>>>> a single thing to damp down your core power noise at your die ? You =
can
>>>>
>>>> =20
>> put
>>
>> =20
>>>> 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
>>>>
>>>> =20
>> noise.
>>
>> =20
>>>> =20
>>>>> It is the same as seeing a leaking diaper and just wipe the =
outside
>>>>>
>>>>> =20
>> clean
>>
>> =20
>>>>> =20
>>>> or put an extra one to cover it, I guarantee it will not have any =
effect
>>>> for the end user.
>>>>
>>>>
>>>> =20
>>>>> ________________________________
>>>>>
>>>>> 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
>>>>>
>>>>> =20
>> hundreds of
>>
>> =20
>>>>> MHz. Looks like the on die and on package capacitance was not =
done
>>>>>
>>>>> =20
>> well.
>>
>> =20
>>>>> Fixed with a little more plane capacitance.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> =20
>>>>>> [Original Message]
>>>>>> From: steve weir <weirsi@xxxxxxxxxx>
>>>>>> To: Chris Cheng <Chris.Cheng@xxxxxxxx>
>>>>>> Cc: Bowden, Ivor <ibowden@xxxxxxxxxxxxxxxxx>; Gil Simsic [IEEE]
>>>>>>
>>>>>>
>>>>>> =20
>>>>> <gilsimsic@xxxxxxxx>; <si-list@xxxxxxxxxxxxx>
>>>>>
>>>>>
>>>>> =20
>>>>>> 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
>>>>>>
>>>>>> =20
>> hunting
>>
>> =20
>>>>>> 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
>>>>>>
>>>>>> =20
>> for
>>
>> =20
>>>>>> 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
>>>>>>
>>>>>> =20
>> is
>>
>> =20
>>>>>> the starting point for a competent design.
>>>>>>
>>>>>> For the two rules, personally I like coefficients for any =
problem.
>>>>>>
>>>>>> =20
>> Over
>>
>> =20
>>>>>> 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
>>>>>>
>>>>>> =20
>> demonstrably
>>
>> =20
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> =20
>>>> PDN."
>>>>
>>>>
>>>> =20
>>>>>> A parting comment on using a ton of 100nF caps. It used to be =
that
>>>>>>
>>>>>> =20
>> this
>>
>> =20
>>>>>> could work rather well when the overall density of the capacitors
>>>>>>
>>>>>> =20
>> pushed
>>
>> =20
>>>>>> the PRF between the bypass network and the planes out beyond the
>>>>>>
>>>>>> =20
>> spectra
>>
>> =20
>>>>>> of both the bit and edge rates. Nowadays that is just a very
>>>>>>
>>>>>> =20
>> expensive
>>
>> =20
>>>>>> if not just impossible approach.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>>
>>>>>> Steve.
>>>>>>
>>>>>> Chris Cheng wrote:
>>>>>>
>>>>>>
>>>>>> =20
>>>>>>> My first disclaimer will be :
>>>>>>> YMMV
>>>>>>> my second will be :
>>>>>>> I still don't have the balls to do single value highspeed =
ceramic
>>>>>>>
>>>>>>> =20
>> caps
>>
>> =20
>>>>>>> but I do think .1u is a good starting point to go up to 1u and =
down
>>>>>>>
>>>>>>> =20
>> to
>>
>> =20
>>>>>>> .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
>>>>>>>
>>>>>>> =20
>> "external
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> that
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> bands.
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>> operation
>>>>
>>>>
>>>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> up
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> package
>>
>> =20
>>>>>>> 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 =
?
>>>>>>>
>>>>>>> =20
>> Back
>>
>> =20
>>>>>>> in the days when boards are big and performance and financial
>>>>>>> budget are loose, we chose to let whoever speculate whatever is
>>>>>>>
>>>>>>> =20
>> needed
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> for
>>
>> =20
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>> =
------------------------------------------------------------------------
>>>>
>>>>
>>>> =20
>>>>>>> *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
>>>>>>>
>>>>>>> =20
>> particular
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> was
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> bypass
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> off
>>
>> =20
>>>>>>> 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,
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>> and
>>>>
>>>>
>>>> =20
>>>>>>> books that are out there. But, I am not sure where you are =
going
>>>>>>>
>>>>>>> =20
>> with
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> to
>>
>> =20
>>>>>>> undefined results. If you want predictable results then: =
Define the
>>>>>>>
>>>>>>> requirements and engineer to them.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We can characterize components to determine their actual power
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>> delivery
>>>>
>>>>
>>>> =20
>>>>>>> requirements. Once known we can easily demonstrate failures =
that
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>> result
>>>>
>>>>
>>>> =20
>>>>>>> when we don't meet those requirements. It is also easy to
>>>>>>>
>>>>>>> =20
>> demonstrate
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> the
>>
>> =20
>>>>>>> plane cavity is 4mil FR406 on layers 2/3, the bypass to cavity =
PRF
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>> will
>>>>
>>>>
>>>> =20
>>>>>>> land around 330MHz depending on how you do your vias. If the =
planes
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>> are
>>>>
>>>>
>>>> =20
>>>>>>> deeper in the board that frequency will just go down. Then get
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>> yourself
>>>>
>>>>
>>>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> 1-0-1-0
>>
>> =20
>>>>>>> sequence while you monitor the power supply planes with a decent
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>> scope.
>>>>
>>>>
>>>> =20
>>>>>>> Just step frequency until the bit rate / 2 excites the lowest
>>>>>>>
>>>>>>> =20
>> parallel
>>
>> =20
>>>>>>> resonance in the power system. After that experiment see if =
your
>>>>>>>
>>>>>>> feelings about what works fine are still the same.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bowden, Ivor wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>>>>>> Hi Gil,
>>>>>>>>
>>>>>>>> Thanks for sharing.
>>>>>>>>
>>>>>>>> By "real world" I do not mean rules of thumb and shortcuts, I =
mean
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> bypass
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>> =20
>> vias
>>
>> =20
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>>>> designs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>>>>>> under my belt. (I know - not very humble...)
>>>>>>>>
>>>>>>>> In one way or another I worked and learned from SI leaders (aka =
-
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>> gurus)
>>>>>
>>>>>
>>>>> =20
>>>>>>>> like Lee Ritchey, Istvan Novak, Eric Bogatin, Scott McMorrow =
and
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>> Howard
>>>>>
>>>>>
>>>>> =20
>>>>>>>> Johnson (and others that due to a senior moment I did not =
mention
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>> here -
>>>>>
>>>>>
>>>>> =20
>>>>>>>> sorry) I gratefully owe my knowledge to them.
>>>>>>>>
>>>>>>>> by the way - all I tried to do is to learn about "real world
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>> picture".
>>>>
>>>>
>>>> =20
>>>>>>>> My greatest lesson is - there are no short cuts and no rule of
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>> thumbs. I
>>>>>
>>>>>
>>>>> =20
>>>>>>>> read daily emails on this list that prove this point over and =
over
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>>>> again.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>>>>>> And than again I might misunderstand you...
>>>>>>>>
>>>>>>>> If the by 'real world' you refer to 'rules of thumbs' and =
'short
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>>>> cuts', I
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>>>>>> will strongly recommend you to shy away from that 'real world'. =
I
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>> really
>>>>>
>>>>>
>>>>> =20
>>>>>>>> think that any design as hypothetic or rhetorical as it is, =
needs
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>>>> analysis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>>>>>> (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
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>>>> waveform
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>>>>>> of xxx characteristics across the bypass capacitor". *
>>>>>>>>
>>>>>>>> My answer - "you might see a waveform of xxx characteristics =
across
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>> the
>>>>>
>>>>>
>>>>> =20
>>>>>>>> bypass capacitor". ;-)
>>>>>>>>
>>>>>>>> How can one attempt giving you any 'ball-park' numbers for a
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>> frequency
>>>>
>>>>
>>>> =20
>>>>>>>> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>> =20
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'd like to thank everyone who replied so far, off and on the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> =20
>>>> list. I
>>>>
>>>>
>>>> =20
>>>>>>>>> emphasize that this is a rhetorical question, it doesn't =
represent
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> =20
>>>>> any
>>>>>
>>>>>
>>>>> =20
>>>>>>>>> specific product. I also emphasize that I'm interested more in =
the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> =20
>>>>>>> "real
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =20
>>>>>>>>> world observation" part. Instead of answers like "your power =
plane
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> =20
>>>>> may
>>>>>
>>>>>
>>>>> =20
>>>>>>>>> have a resonance at xxx frequency", I'm more interested in =
answers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> =20
>>>>> like
>>>>>
>>>>>
>>>>> =20
>>>>>>>>> "you might see a waveform of xxx characteristics across the =
bypass
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> capacitor". Also, this question is more about power =
distribution
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> =20
>>>> than
>>>>
>>>>
>>>> =20
>>>>>>>>> signal return path. All answers appreciated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Ivor
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ________________________________
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: Bowden, Ivor
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> =20
>>>>>>> =20
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>> =20
>> property
>>
>> =20
>>>>>> =20
>>>>> of Teraspeed Consulting Group LLC
>>>>>
>>>>>
>>>>> =20
>> =
-------------------------------------------------------------------------=
---
>>
>> =20
>>>> =20
>>>>> --------------------------
>>>>>
>>>>>
>>>>> =20
>>>>>> Teraspeed(R) is the registered service mark of Teraspeed =
Consulting
>>>>>>
>>>>>>
>>>>>> =20
>>>> Group
>>>>
>>>>
>>>> =20
>>>>> LLC
>>>>>
>>>>>
>>>>> =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.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
>>>>>>
>>>>>>
>>>>>>
>>>>>> =20
>>>>> =20
>>>>
>>>> =20
>>> --
>>> 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
>>>
>>> =20
>> of Teraspeed Consulting Group LLC
>>
>> =
-------------------------------------------------------------------------=
---
>> --------------------------
>>
>> =20
>>> Teraspeed(R) is the registered service mark of Teraspeed Consulting =
Group
>>>
>>> =20
>> 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
>>
>>
>>
>>
>> =20
>
>
> --
> 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
>
>
>
> =20
--=20
Steve Weir
Teraspeed Consulting Group LLC=20
121 North River Drive=20
Narragansett, RI 02882=20
California office
(408) 884-3985 Business
(707) 780-1951 Fax
Main office
(401) 284-1827 Business=20
(401) 284-1840 Fax=20
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: =20
//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.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:
