[SI-LIST] Re: DesignCon Papers
- From: Chris Cheng <Chris.Cheng@xxxxxxxxxxxx>
- To:
- Date: Fri, 11 Feb 2005 14:24:49 -0800
Larry,
PDS has been done in your company more than 15 years ago starting with Bill
Gunning and a few analog engineers in the power group. Cetainly since I
designed the first VRM for your company. There may be a few lowend groups
who choose to ignore the discipline but they are by no means the majority.
The fundamental problem you mention is a more serious issue that needs to
get people's attention. Historically the compliance group in certain company
always has the first cut to place and allocate capacitors on PCB. They tend
to be UL engineer with little or no EMC background. They look at the scan of
similar platform and magically decided to assign these rediculously small
value capacitors (1pf,10pf,100pf etc) and carpet bomb those caps in the
prime area near the chips because they see peaks frequencies correspond to
the un-mounted resonance frequencies of these tiny caps in the scan. They
never make an effort to understand if the peaks are due to radiation from
package or poor reference plain return. All those real critical 1-100MHz
decoupling caps got push way out to where they become less effective. There
are groups who know better and fight the decisions and there those who just
let it go and suffer the consequences.
You probably know who I am working with right now and I can tell you we
always joke about the reason why our platform always pass EMC is because we
don't hire EMC engineers.
Of course good EMC engineers are a value, but a bad one can really hurt you.
-----Original Message-----
From: Larry Smith [mailto:Larry.Smith@xxxxxxx]
Sent: Wednesday, February 09, 2005 9:46 AM
To: rsefton@xxxxxxxxxxxxx
Cc: 'Scott McMorrow'; 'silist'
Subject: [SI-LIST] Re: DesignCon Papers
Bob - I also wanted to respond to your note but have been pretty busy
since DesignCon. As Scott has clearly articulated, PDS design is a
matter of robustness and quality. You can often get a system running
in the lab on a shoe string. But it takes more effort to have it run
consistently long term over environmental conditions.
We began to enforce high quality power distributions about 7 years
ago, shortly after I joined Sun. Back in those days, I can remember a
product that crashed every time we ran mpeg2 code and several other
customer applications. The culprit was a high impedance peak at about
100 MHz caused by the choice of decoupling and EMI capacitors. The
peak was 7X target impedance! All it took was a change in the BOM and
we were able to keep the FCC happy and run the customer code, even
though the power supply still greatly exceeded the +-5% specified
tolerance at some frequencies.
I remember measuring another product that had +-17% excursions in
power supply voltage as the processor went through power transients.
We made money all the way to the bank on that product, but I cannot
say that I was proud of it. It worked well but was reported to have
problems with peripheral cards that worked in any other system.
(Somebody shoud fix those cards! :) ) Since it was a successful
product, the same design methodology was used the next time around.
But the next product would not boot up until we dealt with the high
impedance peak between the VRM and ceramic cap frequencies by adding
electrolytic bulk capacitance.
Bulk caps had a terrible reliability reputation at the time and there
was quite a battle with the RAS people. Once they figured out that
the product was not going to boot up until we either added bulk
capacitance or paid for a faster VRM, we finally started making some
sensible trade offs in the power train: VRM, bulk, ceramic, power
planes, etc. This is real system engineering where cost, reliability,
thermal and performance budgets must be managed across several
departmental boundaries, each with their own agendas. I view the
decoupling capacitors as just portion of that big picture.
We have developed a methodology that guarantees that the power supply
voltage will stay within a specified tolerance at all frequencies
given the expected current transients. That guarantee does not come
for free. Careful modeling and CAD simulation is required during the
design process and there may be additional complexity in
manufacturing. I cannot prove that a product will fail if we don't
meet target impedance, in fact, it will probably work (probably being
the key word). In the consumer product world, we have somehow
accepted the occasional "blue screen of death." But in the server
world, this can be front page news, the kind of publicity that kills
the stock price. PDS comes in the category of "you get what you pay
for."
regards,
Larry Smith
Sun Microsystems
Robert Sefton wrote:
>
> Scott -
>
> Thanks for the nVidia story. I'm glad I don't have to design motherboards
> for a living. Extreme performance, extreme cost constraints, and extreme
> operating conditions would definitely make life interesting. Great example
> of where bullet-proof design is required.
>
> And thanks for the other responses to my post. I think what triggered it
> more than anything was the post I saw here a few days ago from Himanshu
> Arora who was looking for IC packages that could handle an 80MHz CMOS
clock.
> No offense intended to Himanshu, but his post was a great example of the
> kind of over-analysis that people can get sucked into if they listen to
> what's discussed here and don't know when and how to apply it. I was also
> venting a little tool envy. I'd love to have access to some of those
> big-buck tools from Ansoft, SiSoft, etc., and big-buck test equipment from
> Agilent, Tek, etc., but so far I've managed to get by without them. I'm
sure
> the day will come when that will no longer be the case, but common sense
and
> a few basic design rules will always go a long way in designing boards
that
> work (motherboards excepted!).
>
> Regards,
> Bob S.
>
> -----Original Message-----
> From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
> Sent: Tuesday, February 08, 2005 7:23 AM
> To: rsefton@xxxxxxxxxxxxx
> Cc: 'silist'
> Subject: Re: [SI-LIST] Re: DesignCon Papers
>
> Robert,
>
> Back many years ago when I was an employee of a large semiconductor
company
> that also manufactures desktop computer motherboards and server
> motherboards, I was asked by management why our designs always took more
> layers, more signal integrity design time, more termination, and more
> capacitors than the groups in another section of the building that
designed
> desktop products. The answer was simple: "You want it to work, don't
you?"
>
> Of course, the answer that inevitably came back was, "Are you saying that
> our desktop products don't work? How can that be since we ship millions
of
> them a year." Well the answer to this was quite simple.
> Most products are not stressed to the extremely, but server platforms
often
> are, at maximum bandwidth and continuous throughput 24/7. As one result
of
> this internal controversy, we decided to place a few standard desktop
> platforms into our fairly new server validation lab and run them under
> stressed conditions. Generally it took only a few hours, maybe a day,
> before we were able to produce the "blue screen of death" at room
> temperature. Our servers, on the other hand, would never blue screen,
even
> under full load while sitting in the temperature chamber cycling for an
> entire year.
>
> A few years ago on some of the gaming websites there was an uproar about a
> particular nVidia graphics card driver when used in Via chipset
> motherboards. When the driver was updated a large number of systems
> crashed. Fingers pointed back and forth. Eventually through a bit of
> careful reading of the tea leaves, one could determine what really
happened.
> nVidia had upgraded their driver for higher performance using AGP
> pipelining. On other than Via platforms this worked just fine, but on
some
> subset of poorly designed Via platforms this would cause significant
> power/ground bounce in the chipset, subsequently causing failures.
>
> The moral of the story is that unless you do the appropriate analysis,
> simulations or stress tests, you may never know whether or not a
particular
> system fails PI or SI, until it is too late.
>
> regards,
>
> scott
>
> Scott McMorrow
> Teraspeed Consulting Group LLC
> 121 North River Drive
> Narragansett, RI 02882
> (401) 284-1827 Business
> (401) 284-1840 Fax
>
> http://www.teraspeed.com
>
> Teraspeed is the registered service mark of Teraspeed Consulting Group LLC
>
> Robert Sefton wrote:
>
> >Dear list, especially the power integrity experts and pioneers at Sun,
> >Teraspeed, et al -
> >
> >I've been a list member for more than five years now - rarely
contributing,
> >but religiously monitoring the dialogue. In the 15+ years I've been in
this
> >business I've been responsible for or at least been involved in dozens of
> >large PCB designs. Over all of those designs I've seen maybe 4-5 signal
> >integrity problems (where operation was affected), but I have never, ever
> >seen a power integrity problem. Virtually all of these designs have
> included
> >at least one FPGA, a processor, and SRAM and/or SDRAM. And several have
> >included FPGAs plus ICs dissipating 20+ watts with SPI-4.2, SerDes, DDR,
> and
> >other high speed interfaces.
> >
> >I'm a consultant, and I primarily work with small start-up companies that
> >have no budget and no inclination for SI tools. (They'll spend many
$100Ks
> >or even $1Ms on IC tools, but won't spend a dime on PCB tools other than
> >schematic entry and layout.) Probably half of the boards I've been
involved
> >with are prototype builds where schedule is paramount. With these I can
> >rarely exert enough control to get the layout exactly like I want, and
> often
> >the boards go out with serious reservations on my part. I always try to
> >observe the prevailing guidelines expressed here and elsewhere, but I've
> >seen boards go out with barely any copper left in the "planes" beneath
> large
> >power-hungry BGA parts due to poor via placement and large anti-pads. I
> >recently saw a board come back where a large Virtex-II FPGA would not
> >configure. It was traced down to the fact that the core power islands
under
> >the BGA were were so sliced up that they were not connected to the core
> >power VRM. The swiss cheese core power "plane" was re-connected to the
> +1.5V
> >supply with a 4" blue wire through one via on the bottom of the board.
> Guess
> >what - it worked like a champ.
> >
> >I'm not trying to be an ass here (I'll leave that to Chris C. :`)), but
I'm
> >really beginning to question the need for some or even most of the
> >theoretical PI analyses espoused here. I can't believe that luck has made
> >all of my boards work over the years, despite not having access to SI or
PI
> >tools of any kind. What I really think is going on is that there are very
> >few designs that need the ultra-low-mOhm, highly-simulated, and
> >highly-engineered power distribution methodologies that have been
discussed
> >here recently. I'll be damned if I can make a board NOT work due to how
> >power is distributed.
> >
> >In the PI discussions on the SI-list I almost never hear power/current
> >levels discussed. I'm sure that Sun cranks out boards with processor ICs
or
> >modules that draw 10s of Amps of core power, where detailed analysis of
the
> >PDS is critical. But what about us mortals who design run-of-the-mill
FPGA
> +
> >PowerPC + MAC, etc., type of boards? As I said, despite some brutally bad
> >layouts, I have NEVER had a problem related to power distribution.
> >
> >I have two requests to the list:
> >
> >1. When espousing SI and/or PI practices, please be as specific as
possible
> >about when these practices are warranted, and more importantly, when they
> >are not.
> >
> >2. I would LOVE to hear more detailed reports from the trenches (i.e. war
> >stories) about SI and PI problems that were actually seen on real boards
> >(not in simulation), and how they were fixed. This is something that is
> >almost NEVER discussed amongst the regulars here.
> >
> >I have a strong sense that non-experts (like me) who monitor this list
are
> >buying into methods that may not apply to their designs and are therefore
> >over-engineering (one of my least favorite things - I prefer to
> >under-engineer and get away with it).
> >
> >All comments are welcome.
> >
> >Best regards,
> >Bob Sefton
> >
> >
> >
> >------------------------------------------------------------------
> >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 FAQ wiki page is located at:
> > http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> >
> >List technical documents are available at:
> > http://www.si-list.org
> >
> >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 FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
> List technical documents are available at:
> http://www.si-list.org
>
> 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 FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
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 FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
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:
