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.