[SI-LIST] Re: Article discussion on bad packages
- From: "databits" <databits@xxxxxxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Sun, 26 Dec 2004 10:52:44 -0600
OK... I waited after Christmas...
Well said ( or it that well questioned?), Chris.
Just as in signal integrity and data integrity, power integrity requires
a systemic design approach.
Personally, I would not allow myself to suggest anything less than a
system level approach is "appropriate" because always blaming others
doesn't get the job done.
This being said, it is possible for a bad apple to spoil the whole
system... [sarcasm_mode=on]But how could this possibly happen if the
component designers correctly identified all of the "Critical To
Function" (CTF) tolerances for each part and the relationships between
every part that the component could be connected such that the system
designers could use a spreadsheet to easily identify the CTF gaps
between each of the components of their system. Of course, CTFs are
always defined... Right?[sarcasm_mode=off]. If it was this easy,
everybody could make every system work right the first time. Further, I
would bet, for every "failed" system design with a given component... I
would bet there is a working system design with the same power/signal
requirements already working... (Notice, I did not throw in the word
"price")
The point being is that there is no substitute for perseverance,
experience, and communication with all components when it comes to being
a true system designer. That true system designer is probably underpaid.
(System Designer must have a bunch of Program Management capabilitiy)
To answer Scott's questions directly:
1) To establish some constructive feedback and solutions
>>> OK, I am still working on this... I am not sure what would be
constructive at this point. OR how that article could inspire... Still
thinking.
2) To establish the fallacies (and truths) in the article.
>>> Truth: The article was posted on December 20th. The fallicies...
Well... I do not know if there are any full fallicies, either... But a
lot of low hanging fruit and pathological conclusions are definitely
included. (i.e. Is there even one component provider that does not
realize at n.n GBs and above that package design is critical?) Better
would be to see if there is a list of package CTFs specifications and
tolerances that it would be possible to agree. Maybe this goes to
"Question 1"?
3) To encourage a public discussion on package power delivery issues
(yet again), and specifically those issues concerning FPGA design.
>>> See above. Better yet... Go back to the Smith, Anderson, Novak, et
al. threads.
4) To see if there are others out there who are successfully using FPGAs
in their high-performance designs (we expect there are quite a few.)
>>> Interesting thing is that the responses seem to be equal between
consultants and system designers.. Maybe slightly more to consultants.
I wonder if this means anything?
_ap
Side Note:
A very bad thing is to pick off the low hanging fruit of technical
obviousness to then later imply patholigical conclusions. Give me a
break.
Side Note 2:
New Years resolution for 2005... Be kinder and more gentle... Same as
for 2004... Maybe this year I will get it right.
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Chris Cheng
Sent: Saturday, December 25, 2004 6: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.
------------------------------------------------------------------
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:
