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."

Comments

Complete series

[Saiyine]

Link to all the articles in order.

nothing new here

[wannasleep]

Hardware-software codesign is nothing new and revolutionary. It has been taught for years at berkeley and around the country. A bunch of links can also be found here

Everything old is new again

[dprice]

The concept of software/hardware codesign is not a new one. I would say that every project I have worked on for the past 20 years has been a software/hardware codesign project, regardless of whether it was an SoC or some other hardware system. In every case, I have seen the software start running shortly after the new hardware is powered up. Fast software boot is a validation that you did the design correctly, but it should not be viewed as an amazing feat. It should be an expected outcome that was planned for. Those who design in "silos" are doing it the wrong way from the start and are asking for problems.

Within the last 5 years or so, there has been a lot of hype about System-on-Chip (SoC) development. There have been lots of SoC articles, and many companies trying to sell tools to develop SoC's. But when I read through most of the hype, I find nothing all that revolutionary about the tools and methods. Chip fabrication has reached the point where one can integrate a lot of functionality on a chip, but the design methodologies for successful designs are still basically the same as the past non-integrated designs. Mistakes are less forgiving in an SoC since rework is very difficult or impossible, so the design verification requirements need to be thorough. Most design successes that I have seen have been more dependent on the thoroughness of the design team than the tools used. The best tools in the world will not save you from the blunders of bad designers.

Re:Everything old is new again

[dprice]

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.

It's been done

[seanadams.com]

Why not make a CPU with a built-in FPGA, then load bits of the kernel into that hardware?

Call me crazy, but that might be more efficient than just throwing more cores at the problem.

Here's one: Atmels' 20 MIPS processor + FPGA

The problem is, fast processors are now SO cheap that the applications for a part like this are incredibly limited - you end up with the wrong FPGA and the wrong uP for more than it would probably cost you to buy the right architecture as discrete chips.

Re:This gave me an idea.

[Jerry Coffin]

Why not make a CPU with a built-in FPGA, then load bits of the kernel into that hardware?

Were you thinking of something a lot different from the Xilinx Virtex 4 FX, Altera Excalibur or Atmel part (referred to elsethread)?