[SI-LIST] Re: Article discussion on bad packages
- From: steve weir <weirsp@xxxxxxxxxx>
- To: leeritchey@xxxxxxxxxxxxx, "Dan Bostan" <dbostan@xxxxxxxxx>, vrbanacm@xxxxxxxxxx, Aubrey_Sparkman@xxxxxxxx
- Date: Sat, 25 Dec 2004 15:15:32 -0800
Lee, there are two very important issues here with regard to bounce
conclusions alone:
1) Mr. Hecker described the bounce at the board:
"Mahi was designing what Hecker describes as a "cutting-edge application"
involving 3.125-GHz backplane links. The design called for FPGAs with
integrated serdes capability to be used as serial links. But test data
showed severe ground bounce and power bounce on the board, as well as
performance problems related to the operation of the serdes links in the
system environment."
I assume Mr. Goering took care to quote Mr. Hecker accurately. You
acknowledge your role in the piece. So are you now stating the quote is
wrong? If so, what the heck is going on here with these articles? If that
quote is wrong, what else is wrong in those pieces?
2) Even when the board appears quiet, it is easy to mistake excessive plane
spreading, and/or via attachment inductance for package inductance.
As I stated a complete impedance budget for those things that we can
control, which is all elements up to the package attachment is
imperative. And I fully stand by my statement that this is the system
engineer's responsibility alone.
The switching current that will stand on top of that impedance is something
that we can characterize. In an FPGA application we, not the IC
manufacturer have the final control on whether the combined switching
current and PDS impedance are compatible with device requirements. What a
suboptimal package does is limit the tolerable current. The system
engineer adopting the FPGA must marry the finite capabilities of the FPGA
to an appropriate environment and application. This problem is as old as
switching, even with relays.
I suggest that we maintain decorum here. If you have facts that render my
statements and/or conclusions incorrect, then please by all means share
them, and we will all be educated. I fully accept my own limitations, and
despite the care that I try to use when posting, the possibility always
exists at anytime that I have missed information, and/or concluded in
error. If shown to be in error, I will happily be corrected and apologize
for any errors. But be assured, I make all my posts in good faith. I ask
that you concentrate on advancing the conversation with verifiable facts on
this important subject, and leave unjustified attacks on my character at home.
Regards,
Steve.
At 11:18 AM 12/25/2004 -0800, Lee Ritchey wrote:
>True, bounce on the PCB is a PCB problem and is the responsibility of the
>PCB engineer. Bounce in the package is not a PCB problem and cannot be
>fixed by the PCB engineer. This problem is the responsibility of the IC
>manufacturer. All of the problems cited in the article were demonstrated
>to be packaging problems and not PCB problems. That is the motivation for
>the article and more to follow.
>
>To place the responsibility for this problem on the PCB engineer is
>disingenuous, if not downright dishonest.
>
>Lee W. Ritchey
>Speeding Edge
>P. O. Box 2194
>Glen Ellen, CA 95442
>Phone- 707-568-3983
>FAX- 707-568-3504
>
>I just used the energy it took to be angry to write some blues.
>Count Basie
>
>
> > [Original Message]
> > From: Dan Bostan <dbostan@xxxxxxxxx>
> > To: <weirsp@xxxxxxxxxx>; <vrbanacm@xxxxxxxxxx>; <Aubrey_Sparkman@xxxxxxxx>
> > Cc: <si-list@xxxxxxxxxxxxx>
> > Date: 12/24/2004 2:46:49 PM
> > Subject: [SI-LIST] Re: Article discussion on bad packages
> >
> > Very well said, Steve.
> > I think the key point you make is : "Bounce observable
> > on the PCB is a PCB problem not a package problem".
> > /dan
> >
> > --- steve weir <weirsp@xxxxxxxxxx> wrote:
> >
> > > Aubrey, Mike,
> > >
> > > In response to that EET article, I sent the
> > > following letter to Mr.
> > > Goering. The "Reader's Digest" version is that:
> > >
> > > 1. The PCB can kill the system just as easily as the
> > > IC. Both are part of
> > > the package.
> > > 2. The OEM is responsible for obtaining enough data
> > > to design a system, as
> > > opposed to creating a netlist and praying.
> > > 3. Even where documentation is lacking,
> > > characterization can yield
> > > sufficient data to design reliably.
> > > 4. Bounce observable on the PCB is a PCB problem not
> > > a package problem.
> > > 5. There are lots of misconceptions out there about
> > > power distribution and
> > > packaging.
> > > 6. Package limitations in the ICs, at the board
> > > level and in the system are
> > > a fact of life. Making it all work is what we are
> > > paid to do.
> > > 7. This year's DesignCon has about a dozen papers (
> > > shameless
> > > plug: including two from Teraspeed ) and
> > > presentations on topics that
> > > touch on the subject matter of the Dec. 18 EET
> > > article.
> > >
> > > I hope everyone has a happy and safe holiday.
> > >
> > > Best regards to all,
> > >
> > >
> > > Steve.
> > >
> > > ====
> > > (c) 2004 Teraspeed Consulting Group, LLC
> > >
> > > Dear Mr. Goering,
> > >
> > > I read with great interest, Monday's piece: "When
> > > bad packages kill good
> > > pc boards". I hope someday you will run a
> > > complementary piece perhaps
> > > titled "When
> > > bad board designs undermine serviceable packages".
> > >
> > > To blame excessive system noise on the IC package
> > > without examining how the
> > > actual noise budget was developed and verified, I
> > > find a bit like blaming only
> > > the girl for an unwanted pregnancy. It is the OEM's
> > > ultimate responsibility to
> > > engineer their system properly. This is a theme that
> > > Lee Ritchey stumps on in
> > > his book, "Right the First Time". In his excellent
> > > DesignCon 2004 paper
> > > "System Level
> > > Power Integrity Analysis and Correlation for
> > > Multi-gigabit Designs" Dr.
> > > Ralf Schmitt
> > > and his fellow Rambus authors made plain that system
> > > level power integrity
> > > is the
> > > sum of the parts from the IC core all the way out
> > > through the PCB structure to
> > > the voltage regulator module. If a system is built
> > > without the requisite
> > > analysis, then why
> > > is anyone surprised if it does not work properly?
> > >
> > > OEMs who wish to be successful must develop the
> > > internal skills, or import
> > > external expertise to engineer their systems by
> > > design, and not happenstance. I
> > > find little surprise that various FPGA customers who
> > > have spent the
> > > resources to
> > > develop such expertise jealously guard it, and do
> > > not wish to share it with
> > > competitors.
> > >
> > > Similarly, why would anyone expect an application
> > > note to circumvent the need
> > > for engineering? An appnote is a place to get
> > > started, not the end-point. A
> > > good
> > > appnote IMO demonstrates a principle and provides a
> > > distilled example. Why is
> > > such cookbook simplification reviled instead of
> > > acknowledged for the
> > > limitations
> > > it necessarily carries? As with the hilarious
> > > Douglas Adams books, the trouble
> > > isn't understanding the answer, it is understanding
> > > the question.
> > >
> > > If an OEM lacks the internal resources to evaluate
> > > feasibility, and then design
> > > a demanding physical system themselves, that
> > > critical task should be
> > > out-sourced
> > > to appropriate expertise. That expertise is
> > > available. In the meantime,
> > > education is available including from colleges,
> > > consultants, and even vendors
> > > such as Xilinx. To wit for a paltry $20. one can
> > > purchase the DVD set just
> > > released featuring Dr. Howard Johnson's discussion
> > > of the care and feeding of
> > > MGTs. Xilinx also offers an SI course, and Altera
> > > will be presenting at
> > > DesignCon 2005 on SSO.
> > >
> > > We have many people in this community, including the
> > > many contributors to the
> > > SI-List from Sun Microsystems: Larry Smith, Istvan
> > > Novak, Ray Anderson (
> > > recently snagged by Xilinx ), who for years have all
> > > been beating the drum on
> > > the importance of three things to PDS quality:
> > > Inductance, inductance and
> > > inductance. Even so, misconceptions, and failure to
> > > do necessary homework
> > > frequently get people into trouble. One subject that
> > > I still see regularly
> > > trip-up even "experts" is a proper accounting of
> > > device via attachment and
> > > plane
> > > spreading inductance as elements of the overall
> > > bypass impedance budget.
> > > Overlooking these in high performance systems can
> > > lead to horribly wrong
> > > conclusions and encourage error prone measurements.
> > > Yet we see repeated
> > > statements and even books that assert demonstrably
> > > wrong claims in both
> > > theory and practice. Given the description offered
> > > in today's article that
> > > featured Mahi's difficulties I can but wonder if
> > > this common
> > > misunderstanding is
> > > not at the root of the nine-month $20 million dollar
> > > fiasco reported.
> > >
> > > The article quotes as an example a reported failure
> > > at Mahi Networks, described
> > > as:
> > >
> > > "Mahi was designing what Hecker describes as a
> > > "cutting-edge application"
> > > involving 3.125-GHz backplane links. The design
> > > called for FPGAs with
> > > integrated
> > > serdes capability to be used as serial links. But
> > > test data showed severe
> > > ground
> > > bounce and power bounce on the board, as well as
> > > performance problems
> > > related to
> > > the operation of the serdes links in the system
> > > environment."
> > >
> > > Assuming the quote is accurate, how on earth does
> > > any engineer blame board
> > > level
> > > bounce on the IC package? Were the package the
> > > culprit here, noise at IC
> > > package
> > > attachment would be nominal while the noise at quiet
> > > IC I/Os or in the core
> > > would be problematic.
> > >
> > > For board level PDS stability, the only two
> > > variables at our disposal are
> > > the IC
> > > application current and the board impedance. The
> > > former may be determined by
> > > test fixturing, the latter readily synthesized by
> > > design. So how could anyone
> > > who did their engineering homework end-up with
> > > unexpected excessive board level
> > > bounce? How could such bounce possibly be the fault
> > > of the package as
> > > opposed to
> > > the system engineer? Placing a high performance IC
> > > in an inadequate PCB
> > > environment is a lot like putting Yugo tires on a
> > > Formula One race car. Why is
> > > the tragic result either a surprise, or blamed on
> > > the car?
> > >
> > > There are many misconceptions out there, and none of
> > > them help engineer working
> > > systems. Unfortunately, Monday's piece IMO helped
> > > propagate some wive's
> > > tales. I
> > > about fell out of my chair when I saw that article
> > > apparently
> > === message truncated ===
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Jazz up your holiday email with celebrity designs. Learn more.
> > http://celebrity.mail.yahoo.com
> > ------------------------------------------------------------------
> > 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:
