Slashdot Mirror
System on a Chip Concurrent Development
An anonymous reader writes "The old silo method of chip development, with hardware and firmware developers barely interacting with each other, won't cut it in today's fast-moving industry. IBM DeveloperWorks has the third in a series of articles about system-on-a-chip design. The author, Sam Siewert, displays the development tools and processes that speed system on a chip design and get all your developers working together effectively."
Is there any reason hardware design has such a high standard compared to software?
Part of the reason is that hardware design by nature is less flexible than software to change, particularly as more hardware goes inside chips. The up front cost of a System-on-Chip can easily be more than 1 million dollars, and the cost of re-spinning a chip to fix a design flaw can be almost as high. And the month or two of time lost waiting for the re-spin also has a time-to-market cost. The high cost justifies the high standard.
I can't recall the last time I heard about a major hardware flaw.
Most hardware bugs are detected in the bring-up phases of a project; and by the time a company commits the money to hardware production, they have a fairly high confidence that the hardware is solid. Most major hardware bugs don't make it to production, so people don't hear about those failures. Hardware bugs that do make it to production go unnoticed, are covered up through software workarounds, or they get a lot of bad press (like the infamous Intel FDIV bug, or more recently the Xbox 360 instability problems).
Companies can afford to put out beta versions and patches of software, so a lot more software bugs are visible outside a company. There is still a cost of having software bugs, particular in critical systems and high volume applications, but fundamentally you can patch software. Patching hardware is possible only if you are lucky enough to have an accessible place to change the hardware behavior, or enough time and money to re-spin. For big complex hardware, designers attempt to put in some programmability to hopefully work around potential bugs, but it takes a lot of foresight to predict where things might go wrong.
With field programmable gate arrays (FPGAs) the hardware does look more like software since you can compile and reload a design into the FPGA chip. I have seen hardware designer be less stringent about FPGA designs because of the increased flexibility. With FPGAs there is a power and cost tradeoff since they are more general purpose. For an equivalent design, an FPGA eats much more power than an equivalent SoC, and FPGAs are typically much more expensive in volume than SoCs. So FPGAs are not a viable solution for things like PDAs, cell phones, and MP3 players where SoC's are prevalent.