[SI-LIST] Re: PDS analysis?

When all this unfolded I had four clients suffering from the same problem. 
One of them was a start up that failed because of it.


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