[SI-LIST] Re: Article discussion on bad packages
- From: "Lee Ritchey" <leeritchey@xxxxxxxxxxxxx>
- To: "Chris Cheng" <Chris.Cheng@xxxxxxxxxxxx>
- Date: Sun, 2 Jan 2005 17:46:16 -0800
Chris,
You are right that an engineer should check out the package first before
committing to it in a design.
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: Chris Cheng <Chris.Cheng@xxxxxxxxxxxx>
> Cc: si-list@xxxxxxxxxxxxx <si-list@xxxxxxxxxxxxx>
> Date: 12/25/2004 4:14:26 PM
> Subject: [SI-LIST] Re: Article discussion on bad packages
>
> Let's do some Einstein thought experiments here.
>
> Let's say we have a properly design I/O cell with sufficient power/ground
to
> signal pad ratio. But :
>
> a) Some smart system designer decided to reference the entire bus with an
> external power plane on the PCB that has nothing to do with the I/O or
even
> the chip power. And to make things worst he does not have enough highspeed
> caps on the PCB to provide the return current back to ground.
> Do you expect to see SSO noise ?
> Can you blame the I/O or package design ?
>
> b) Now move this problem to the package substrate where the package
designer
> make the same mistake on reference plane.
> Do you expect to see SSO noise ?
> Can you blame the system design ?
>
> c) Now what if both of the make the same mistakes ?
> Do you expect to see SSO noise ?
> Can you blame the system or package design alone ?
>
> At the end of the day, the buck stops at the designer. When you take the
> responsibility to implement a system, you have to check the I/O design,
> signal to power/ground ratio, package stack up/routing, PCB stack
> up/routing. Yes, when I was in certain company I had Ray or Larry to help
me
> check the package as they are great component engineers. But it was my pin
> out, I/O design and stackup. There is no excuse to point finger at the
> silicon or component vendor, you should have evaluated the IC in your
> feasibility study before you commit to that vendor. If the bus doesn't
work,
> it's my rear. And my boss let me know that well in advanced.
>
>
> -----Original Message-----
> From: steve weir
> To: leeritchey@xxxxxxxxxxxxx; Dan Bostan; vrbanacm@xxxxxxxxxx;
> Aubrey_Sparkman@xxxxxxxx
> Cc: si-list@xxxxxxxxxxxxx
> Sent: 12/25/2004 3:15 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
> >
> >
> ------------------------------------------------------------------
> 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:
