[SI-LIST] Re: Article discussion on bad packages
- From: steve weir <weirsp@xxxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Sat, 01 Jan 2005 21:16:54 -0800
Lee thanks for the information, however with all due respect it still lacks
any data that supports the technical position that a defective package was
the root cause of Mahi's problems. The pieces of information that I
believe we have to date:
Mahi had problems with FPGA based 3.125Gbps links.
Mahi reported "severe" PCB level ground and power bounce.
Mahi had hundreds of 3.125Gbps links. ( All FPGA based? )
Mahi had several 4.8Gbps links that worked. non-FPGA based, ie completely
different silicon and package as the FPGAs
Mahi had several 9.6Gbps links that worked, same as above.
Now, what can we really determine from this data? We all agree that
"severe" PCB bounce is a PCB only phenomenon unrelated to a defect in any
IC. So, with all due respect, unless he was misquoted, Mr. Hecker has made
a public proclamation that admits a PCB level design failure at Mahi. We
should also expect that such a problem would in the best case mask any
problem with any IC or channel.
That one supplier, or two suppliers chips worked properly tells me very
little. The current profile, impedance requirements, analog Vcc noise
sensitivity, and local impedance environment of the various chips could all
have been vastly different without saying a single thing about any of the
packages. As Mr. Varma from Altera noted, it is very possible for an FPGA
customer to place demands on an FPGA that no practical package can support,
such as switching an insanely large, unbalanced NRZ bus at high drive
strength in the same region as the SERDES.
I eagerly await any technical data that both reconciles Mr. Hecker's
admission of PCB level design problems and supports the offered conclusion
that the FPGA package was inadequate to support the SERDES along with some
reasonable application behind it. In the meantime, I stand behind my
interpretation of the available data that points to a definite PCB level
problem(s), and fails to substantiate assertions of any FPGA defect as root
cause of Mahi's troubles.
I appreciate that Mahi might have quite a lot of information that they wish
to retain as confidential. However absent data, how do you, or Mahi expect
any trained engineer to accept unsupported conclusions on faith? Should an
OEM contemplating, or in design with SERDES from any: Altera, Lattice, or
Xilinx, now believe that they do not:work?
Regards,
Steve.
At 08:04 PM 1/1/2005 -0800, Lee Ritchey wrote:
>Steve,
>
>The product described by Mr. Hecker had hundreds of 3.125 GB/S links on it.
>It also had several 4.8 GB.S and a few 9.6 Gb/S links on it, all running in
>the same environment as the ones that failed and running very well.
>Hundreds of hours were spent making sure that the problem was correctly
>indentified before component changes were made. It is not my place to
>publish the data. It is the property of Mahi. Perhaps Ramon Hecker will
>share it.
>
>To suggest that the problem is somewhere else than the package is to
>discredit the fine work of a group of very thorough engineers. Not what I
>consider a good thing to do.
>
>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: steve weir <weirsp@xxxxxxxxxx>
> > To: <leeritchey@xxxxxxxxxxxxx>; Dan Bostan <dbostan@xxxxxxxxx>;
><vrbanacm@xxxxxxxxxx>; <Aubrey_Sparkman@xxxxxxxx>
> > Cc: <si-list@xxxxxxxxxxxxx>
> > Date: 12/25/2004 3:15:32 PM
> > Subject: [SI-LIST] Re: Article discussion on bad packages
> >
> > Lee, there are two very important issues here with regard to bounce
> > conclusions alone:
> > 1) Mr. Hecker described the bounce at the board:
> >
> > "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."
> >
> > I assume Mr. Goering took care to quote Mr. Hecker accurately. You
> > acknowledge your role in the piece. So are you now stating the quote is
> > wrong? If so, what the heck is going on here with these articles? If
>that
> > quote is wrong, what else is wrong in those pieces?
> >
> > 2) Even when the board appears quiet, it is easy to mistake excessive
>plane
> > spreading, and/or via attachment inductance for package inductance.
> >
> > As I stated a complete impedance budget for those things that we can
> > control, which is all elements up to the package attachment is
> > imperative. And I fully stand by my statement that this is the system
> > engineer's responsibility alone.
> >
> > The switching current that will stand on top of that impedance is
>something
> > that we can characterize. In an FPGA application we, not the IC
> > manufacturer have the final control on whether the combined switching
> > current and PDS impedance are compatible with device requirements. What
>a
> > suboptimal package does is limit the tolerable current. The system
> > engineer adopting the FPGA must marry the finite capabilities of the FPGA
> > to an appropriate environment and application. This problem is as old as
> > switching, even with relays.
> >
> > I suggest that we maintain decorum here. If you have facts that render
>my
> > statements and/or conclusions incorrect, then please by all means share
> > them, and we will all be educated. I fully accept my own limitations,
>and
> > despite the care that I try to use when posting, the possibility always
> > exists at anytime that I have missed information, and/or concluded in
> > error. If shown to be in error, I will happily be corrected and
>apologize
> > for any errors. But be assured, I make all my posts in good faith. I
>ask
> > that you concentrate on advancing the conversation with verifiable facts
>on
> > this important subject, and leave unjustified attacks on my character at
>home.
> >
> > Regards,
> >
> >
> > Steve.
> >
> >
> >
> > At 11:18 AM 12/25/2004 -0800, 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
> >
------------------------------------------------------------------
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:
