One processor to rule them all?

This series of articles on processor architectures asks, "Can a single processor architecture do it all, and if so, would it be a good idea?" Part one begins with a brief overview of the processor architecture ecosystem.

Much like Middle-earth in The Lord of the Rings, the ecosystem for embedded and computing systems is home to a diverse population. Instead of elves, dwarves, Hobbits, and humans, all manner of processor architectures inhabit the compute and embedded-processing ecosystem. The various microprocessors, digital signal processors, and microcontrollers implement different optimization choices to meet system designers’ myriad design requirements.

That analogy occurred to me as I read a number of recent articles and public online discussions. Collectively, they ask two questions that implicitly share the same underlying architecture: Are 8-bit processors dying, and is ARM winning the processor war? The articles and discussions all suggest that the ARM architecture will be the one to put the final nail in the coffin of smaller-bit-width microcontrollers and will possibly even crowd out other 32-bit microprocessors in other application spaces. In this rapidly evolving ecosystem, can the ARM architecture become the one to rule them all?

The analogy serves only as an illustration of the common, implied architectural theme running through these questions and the accompanying discussions; it is not meant to be a statement about the discussed processor architectures or about the ecosystem companies that support them. At least for me, however, the analogy provides a visual image that captures the almost palpable expectation that a single processor architecture might finally deal the death blow to 8- and 16-bit architectures one day soon, as well as possibly dominate traditional applications for 32-bit and larger microprocessors.

Is such a consolidation of processing architectures possible? Is it even desirable?

Let’s begin this exercise by stipulating that with regard to cost, workload capacity, and energy consumption, a specific 32-bit processor has achieved or surpassed parity with a specific 8-bit processor that is being used for a specifically defined workload. The point of this precisely worded stipulation, beyond avoiding data-sheet debates, is to emphasize that the replacement of any processor with another is performed on a case-by-case basis that distinguishes between explicit alternatives in the context of an explicit workload (expected or already implemented). When the new alternative is superior to the incumbent implementation, there is an opportunity for a migration to the new alternative.

Migrating a workload to an alternative device as part of the life cycle of both the workload and the available processing options, however, is not the same as migrating to an alternative expressly because the incumbent processor width or architectural implementation has become obsolete.

As an example, consider the analogous, long-debated statement that FPGAs will drive DSPs to obsolescence. It has been repeatedly demonstrated that FPGAs can perform arbitrarily wide signal-processing tasks more quickly and efficiently than dedicated DSPs. For a given workload, however, a specific processor that incorporates the optimal type and number of execution units to implement that specific workload can negate an FPGA’s performance and efficiency advantage.

In fact, a realistic life-cycle scenario for contemporary signal-processing workloads could initially see a workload under development implemented as software on a high-performance microprocessor or DSP in simulations and prototypes. As the volatility and uncertainty of the workload implementation stabilized, the developers would migrate it to an FPGA to optimize performance, price, and energy consumption. Once designers adopted the workload for a large number of high-volume designs, a semiconductor company might decide to produce a specialized processor or coprocessor integrated with a microprocessor or DSP that targeted the specific workload; that development, in turn, would justify yet another migration of the workload, this time to a software implementation on said device. None of those migrations would be cause for concern that microprocessors, FPGAs, or DSPs were becoming obsolete.

Part 2 examines the spectrum of processing sweet spots.

Also see:

• Processor architectural differences
• ARM Versus x86: Which will achieve Windows success?
• 30 years of DSP: From a child's toy to 4G and beyond
• The future of computers: multicore and the memory wall
• Intro to embedded systems part 2: Anatomy of a typical small microcontroller
• Memory hierarchy design part 1: basics of memory hierarchies