|
[si-list]
||
[Date Prev]
[01-2005 Date Index]
[Date Next]
||
[Thread Prev]
[01-2005 Thread Index]
[Thread Next]
[SI-LIST] Re: Article discussion on bad packages
- From: steve weir <weirsp@xxxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Sun, 02 Jan 2005 19:22:10 -0800
Lee, l clearly have made no assumptions about the accuracy of Mr. Hecker's
quote. I have from the outset qualified my interpretation based on the
quote's accuracy. I have asked before, if what Mr. Goering authored as a
direct quote from Mr. Hecker is an accurate quote. Is it?
As I read the article, as well as your previous pieces they clearly appear
to assert the charge that at least one of the major FPGA vendors has been
shipping parts that cannot work as advertised. Essentially, that would
mean that the manufacturer has been making fraudulent representations to
their customers. Is my interpretation reasonable? Doesn't this also mean
that SERDES from one of the two major FPGA vendors in currently available
parts cannot be used?
You ask: "Why is it necessary for the article to prove to you that there
was a pacakge problem and not a PCB problem?" For the very simple reason
that the allegation of a package failure has not been even remotely
established. An application failure by itself does not establish a defect
in any one component. When an airplane falls out of the sky, do we
automatically blame: the aircraft design, the aircraft manufacture, the
pilot, maintenance, intentional act?
Your running assertion is that a component package defect is root
cause. Well, where is the data to support that conclusion as correct? Do
we even know what the primary symptom(s) was, for example:
a) DM signal XT from other signal aggressors?
b) CM range violations from other signal aggressors at the far or near end?
c) CM noise from common impedance ( bounce )?
d) PLL jitter or loss of lock?
Once there is at least a primary symptom, additional data can get down to
actual root cause and will either support, or challenge your conclusions.
In the meantime, if people are worried that they cannot use SERDES from
Altera or Xilinx, Teraspeed will be delighted to help them make their
designs work reliably.
Regards,
Steve.
At 06:02 PM 1/2/2005 -0800, Lee Ritchey wrote:
>Steve,
>
>You are assuming that Mr. Hecker was properly quoted. Why don't you call
>him and see. He is at Mahi as we exchange messages. Why is it necessary
>for the article to prove to you that there was a pacakge problem and not a
>PCB problem? The vendors interviewed didn't deny the problem.
>
>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>
> > Date: 1/1/2005 9:16:08 PM
> > Subject: Re: [SI-LIST] Re: Article discussion on bad packages
> >
> > 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:
> > > > > > http://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:
> > > > > > http://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:
> > > > http://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:
> > > > http://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:
> > >http://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:
> > > http://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:
http://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:
http://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
|
|
