[SI-LIST] Re: PDS analysis?
- From: "Chris Cheng" <Chris.Cheng@xxxxxxxx>
- To: <leeritchey@xxxxxxxxxxxxx>, "Ken Cantrell" <Ken.Cantrell@xxxxxxxxxxxxxxxx>, "Steve Weir" <weirsi@xxxxxxxxxx>
- Date: Wed, 2 Apr 2008 11:57:17 -0700
Lee,
I was saying then and I will say it again now. If the problem is SSO and =
your client is using just an IBIS model or worst don't even simulate, =
what do you expect ? I have no idea how bad the package is, but if your =
clients just take a simple IBIS model and expect everything to work, =
they are just as guilty as the ones who gave them a bad package. You are =
just a cry baby if you have not done your own part. Why not demand a =
model that has SSO ? Why not simulate your SSO performance BEFORE you =
commit your design ? And if you can't do it yourself, hire someone to do =
it for you ahead of time. When SHTF and then you try to address the =
problem, it's too late. They deserve to go down. This may be harsh word =
but this is a competitive market and Darwinism is real.
I don't believe there is such things as generic package. Any package =
substrate and the die attached to it performs differently when the I/O =
swing, edge rate, number of I/O switching AND most importantly the =
external topology changes. How could one just blindly follow a design =
guide without simulation ? How could one discover SSO problem with a =
simple I-V curve IBIS model?
Again, this ties in to the model correlation thread. We've been letting =
the model supplier get away with lousy IBIS model that can't do its job =
for a long time. It is time to demand and expect the right models. =
Again, I am not saying IBIS as a spec is inferior, I am saying the model =
that only address the basic I-V curve is.
-----Original Message-----
From: Lee Ritchey [mailto:leeritchey@xxxxxxxxxxxxx]
Sent: Wednesday, April 02, 2008 9:01 AM
To: Ken Cantrell; Steve Weir
Cc: Chris Cheng; Ivor Bowden; Gil Simsic [IEEE]; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: PDS analysis?
When all this unfolded I had four clients suffering from the same =
problem.=20
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.=20
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.=20
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: =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:
