Brian Fuller's editorial, "Red, blue, altered states" (Dec. 13, 2004; page 46) seems to agree with the Pacific Research Institute's nutty "economic freedom" rankings and links the so-called economic freedom of states to their voting for Bush. Yes, it is true that companies don't build fabs in New York or California anymore, choosing instead low-wage and environmentally lax areas. It is more telling to note that while companies may move their fabs to China or Texas, the company executives stay in the "high cost" states. Do you know of any high-tech executives who have moved their families to Shenzhen or Houston to enjoy the lax environmental regulations? Are the execs of the Pacific Research Institute now going to move its office from San Francisco to Bangkok to be free of the "nutty bureaucracy" and cut their own salaries to lower costs?
From [the editor's] listed area code, he must be a California resident too. He is one of the many people who want to live in the wealthier, more educated, more environmentally protective and more culturally enlightened states, if they can afford it. If economic freedom means accepting 30-cent-an-hour wages, toxic air and intolerance, I will decline, thank you very much.
IC Design Engineer
System woes? Maybe the chip packages aren't to blame
I read with great interest Richard Goering's piece "When bad packages kill good pc boards" (Dec. 20, 27, 2004; page 18). I hope someday you will run a complementary piece perhaps titled "When bad board designs undermine serviceable packages."
Blaming excessive system noise on the IC package, without examining how the actual noise budget was developed and verified, is a bit like blaming only the girl for an unwanted pregnancy. It is the OEM's responsibility to engineer its system properly. If a system is built without the requisite analysis, no one should be surprised if it doesn't work.
OEMs that wish to be successful must develop the internal skills or import the external expertise to engineer their systems by design and not happenstance. If an OEM lacks the internal resources to evaluate feasibility, that critical task should be outsourced.
Many people in this community, including the many contributors to the SI-List [electronic mailing list] from Sun Microsystems, have been beating the drum for years on the importance of three things to PDS quality: inductance, inductance and inductance. Even so, misconceptions and failure to do the 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. Given the article's description of Mahi Networks Inc.'s difficulties, I can't help but wonder whether this misunderstanding was at the root of that company's nine-month, $20 million fiasco.
The article also cites Mahi's design of 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," the article states. "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."
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 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 his or her engineering homework end up with unexpected excessive board-level bounce? How could such bounce possibly be the fault of the package? Placing a high-performance IC in an inadequate pc board environment is a lot like putting Yugo tires on a Formula One race car. Don't blame the tragic result on the car.
Don't get me wrong: There is much that can be done to improve both packages and vendor documentation/communication. But responsibility for both the pc board package and system performance lies with us as the integrators. And in most cases, the tools and methods to address our challenges exist.
Smart OEMs assess the available information, uncertainty and risk as part of program management. If they need to hire experts to get the job done, they do. Let the competition bemoan how hard life is as it loses market share.
Teraspeed Consulting Group LLC