[SI-LIST] Re: Article discussion on bad packages
- From: Dan Bostan <dbostan@xxxxxxxxx>
- To: weirsp@xxxxxxxxxx, vrbanacm@xxxxxxxxxx, Aubrey_Sparkman@xxxxxxxx
- Date: Fri, 24 Dec 2004 14:43:53 -0800 (PST)
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
Other related posts:
