Archive for February, 2010

Road Construction Ahead

Thursday, February 25th, 2010

A long-running joke in Canada is there are only two seasons—winter and road repair.

Dating back from the days of ancient times, roads have united empires. In a more figurative sense, they have made the best corporations better than their competitors. And on a conceptual level, they have linked together theories and concepts that previously had functioned in separate worlds.

In SoC design, we are at a point where we need more roads. The link between high-level models and abstractions and RTL-based hand-written code or hand-crafted test benches are sketchy, at best. At worst, there are no links at all. Models are created, abstractions are developed, and all too often they are completely ignored. It’s not that there isn’t value in this stuff—it’s that most people can’t connect the dots.

Unfortunately, semiconductor design cannot progress without them. At advanced nodes, designs are too complex to do everything by hand and far too costly. Yet without the roads between all the pieces, there also is too much mistrust and “black-box” uncertainty for many engineers to accept them. The result is chip design costs continue to skyrocket and the number of designs that can be justified at advanced nodes continues to shrink.

The irony is that while there is an enormous amount of profit to be gained once these connections are built, there is little financial incentive to dig in and create them. Perhaps it’s time for tools vendors and standards bodies to look at the big picture and build some new roads that can help manage complexity and significantly drive down costs.

The real value of a road is its ability to connect together lots of pieces, not just those with the fastest and most expensive vehicles.

–Ed Sperling

How Accurate Is Software?

Friday, February 19th, 2010

The number of corner cases is growing. In hardware, that means more verification, more testing and more re-spins. But in software there is no comparable verification method.

The Prius braking problem was blamed on a software glitch, but as Synopsys CEO Aart de Geus succinctly noted, none of Toyota’s rivals rushed out to trumpet their own software methodologies. While software adds flexibility, the perpetual mixing of ones and zeros also adds a lot more complexity into the whole process.

A couple decades ago, many software developers consider their applications to be market-ready when more than half of the bugs had been caught. While testing methodology has improved significantly, there are still enough software updates showing up on our computers and handheld devices to give pause to the effectiveness of the testing methodology.

In a smart phone, it really doesn’t matter. Unless you’re calling 911, you can simply reboot. But in a car’s braking system, you can’t. You can’t do that in an implantable medical device, either. And if your device is floating around in outer space, it can be tough to update the software.

Software cuts the cost of chip development. It adds flexibility to designs that can speed time to multiple markets. And it makes derivative chips much easier. But it also makes it much harder to find what in hardware would be considered all the corner cases.

It’s certainly important to begin developing software as early as possible in the design cycle. But given some of the high-profile failures, it’s also important to test it more effectively than in the past. Public perception and consumer demand are riding on getting these problems solved, and so are the future sales of semiconductors.

If Toyota is encountering these problems—a company that has been the poster child of manufacturing quality—then you can bet the problems are far more widespread than just the Prius.