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.