[SI-LIST] Re: Article discussion on bad packages
- From: "Patrick Zilaro" <pzilaro@xxxxxxxxxxxx>
- To: istvan.novak@xxxxxxxxxxxxxxxx, cgrassosprint1@xxxxxxxxxxxxx, Chris.Cheng@xxxxxxxxxxxx
- Date: Mon, 27 Dec 2004 12:17:03 -0800
Hi,
I completely agree that a full system analysis should be carried out to
ensure the design will meet all required performance specs. Each piece =
of
the puzzle will contribute to the system noise -> IC, package, and PCB =
(as
well as connectors, cabling, etc.)
With that said, I summarized my opinion last week on why packaging tends =
to
receive a lot of blame for the "system" noise. I am re-posting, since I
think many people were on vacation and did not get a chance to read it.
*************************************
I read the article; here is my perspective on why people like Lee =
Ritchey
think there are so many bad IC packages out there.
1) Margin and cost:
On most of our consumer products, we need to keep the cost of the
package very low in order to make any money. When you consider that a =
lot
of our products are integrating high speed analog blocks, high speed =
digital
interfaces, and even RF sections it becomes very difficult (sometimes
impossible) to maintain good signal integrity while designing into these =
low
cost packages.
2) Marketing people / IBIS models:
Our customers do not typically get to interface with myself or other
SI engineers. Instead they have to talk to marketing people. Most
marketing people think that delivering IBIS models with lumped =
(uncoupled)
RLC data takes into account all the necessary characterization =
information
that board level designs need to run SI analysis. They don't understand =
the
concepts of SSO noise, X-talk/coupling, core power droop, impedance
matching, skew, attenuation/loss, etc. Many times it is necessary to =
run
analysis using transistor level I/O's (instead of IBIS) and a more =
accurate
package model than lumped RLC.
3) I/O blocks on chip:
Many times I have seen I/O blocks that were not designed well for
signal integrity. Maybe they are analog blocks with noisy feedback =
loops,
RF sections that are overly sensitive to attenuation, or digital =
interfaces
with high slew rates and bad skew mismatch on-chip. Regardless of the
issue, it is much cheaper to try to fix the package than to re-spin the
silicon masks. In these situations the package might get "blamed" for =
the
bad performance, when the real problem is non-robust circuit design.
Just my $0.02.
Regards,
Patrick
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] =
On
Behalf Of Istvan NOVAK
Sent: Monday, December 27, 2004 7:51 AM
To: cgrassosprint1@xxxxxxxxxxxxx; Chris.Cheng@xxxxxxxxxxxx
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Article discussion on bad packages
I think the added difficulty in case of designing a 'good'
package comes from the fact that a large percentage
of the packages are designed for generic use.
When people are in the position to overview the entire
chain of silicon-package-board design, at least they
have a good chance to obtain all the necessary information
to do it right. This is the scenario, when there is a
problem with the final design, it is most probabably
the designers to blame: they must have overlooked
something or violated some design rules.
The problem is much more difficult to people who are
doing only part of this chain, and do it in isolation, without
much knowledge about the rest. People designing boards
with off-the-shelf third-party silicons do not know what
assumptions went into the silicon and package design.
Similarly, silicon and package designers for the open
market may not know what the board designers eventually
will do. As opposed to signal integrity, power integrity,
proper grounding and return-path selection is at least a
two-dimensional problem, plus performance of each major
block (silicon, package, board) can be traded among each
other to a large extent, so there is no unique good way to do
the design if the rest of the chain is unknown: there may
be millions of equally good designs, differing from each
other as the 'unknown' pieces differ.
At the moment there is no standardized way to even
capture the design requirements for the pieces of the
chain which is not under our control. For instance,
board designers dont have a standardized way to communicate
to chip and package designers what they intend to do on the
board. A board stackup and layout would be sufficient, but
it is so much information, and such a big part of it may be
irrelevant to the question in hand, that it requires simplification.
Also, because packages behave like filters between the silicon
and board, only a smaller percentage of the board-info details
will be eventually relevant for the silicon designers. A
standardized way is necessary to help to distill the information
and present it in a useful way. The same is true in the opposite
direction. Silicon designers dont need to communicate all of
the silicon details to board designers to enable them to do a
good design, but how to distill the information still remains to be
solved.
After the 2004 DesignCon panel discussion on PDN simulations,
this kind of standardization started in two independent tracks:
one of the IBIS committees and the IEEE TC-12 have been working
on proposals to address these issues. If anyone is interested in
contributing comments and proposals, please contact me offline
so that your effort can be channeled into these ongoing projects.
HAPYY HOLIDAYS to everyone.
Istvan Novak
SUN Microsystems
----- Original Message -----
From: "Charles Grasso" <cgrassosprint1@xxxxxxxxxxxxx>
To: <Chris.Cheng@xxxxxxxxxxxx>
Cc: <si-list@xxxxxxxxxxxxx>
Sent: Monday, December 27, 2004 9:28 AM
Subject: [SI-LIST] Re: Article discussion on bad packages
> Chris - And thats the bottom line (pun intended!)
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx
> [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Chris Cheng
> Sent: Saturday, December 25, 2004 4:08 PM
> Cc: 'si-list@xxxxxxxxxxxxx '
> 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
>
>
------------------------------------------------------------------
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: =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
------------------------------------------------------------------
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:
