[SI-LIST] Re: Article discussion on bad packages
- From: "Chris McGrath" <chris.mcgrath@xxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Wed, 29 Dec 2004 12:17:28 -0500
A couple of comments based upon a quick reading through of this thread:
First, as far as the relevance of the article, I agree that this is not
a new issue but you can bet that I forwarded it to the key program
"higher-ups" as another plank in the platform of SI design time required
in our product design. As most of you are familiar with, quantifying SI
work in a development schedule is difficult to spec out and high level
articles like this, if anything, justify our existence a little more.
In a company like ours that has program managers and executives from a
variety of engineering backgrounds (including EEs who went into
management before this topic really got serious attention), this kind of
article is relevant to the evangelization effort.
Second, I thought it has started a good discussion thread, as intended.
I appreciate links like this and hope that others share them since I
know that I don't have time to read through many of the trade
publications.
Third, Steve's second comment...
> 2. The OEM is responsible for obtaining enough data to design=20
> a system, as=20
> opposed to creating a netlist and praying.
... is a little too black and white. While I agree that the OEM is
responsible for obtaining the data, it is the responsibility of the
vendor to be able to supply this information. On programs like many
that we work on on where the silicon will be coming out at the same time
the PCB is ready and the silicon is from a sole source, we have already
made a substantial commitment to a vendor and we rely heavily on them to
to provide advance information based on their simulation and testing.
Just as it is the obligation of the OEM to request the information, it
is also the obligation of the vendor to be able to supply it and in a
timely manner. To tie this back to my first comment, having program
folks understand this type of issue allows us to better quantify risk to
programs when choosing a vendor if they better understand the shades of
grey. For instance, if vendor A can better describe their SI design and
testing for a chip and produce good PCB design use guidelines when
compared to vendor B, then vendor A is more desireable. =20
-Chris
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx=20
> [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of steve weir
> Sent: Friday, December 24, 2004 4:47 PM
> To: vrbanacm@xxxxxxxxxx; Aubrey_Sparkman@xxxxxxxx
> Cc: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: Article discussion on bad packages
>=20
>=20
> Aubrey, Mike,
>=20
> In response to that EET article, I sent the following letter to Mr.=20
> Goering. The "Reader's Digest" version is that:
>=20
> 1. The PCB can kill the system just as easily as the IC. =20
> Both are part of=20
> the package.
> 2. The OEM is responsible for obtaining enough data to design=20
> a system, as=20
> opposed to creating a netlist and praying.
> 3. Even where documentation is lacking, characterization can yield=20
> sufficient data to design reliably.
> 4. Bounce observable on the PCB is a PCB problem not a=20
> package problem. 5. There are lots of misconceptions out=20
> there about power distribution and=20
> packaging.
> 6. Package limitations in the ICs, at the board level and in=20
> the system are=20
> a fact of life. Making it all work is what we are paid to=20
> do. 7. This year's DesignCon has about a dozen papers ( shameless=20
> plug: including two from Teraspeed ) and presentations on=20
> topics that=20
> touch on the subject matter of the Dec. 18 EET article.
>=20
> I hope everyone has a happy and safe holiday.
>=20
> Best regards to all,
>=20
>=20
> Steve.
>=20
> =3D=3D=3D=3D
> (c) 2004 Teraspeed Consulting Group, LLC
>=20
> Dear Mr. Goering,
>=20
> I read with great interest, Monday's piece: "When bad=20
> packages kill good pc boards". I hope someday you will run a=20
> complementary piece perhaps=20
> titled "When
> bad board designs undermine serviceable packages".
>=20
> To blame excessive system noise on the IC package without=20
> examining how the actual noise budget was developed and=20
> verified, I find a bit like blaming only the girl for an=20
> unwanted pregnancy. It is the OEM's ultimate responsibility=20
> to engineer their system properly. This is a theme that Lee=20
> Ritchey stumps on in his book, "Right the First Time". In his=20
> excellent DesignCon 2004 paper=20
> "System Level
> Power Integrity Analysis and Correlation for Multi-gigabit=20
> Designs" Dr.=20
> Ralf Schmitt
> and his fellow Rambus authors made plain that system level=20
> power integrity=20
> is the
> sum of the parts from the IC core all the way out through the=20
> PCB structure to the voltage regulator module. If a system is=20
> built without the requisite=20
> analysis, then why
> is anyone surprised if it does not work properly?
>=20
> OEMs who wish to be successful must develop the internal=20
> skills, or import external expertise to engineer their=20
> systems by design, and not happenstance. I find little=20
> surprise that various FPGA customers who have spent the=20
> resources to
> develop such expertise jealously guard it, and do not wish to=20
> share it with competitors.
>=20
> Similarly, why would anyone expect an application note to=20
> circumvent the need for engineering? An appnote is a place to=20
> get started, not the end-point. A=20
> good
> appnote IMO demonstrates a principle and provides a distilled=20
> example. Why is such cookbook simplification reviled instead=20
> of acknowledged for the=20
> limitations
> it necessarily carries? As with the hilarious Douglas Adams=20
> books, the trouble isn't understanding the answer, it is=20
> understanding the question.
>=20
> If an OEM lacks the internal resources to evaluate=20
> feasibility, and then design a demanding physical system=20
> themselves, that critical task should be=20
> out-sourced
> to appropriate expertise. That expertise is available. In the=20
> meantime, education is available including from colleges,=20
> consultants, and even vendors such as Xilinx. To wit for a=20
> paltry $20. one can purchase the DVD set just released=20
> featuring Dr. Howard Johnson's discussion of the care and=20
> feeding of MGTs. Xilinx also offers an SI course, and Altera=20
> will be presenting at DesignCon 2005 on SSO.
>=20
> We have many people in this community, including the many=20
> contributors to the SI-List from Sun Microsystems: Larry=20
> Smith, Istvan Novak, Ray Anderson ( recently snagged by=20
> Xilinx ), who for years have all been beating the drum on the=20
> importance of three things to PDS quality: Inductance,=20
> inductance and inductance. Even so, misconceptions, and=20
> failure to do necessary homework frequently get people into=20
> trouble. One subject that I still see regularly trip-up even=20
> "experts" is a proper accounting of device via attachment and=20
> plane
> spreading inductance as elements of the overall bypass=20
> impedance budget. Overlooking these in high performance=20
> systems can lead to horribly wrong conclusions and encourage=20
> error prone measurements. Yet we see repeated statements and=20
> even books that assert demonstrably wrong claims in both=20
> theory and practice. Given the description offered in today's=20
> article that featured Mahi's difficulties I can but wonder if=20
> this common=20
> misunderstanding is
> not at the root of the nine-month $20 million dollar fiasco reported.
>=20
> The article quotes as an example a reported failure at Mahi=20
> Networks, described
> as:
>=20
> "Mahi was designing what Hecker describes as a "cutting-edge=20
> application" involving 3.125-GHz backplane links. The design=20
> called for FPGAs with=20
> integrated
> serdes capability to be used as serial links. But test data=20
> showed severe=20
> ground
> bounce and power bounce on the board, as well as performance problems=20
> related to
> the operation of the serdes links in the system environment."
>=20
> Assuming the quote is accurate, how on earth does any=20
> engineer blame board=20
> level
> bounce on the IC package? Were the package the culprit here,=20
> noise at IC=20
> package
> attachment would be nominal while the noise at quiet IC I/Os=20
> or in the core would be problematic.
>=20
> For board level PDS stability, the only two variables at our=20
> disposal are=20
> the IC
> application current and the board impedance. The former may=20
> be determined by test fixturing, the latter readily=20
> synthesized by design. So how could anyone who did their=20
> engineering homework end-up with unexpected excessive board=20
> level bounce? How could such bounce possibly be the fault of=20
> the package as=20
> opposed to
> the system engineer? Placing a high performance IC in an=20
> inadequate PCB environment is a lot like putting Yugo tires=20
> on a Formula One race car. Why is the tragic result either a=20
> surprise, or blamed on the car?
>=20
> There are many misconceptions out there, and none of them=20
> help engineer working systems. Unfortunately, Monday's piece=20
> IMO helped propagate some wive's=20
> tales. I
> about fell out of my chair when I saw that article apparently=20
> decry use of capacitors beyond their SRF as "bad advice":
>=20
> "Application notes typically offer really bad advice, such as=20
> advocating=20
> the use
> of decoupling capacitors, which turn into inductors above 100 MHz"
>=20
> Is there some misplaced belief that an inductive shunt is not a shunt?
>=20
> Please don't get me wrong, there is much that can be done to=20
> improve both packages and vendor documentation/communication.=20
> That is just the ordinary technology treadmill. But=20
> responsibility for both the PCB package and system=20
> performance lies with us as the integrators. We are the ones=20
> responsible to validate what we believe and find out what we=20
> need to complete our jobs. Fortunately, in most cases, the=20
> tools and methods to address our challenges, while perhaps=20
> expensive, tedious and slow, do exist. Where vendor=20
> information is
> sparse, laboratory and analytical methods can fill the gaps.=20
> This is something that Teraspeed does quite successfully for=20
> its customers including those using big, fast FPGAs.
>=20
> A smart OEM is the one who engineers: working, market=20
> commanding products. They
> assess: available information, uncertainty and risk as part=20
> of ordinary program management. What needed information they=20
> cannot obtain from vendors they=20
> develop
> themselves. If they need to hire qualified experts to get the=20
> job done,=20
> they do.
> In the meantime, their competitors can bemoan how hard life=20
> is while they lose market. In his book Lee Ritchey implores=20
> that we cast away myths and rote practices in favor of hard=20
> analysis. That's a concept worth taking seriously. At=20
> Teraspeed, we do.
>=20
> As a footnote, for people seeking solutions and ideas,=20
> DesignCon 2005 promises to be rich with content on packages=20
> and power integrity and related systems issues. It will=20
> include two papers from Teraspeed: "The Impact of PCB=20
> Laminate Weave on the Electrical Performance of Differential=20
> Signaling at Mutli-Gigabit Data Rates", and "High Performance=20
> FPGA Bypass Filter Networks". The truth is out there. Let's=20
> use it to advantage. =3D=3D=3D
>=20
>=20
>=20
> At 02:38 PM 12/24/2004 -0600, you wrote:
> >Aubrey,
> >Wishing you the best during this holiday season...
> >
> >What I really think? If you knew me, you would already know. :-)
> >
> >re: the issue at hand... device/package/pcb PDS issues
> >I have already been fighting this "battle" for at least a=20
> decade and a=20
> >half as have been Scott, Steve, and others and while I=20
> haven't been a=20
> >personal confidant in their work on this, I am sure most of it
> >would not be surprising to me since physics seems to be=20
> consistent that
> >way and we are looking
> >at the same sort of structures and have similar electrodynamic events
> >going on. I am hoping that
> >there will be enough of us to finally move this thing forward without
> >all the FUD (fear, uncertainty,
> >and doubt) that has preceded on this. While my knowledge on this is
> >under "gag rule", I am
> >cheering these guys on because I think "we'll" get it done this time.
> >If it doesn't, your employer
> >might find it hard to keep momentum on building new servers and
> >computers. Given the import
> >of that possibility, its not time to mince words about=20
> articles like that.
> >
> >re: how to do an article like that... properly
> >How about avoid "dissing" companies and instead cite "unnamed"=20
> >situations where a real problem existed? You'd get a lot more folks=20
> >offering up their horror stories. But don't stop there. Discuss
> >what caused such things and what are the ramifications of doing it
> >right/wrong. Write it in such
> >a way as to allow folks to look at their situation and be able to
> >compare it and then learn from it.
> >The article that was published really did not do that. It was too
> >clouded with other things more
> >suited for an advertising piece than a technical piece. You=20
> must first
> >start from a firm and sound
> >technical basis from which to move forward.
> >
> >re: a battle already won
> >Not yet, my friend. Knowing what is wrong is not the same as=20
> >implementing it in practice. Perhaps we will be there but=20
> not without=20
> >some paradigms getting shifted, though. I happen to know
> >it is far from over. The infrastructure to cause the=20
> problem is still
> >well in place and will continue
> >to affect you and others for a while yet.
> >
> >re: the most effective way
> >Build bridges to what? To the same situation we've lived=20
> with for so=20
> >long? Being politically correct has its places but you shouldn't be=20
> >too soft spoken when "the house is burning down"
> >as it is for many of these companies cited in the article. Nice
> >platitudes but the time for that is over.
> >Companies are losing their shirts and if we have any sort of=20
> decency and
> >professional dignity
> >about us, we'd better be about solving the problem instead=20
> of making a
> >"bogey-man" out of it.
> >
> >Now I've spent much more time on discussing the article than=20
> I intended=20
> >and not on the problem at hand which was the point of my=20
> first message. =20
> >Focus on the real problem at hand instead of the
> >problems that the article caused. That is what gives=20
> "forward motion".
> >
> >Best Regards,
> >
> >Michael E. Vrbanac
> >
> >
> >Aubrey_Sparkman@xxxxxxxx wrote:
> >
> > >Michael,
> > >Why don't you tell us what you really think? :-)
> > >
> > >While I agree that the problem has been around awhile, I=20
> thought the=20
> > >benefit of this article to the SI community was to put a=20
> spotlight on=20
> > >the problem, thus "some constructive "forward motion"=20
> toward solving=20
> > >the problem." Indeed, I'm not sure of the benefit of=20
> discussing the=20
> > >problem (companies designing products without proper resources) in=20
> > >this forum. A discussion in this forum would be a little like=20
> > >"preaching to the choir"; this problem seems more related=20
> to business=20
> > >decisions rather than technical ones.
> > >
> > >What better method to move the issue forward than to publish=20
> > >successes and failures? Anyone want to take a survey and=20
> publish? =20
> > >And where to publish is important; the target audience isn't SI=20
> > >Engineers. While there are many of us who would like to see that=20
> > >article, if you are in a position to take that article and=20
> put in on=20
> > >your bosses desk, you are most likely fighting a battle=20
> that someone=20
> > >already won.
> > >
> > >To be most effective the target audience needs to be those=20
> who want=20
> > >to "build bridges" without proper engineering support.
> > >
> > >But that's just my opinion.
> > >
> > >Happy Holidays!
> > >Aubrey Sparkman
> > >Enterprise Engineering Signal Integrity Team
> > >Dell, Inc.
> > >Aubrey_Sparkman@xxxxxxxx
> > >(512) 723-3592
> > >
> > >-----Original Message-----
> > >From: si-list-bounce@xxxxxxxxxxxxx=20
> > >[mailto:si-list-bounce@xxxxxxxxxxxxx]
> > >On Behalf Of Michael E. Vrbanac
> > >Sent: Tuesday, December 21, 2004 2:33 AM
> > >To: scott@xxxxxxxxxxxxx
> > >Cc: silist
> > >Subject: [SI-LIST] Re: Article discussion on bad packages
> > >
> > >Scott,
> > >
> > >I wasn't terribly impressed. What was the point? That news is so=20
> > >old its got mold on it.
> > >
> > >I'm trying to figure out what it was for except to fill=20
> some space in=20
> > >EE Times, was it a promotional advertisement for a consultant, or=20
> > >promoting two companies and dissing two, etc.? There were=20
> no answers=20
> > >and no solutions offered, plenty of gloom and doom, the=20
> industry is=20
> > >in the tank on this issue, and there certainly doesn't seem to be=20
> > >enough simulator "pilots" to do all the simulation we need=20
> to do and=20
> > >everyone is to blame for "it" (whoever and whatever that is). I=20
> > >guess that means we need to call in a "superhero", eh? Frankly,=20
> > >we've had better discussions on this forum about that=20
> topic than that=20
> > >was. What a waste.
> > >
> > >Enough of that...
> > >I am hoping your query is to stimulate some constructive "forward=20
> > >motion" toward solving the problem. Its been around for a=20
> very long=20
> > >time.
> > >
> > >Michael E. Vrbanac
> > >
> > >
> > >Scott McMorrow wrote:
> > >
> > >
> > >
> > >>I'd be interested in peoples thoughts about the following article=20
> > >>from today's EE Times.
> > >>
> >=20
> =
>>http://www.eedesign.com/article/showArticle.jhtml?articleId=3D55801038
> > >>
> > >>
> > >>------------------------------------------------------------------
> > >>To unsubscribe from si-list:
> > >>si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject=20
> > >>field
> > >>
> > >>or to administer your membership from a web page, go to:=20
> > >>//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=20
> Subject field
> > >
> > >or to administer your membership from a web page, go to:=20
> > >//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:=20
> >//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
> >
>=20
>=20
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>=20
> or to administer your membership from a web page, go to:=20
> //www.freelists.org/webpage/si-list
>=20
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>=20
> List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>=20
> List technical documents are available at:
> http://www.si-list.org
>=20
> List archives are viewable at: =20
> //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
> =20
>=20
>=20
------------------------------------------------------------------
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:
