[SI-LIST] Re: Article discussion on bad packages
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: leeritchey@xxxxxxxxxxxxx, si-list@xxxxxxxxxxxxx
- Date: Sat, 25 Dec 2004 17:01:34 -0500
Lee
Can I ask how these problems were demonstrated and determined
specifically to be package problems, rather than PCB problems? None of
your articles offer the slightest bit of information in this regards.
I ask, because I have been actively involved in the analysis and design
of quite a few packages in the industry, from multiple vendors, have
diagnosed similar problems on the products of several ASIC and
semi-custom foundry products, have corrected problems on a number of
vendors custom products and one FPGA vendor's product that is in
production today, and have designed several 10 Gbps packages over the
past several years that have exceeded performance requirements.
regards,
scott
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
>
>
>
>
--
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
(503) 750-6481 Cellular
http://www.teraspeed.com
Teraspeed 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:
//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:
