[SI-LIST] Re: PDS analysis?
- From: Dan Smith <Dan.Smith@xxxxxxxxx>
- To: steve weir <weirsi@xxxxxxxxxx>, Lee Ritchey <leeritchey@xxxxxxxxxxxxx>
- Date: Mon, 31 Mar 2008 20:46:00 -0700
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 apol=
ogized for the behavior of their company in regards to the prior relationsh=
ip I had with them. I was told that they had been trumped by their managem=
ent and told to lie about an exiting problem with their design they were se=
lling 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 d=
irective 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 U=
GLY! In my case, due to this politics I heard words like "40uv is the nois=
e tolerance you need to design to on your power supply pins". Read that ag=
ain.... 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. Su=
re, we still won't all agree but it is way beyond anything that you can pro=
vide 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:
> 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 wit=
h
> the same data bus were placed on the same PCB, ala Howard Johnson's famou=
s
> test PCB, and the results were very much like those that Howard got. It w=
as
> this final test that convinced those who needed convincing that the packa=
ge
> 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 memorie=
s
> about how this engineer was treated by the vendor. The experience was ba=
d
> 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 ferri=
te
> beads to the power leads of the serdes. That gave rise to another ad bli=
tz
> 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 tes=
ts
> 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 pi=
n
>>> 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 effec=
t
>>> 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 actuall=
y
>>>>>> 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 sophisticate=
d
>>>>>> 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 pi=
n
>>>>>> 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 i=
f
>>>>>> 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 w=
e
>>>>>> 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 typica=
l
>>>>>> design practices.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I know that PDS analysis tools are not as ubiquitous as simulation /
>>>>>> crosstalk tools, and many companies, especially smaller ones, tend t=
o
>>>>>> 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. Fo=
r
>>>>>> 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 neede=
d
>>>>>> if proper rules are followed", generally backed up with statistics o=
f
>>>>>> successful boards not PDS analyzed, while the on list replies tend t=
o
>>>>>> 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 yo=
u
>>>>>>
>>>>>> 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 th=
e
>>>>>>
>>>>>> 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 fo=
r
>>>>>> 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 powe=
r
>>>>>> 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 scop=
e
>>>>>> (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 Grou=
p
>>
> 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
>
>
>
>
--
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 L=
LC
------------------------------------------------------------------
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
Other related posts:
