[SI-LIST] Re: Article discussion on bad packages
- From: steve weir <weirsp@xxxxxxxxxx>
- To: vrbanacm@xxxxxxxxxx, Aubrey_Sparkman@xxxxxxxx
- Date: Fri, 24 Dec 2004 13:47:17 -0800
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 decry use of
capacitors beyond their SRF as "bad advice":
"Application notes typically offer really bad advice, such as advocating
the use
of decoupling capacitors, which turn into inductors above 100 MHz"
Is there some misplaced belief that an inductive shunt is not a shunt?
Please don't get me wrong, there is much that can be done to improve both
packages and vendor documentation/communication. That is just the ordinary
technology treadmill. But responsibility for both the PCB package and system
performance lies with us as the integrators. We are the ones responsible to
validate what we believe and find out what we need to complete our jobs.
Fortunately, in most cases, the tools and methods to address our challenges,
while perhaps expensive, tedious and slow, do exist. Where vendor
information is
sparse, laboratory and analytical methods can fill the gaps. This is something
that Teraspeed does quite successfully for its customers including those using
big, fast FPGAs.
A smart OEM is the one who engineers: working, market commanding products. They
assess: available information, uncertainty and risk as part of ordinary program
management. What needed information they cannot obtain from vendors they
develop
themselves. If they need to hire qualified experts to get the job done,
they do.
In the meantime, their competitors can bemoan how hard life is while they lose
market. In his book Lee Ritchey implores that we cast away myths and rote
practices in favor of hard analysis. That's a concept worth taking seriously.
At Teraspeed, we do.
As a footnote, for people seeking solutions and ideas, DesignCon 2005 promises
to be rich with content on packages and power integrity and related systems
issues. It will include two papers from Teraspeed: "The Impact of PCB Laminate
Weave on the Electrical Performance of Differential Signaling at Mutli-Gigabit
Data Rates", and "High Performance FPGA Bypass Filter Networks". The truth is
out there. Let's use it to advantage.
===
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 decade and a
>half as have been Scott, Steve,
>and others and while I haven't been a personal confidant in their work
>on this, I am sure most of it
>would not be surprising to me since physics seems to be 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 articles like that.
>
>re: how to do an article like that... properly
>How about avoid "dissing" companies and instead cite "unnamed"
>situations where a real problem
>existed? You'd get a lot more folks 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 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
>implementing it in practice.
>Perhaps we will be there but not without some paradigms getting shifted,
>though. I happen to know
>it is far from over. The infrastructure to cause the 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 with for so
>long? Being politically
>correct has its places but you shouldn't be 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 decency and
>professional dignity
>about us, we'd better be about solving the problem instead of making a
>"bogey-man" out of it.
>
>Now I've spent much more time on discussing the article than I intended
>and not on the problem
>at hand which was the point of my first message. Focus on the real
>problem at hand instead of the
>problems that the article caused. That is what gives "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 thought the
> >benefit of this article to the SI community was to put a spotlight on
> >the problem, thus "some constructive "forward motion" toward solving the
> >problem." Indeed, I'm not sure of the benefit of discussing the problem
> >(companies designing products without proper resources) in this forum.
> >A discussion in this forum would be a little like "preaching to the
> >choir"; this problem seems more related to business decisions rather
> >than technical ones.
> >
> >What better method to move the issue forward than to publish successes
> >and failures? Anyone want to take a survey and publish? And where to
> >publish is important; the target audience isn't SI Engineers. While
> >there are many of us who would like to see that article, if you are in a
> >position to take that article and put in on your bosses desk, you are
> >most likely fighting a battle that someone already won.
> >
> >To be most effective the target audience needs to be those who want 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 [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 old
> >its got mold on it.
> >
> >I'm trying to figure out what it was for except to fill some space in EE
> >Times, was it a promotional advertisement for a consultant, or promoting
> >two companies and dissing two, etc.? There were no answers and no
> >solutions offered, plenty of gloom and doom, the industry is in the tank
> >on this issue, and there certainly doesn't seem to be enough simulator
> >"pilots" to do all the simulation we need to do and everyone is to blame
> >for "it" (whoever and whatever that is). I guess that means we need to
> >call in a "superhero", eh? Frankly, we've had better discussions on
> >this forum about that topic than that was.
> >What a waste.
> >
> >Enough of that...
> >I am hoping your query is to stimulate some constructive "forward
> >motion" toward solving the problem.
> >Its been around for a very long time.
> >
> >Michael E. Vrbanac
> >
> >
> >Scott McMorrow wrote:
> >
> >
> >
> >>I'd be interested in peoples thoughts about the following article from
> >>today's EE Times.
> >>
> >>http://www.eedesign.com/article/showArticle.jhtml?articleId=55801038
> >>
> >>
> >>------------------------------------------------------------------
> >>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
> >
> >
> >
> >
> >
> >
>
>
>
>------------------------------------------------------------------
>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:
