PROCESSORS
Both reduced-instruction-set computer (RISC) microcontrollers (MCUs) and digital signal processors (DSPs) have traditionally served in media-rich embedded applications such as medical electronics. They are not used interchangeably; rather, they work in concert. MCU architectures are well suited for efficient asynchronous system control code execution while the bread and butter of DSP architectures is synchronous, constant-rate data flow (for example, filtering and transform operations). Because both function sets are necessary in today's media-processing applications, engineers often use separate MCU and DSP chips. This combination constitutes a good processing engine for a wide variety of multimedia applications, but it entails the added complexity of multiprocessing design, multiple development tool sets, and heterogeneous architectures to learn and to debug.
Chip vendors have tried to alleviate these problems with several different solutions. Various MCU makers have integrated some signal- processing functionality in their devices, such as instruction-set extensions and multiply-accumulate (MAC) units, but these efforts often lack the essential architectural basis required for advanced signal-processing applications. Similarly, DSP manufacturers have incorporated limited MCU functionality into their processors, but with inevitable compromises in the system control domain.
Another option has emerged recently, however—the embedded media processor (EMP). This processor presents both MCU and DSP functionality in a unified architecture that allows flexible partitioning between control and signal-processing requirements. As the application may demand, the EMP can act entirely as an MCU (with code density on par with industry standards), 100% as a DSP (with clock rates at the leading edge of DSP technology), or as something in between those poles, combining the modes of function in varying proportion.
This article presents a system designer's view of the organizational and technical questions that may arise when an EMP is considered. It offers goal-oriented insights into successful implementation of EMP-based approaches in system designs.
EMP Architecture
) |
Figure 1. Block digaram of single-core embedded media processor. (click to enlarge) |
An illustration of an EMP architecture is provided by the single-core BF533 from Analog Devices Inc. (Norwood, MA), a member of the Blackfin EMP family. This device combines a 32-bit RISC instruction set, dual 16-bit MAC units, and an 8-bit video processing engine (see Figure 1). Its variable-length instruction set extends as far as 64-bit opcodes used in DSP inner loops, but it is optimized such that 16-bit opcodes represent the most frequently used instructions. Therefore, compiled-code density is competitive with that of industry-leading MCUs, while the processor's interlocked pipeline and algebraic instruction syntax facilitate development in both C/C++ and assembly language.
EMPs, like MCUs, have protected operating modes that prevent users from accessing or affecting shared parts of the system. EMPs also provide memory management capabilities that define separate application development spaces while preventing distinct code sections from being overwritten. They allow for both asynchronous interrupts and synchronous exceptions, as well as programmable interrupt priorities. An EMP, therefore, is well suited for embedded operating systems, heretofore the MCU's domain.
On the DSP side, the EMP is structured for efficient data flow and very high performance, with a peripheral set that supports high-speed serial and parallel data movement. The convergent processor in addition contains an advanced power-management feature set that allows system architects to craft a design having the lowest possible dynamic power profile.
Development Approaches
In today's design paradigm, MCU and DSP programmers generally find themselves in two separate groups, interacting only at the system boundary where their two functional worlds meet. This makes some sense because the two groups of developers have evolved their own sets of design practices.
MCU versus DSP Programming. A signal-processing developer may relish the nitty-gritty details of the processor architecture and thrive on implementing tricks to improve performance. However, an MCU programmer might well prefer a model in which the device can just be turned on and left to do all the work. The EMP supports both direct memory access (DMA) and cache memory controllers for moving data through a system. Multiple high-speed DMA channels shuttle data between peripherals and memory systems, allowing for the fine-tuning controls sought by DSP programmers without using up valuable core processor cycles. Conversely, on-chip-configurable instruction and data caches support the hands-off approach to managing code and data that is very familiar to MCU programmers. Often, at the system integration level, a combination of both approaches is ideal.
Another reason for the historical separation of MCU and DSP development groups is that the two types of processor have two separate sets of design imperatives.
From a technical standpoint, engineers responsible for creating a system sometimes hesitate to mix a control application with a signal-processing application on the same processor. Their most common concern is that non-real-time tasks will interfere with hard real-time tasks. A programmer who handles tasks such as the graphical user interface or the networking stack, for instance, should not have to worry about hampering the real-time signal-processing activities of the system. Of course, what real-time means varies depending on the specific application. In an embedded application, the focus is on the time required to service an interrupt. A time frame of less than 10 microseconds between the occurrence of an interrupt and the saving of the system context at the start of the service routine generally is assumed for this purpose.
Although library-based MCU control code is usually written in C, real-time DSP code is typically assembly based and is handcrafted to extract the highest possible performance for a given application. This latter optimization unfortunately limits the portability of an application. Therefore, it perpetuates the need for two programming teams with divergent skill sets and tools suites on future projects.
EMP Programming. With the introduction of the EMP, however, a C/C++-centric unified code base can be realized. This allows developers to leverage the enormous amount of existing application code developed in earlier efforts. Because the EMP is optimized for both control and signal-processing operations, compilers can generate code that is both tight (from the standpoint of code density) and efficient (for computationally intensive signal-processing applications). Any gap in compiler performance is closed by the EMP's high operating frequencies—in excess of 750 MHz—which are at the leading edge of mainstream DSP capability today. Additionally, targeted assembly coding is still an option for optimizing critical processing loops.
Although moving to an EMP can greatly reduce the need to write code in assembly, this fact alone does not necessarily justify a switch to this unified platform. Operating system (OS) support also is key. Supporting an OS or real-time kernel allows several layers of tasking to be realized. To ensure that the targeted performance is still achievable, an interrupt controller that accommodates multiple priority levels is necessary. Context switching must be attainable through hardware-based stack and frame pointer support. This allows developers to create systems that include both realms of functionality—control and real-time signal processing—on the same device.
In addition, an EMP's memory management facility allows OS support for memory protection. This enables one task, by means of a paging mechanism, to block access to memory by another task. An exception is generated whenever unauthorized access is attempted on a protected area of memory. The kernel services this exception and takes appropriate action.
The high processing speeds achievable by an EMP translate into several tangible benefits. The first is shorter time to market: considerable time savings can be realized by reducing or bypassing the code optimization effort when there is plenty of processing headroom to spare. A second key benefit is a reduction in software maintenance, an expensive chore that can dominate a product's life-cycle cost. Finally, for scalable EMP architectures, there is the possibility of designing a system on the most capable processing family member and later right sizing the processor for the computational footprint of the final application.
Dual-Core Approaches
) |
Figure 2. Diagram of a dual-core embedded media processor. Core A runs operating-system, network, and control-related tasks, while Core B runs signal-processing algorithms. (click to enlarge) |
A final option—one that adds flexibility—is worth a quick review. Today, some EMPs are available as dual-core devices. The traditional use of a dual-core processor involves running discrete, and often different, tasks on each core (see Figure 2). For example, one core might perform all control-related tasks—such as graphics and overlay functionality, networking, interfacing to bulk storage, and overall flow control. This core is likely where the OS or kernel will reside. Meanwhile, the second core can be dedicated to the high-intensity processing functions of the application. For instance, compressed data packets might be transferred over a network interface to the first core, which would preprocess them and then hand them over to the second core for audio and video decoding.
This model is preferred by customers who employ separate software development teams. The ability to segment these types of functions allows a parallel design process, eliminating critical path dependencies in the project. Also, this programming model aids the testing and validation phases of the project. For example, if code changes on one core, that does not necessarily invalidate testing already completed on the other core.
Conclusion
In short, while digital signal processors and RISC microcontrollers will continue to pair up in a wide range of medical electronics applications, the introduction of the embedded media processor is enabling media-rich products to achieve levels of performance, integration, power efficiency, and cost sensitivity that are unattainable with solutions that employ those separate devices.
