[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:
http://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:     
                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: