There seems to be a gradual shift in emphasis in IC design from traditional, hardwired architectures to more software-defined solutions. Fast processors, on-chip multiprocessing and large arrays of little processorlets seem to be replacing state machines and data paths as the building blocks of systems-on-chip. With sufficient execution speed, the reasoning goes, algorithms belong in software, not hardware. The arguments given for this notion include the difficulty of hardware design and the just-as-often-cited uncertainty in standards, protocols and requirements, all of which generate engineering change orders during chip design.

Integrating system-level chips into a system is a software-intensive business. If you add up all the test, diagnostic, driver and application software effort that goes into a typical SoC design, both the head count and cost of the software often dwarf the hardware development numbers. Makes you wonder why we're so exercised about mask costs. But we are talking about something different-shifting the basic work of the IC from dedicated hardware to software.

The force here is not sound architectural judgment, but rather the psychological issue that the grass always seems greener in the next pasture. Chip designers will usually tell you that design, implementation and debug are easier, faster and require fewer people for software than for hardware. So hardware engineers tend to move complex or unstable algorithms out of the chip and into software.

Unfortunately, the opposite is also true. Software designers will tell you that design, implementation and debug are vastly quicker and more reliable for hardware. And the numbers appear to be on their side. According to a recent statistic borrowed from the IT world, 25 to 40 percent of all major software installations at the enterprise level fail so badly that they are removed from service. Anecdotal evidence suggests that when a hardware/software system hits a snag, the fix is more often implemented in hardware than in software-not because that's where the problem was, but that's where the more-reliable methodology rests. Trying to patch the software often brings chaos. Maybe we should think twice about the notion and try to keep critical algorithms in hardware, where they can be analyzed, verified and reused.

Ron Wilson covers MPUs, programmable/reconfigurable logic and the chip design process. Contact him at rwilson@cmp.com.