The General Purpose Processor
David Katz and Richard Gentile
Introduction
What characteristics do today’s General Purpose Processors (GPPs)
share? How have evolving multimedia standards (e.g. audio, imaging
and video) influenced today’s GPP? What makes a good GPP? I
am glad you asked!

While
the processing requirements in today’s embedded systems have
increased based on a wide variety of reasons including more features,
increased frame rates, and the
display of larger resolutions, the corresponding connectivity requirements
have also been expanding (wired Ethernet, USB HS, WiFi, etc). In
past “design-in”
generations, the GPP was more tuned to the connectivity and control aspects
of the application and less on the signal processing. For designers
using a GPP in the past, there were a few choices. The first was
a paper exercise to work with “Marketing” to eliminate quantum
upgrades in the requirements. The second was to find a way to keep
the control and network aspects of the application while adding an upgrade
to the processing power.
Reducing
the requirements on the spec of a new product can mean the difference
between an “audio only” product versus one with audio and
imaging. On the higher end, it can mean a system that handles
imaging versus a system with video. The processing capability
can also separate the application in terms of value-added features
that can set your product apart from your competition’s product.
Certainly,
having a large number of operating systems available is a key component. Being
fluent and comfortable with an operating system is a major selection
criteria in selecting your processor. A good GPP has to have
a full suite of operating support. To support an operating system,
the GPP needs to be able to support a range of configurable interrupt
levels. By configurable, a priority level must be programmable. Also,
interrupts must be able to be reentrant and/or locked.
The
instruction set should support multiple word access sizes, including
byte addressing, as well as 16- and 32-bit accesses. The instruction
set should also include native support for stack and frame management. With
these capabilities, along with the managed interrupt capability described
above, operating kernels such as RTXC from Quadros, MicroC/OS-II form
Micrium, Nucleus form Mentor Graphics, ThreadX from ExpressLogic and
Fusion from Unicoi can run with small memory footprints and fast context
switch times.
With
a memory management unit that provides memory protection, operating
systems such uClinux and Integrity from Green Hills Software can run
with a segments of memory that are protected from user code accesses,
which improve the reliability of operations.
There
are two items that standout when using an operating system on a GPP. The
first is the ability to make a complex project simpler. This
is accomplished by managing tasks and threads in a way that doesn’t
compromise performance. The second is the large amount of software
that runs on top of the operating system. For example, each of
the operating systems listed above include things such networking,
graphics, and a file system. As I have discussed in past columns,
applications can also be available, such as voice, video and a whole
host of others.
This
is where today’s GPP begins to diverge from yesterday’s. The
addition of processing power on top of the control and networking functionality. This
has been solved in a variety of different ways by a large number of
silicon providers. One thing to take a look at during your processor
evaluation is how this processing power is accessed in the programming
model. Does the added processing come via a separate processor
that has to be programmed independently? Is there a specific
mode that you have to place the processor in?
Do you have to disable interrupts? If any of these are true, your
integration job will be more difficult.
Our
goal with Blackfin was to integrate these features into a single instruction
set architecture that works best when you write C and C++ code and
use the tools to build your system.
Another
facet of the GPP that has evolved is the use of a DMA controller to
move data throughout the system. The key to this is that any
work that a DMA controller does is work that the processor doesn’t
have to do. Similar to the way interrupts need to be flexible
from a priority standpoint, DMA channels have to be programmable to
match their importance in the system.
When
a processor has the features I have described above, it doesn’t
take as much effort to put it together. It also provides a platform
to evolve on.