In today's increasingly net-centric microcontroller systems, especially those, such as home networking, which use wireless connectivity to transmit both control and data, such combinations are becoming more common. They require the same attention to reduced component count and cost, without sacrificing performance or deterministic operation.

To handle these tasks, there are a few system design options. One is to use a combination of DSP and MCU chips on-board. This plan is cost-intensive and space-demanding, but allows maximum flexibility to size each chip appropriately to the system's needs. Another is to use a multichip module (MCM) consisting of a DSP and MCU within a single package. However, the limitation to this approach is that the designer must partition to a "50/50" share of control and DSP functions; once the DSP is "maxed out," for instance, the MCU will be unable to take up the computational slack. As with the first option, two sets of development tools are required when separate DSP and MCU cores are present.

A third option involves incorporating DSP functionality into an MCU. This approach is only appropriate for straightforward signal processing applications. MCU clock speeds and computation architectures are fundamentally not well suited for intensive number-crunching. Some MCUs try to compensate by adding a multiply/accumulate (MAC) unit, a hallmark of the DSP. Still, this approach lacks the essential "ground-up" architectural design necessary for more advanced applications.

Recently, a fourth approach has emerged: incorporating MCU functionality into a DSP. These new DSPs exhibit a unified architecture optimized not only for numeric computation, but also for control-oriented tasks. By balancing the need for control task execution with requirements for complex calculations, this approach allows for up to 100% control or 100% computation, depending on the real-time needs of the system. All this is accomplished with no mode switching between "DSP Mode" and "MCU Mode."

Let's first review how DSPs and MCUs typically function. The DSP focuses on performing as many MAC operations as possible in a single core clock cycle. To that end, instruction opcodes are often of the VLIW variety. Also, a DSP is optimized to run in tight, efficient loops. In addition, achieving performance goals usually requires writing optimized assembly code. Because DSP algorithms can typically fit in small, low-latency on-chip memory, code density is not generally of great concern.

As much as DSPs focus on performing computations, MCUs concentrate on performing control functions. As such, the typical MCU application involves many conditional operations, with frequent changes in program flow. Programs are usually written in C or C++. Code density is paramount, and algorithms are measured in terms of compiled code size. Memory systems are cache-based and allow the system designer to run from larger memories with higher latencies. With a cache-based system, the programmer need not manage how and when instructions are brought into the core for execution.

The unified DSP/MCU realizes the benefits of both approaches. Its instruction set consists of 16-, 32- and 64-bit opcodes, but since the most common instructions are encoded using 16 bits, compiled code density figures are on par with those of popular MCUs. Additionally, it includes a memory protection facility and both instruction and data caches, as part of an overall Memory Management Unit (MMU).

Multitasking RTOSes
An important aspect of system control is task management. Increasingly, real-time operating systems (RTOS) are employed to handle the wide range of ongoing, concurrent tasks in complex systems. The RTOS simplifies the programming model by providing support for task scheduling and management, and it usually runs on the MCU, since typical DSPs do not have all of the RTOS-friendly features needed for efficient implementation.

A unified DSP/MCU can facilitate RTOS development if it has several important features. One is the ability to restrict access to protected or reserved memory locations. Another is the provision of separate stack and frame pointers to reduce latency of OS calls and interrupt/exception handling. A third feature is the existence of separate user and supervisor operating modes.

Historically, DSPs have operated in the equivalent of supervisor mode, allowing full access to all system resources at all times, whereas MCUs have provided the analog of a user mode that allows applications to run on top of an OS. With two operating modes under one unified architecture, a DSP-intensive system can restrict user applications to accessing system resources only through the OS.

One area in which MCUs excel is their flexible, ample peripheral set. As general-purpose embedded controllers, they're often packed with I/O flags, timers, serial ports and, increasingly, more complex standard interfaces.

But the thrust of the MCU peripheral set is that of embedded control, not intensive computation. For instance, a real-time clock might wake up a temperature sensor to sample the ambient environment and relay information back to the MCU via I/O pins. Then, a timer's pulse-width modulated (PWM) output could increase or decrease the speed of a fan motor accordingly.

Like the MCU, a unified DSP/MCU can incorporate a suite of system control peripherals, for example, real-time clock, multi-function timers, watchdog timer and bi-directional flag pins. But such a design should also include several high-speed interfaces to move data quickly through the part such as PCI, asynchronous/synchronous memory controllers, USB, and parallel video interfaces, coupled with numerous DMA channels that facilitate efficient use of the high-speed DSP core's signal processing capabilities.

Control of power dissipation has long been a feature of embedded controllers. However, when the system requires DSP functionality as well, the power choices have been less than ideal. If discrete microcontrollers and DSP chips are used in power-sensitive applications, a separate switching regulator must often be provided for each one, because the core voltages of the two devices frequently differ. This results in decreased power conversion efficiency and an increased design footprint, ultimately increasing layout complexity and solution cost. Moreover, when separate MCU and DSP cores are combined on one chip, the power solution is inherently non-optimal, because it must service the needs of two completely independent processors with different loading profiles.

In an appropriately designed unified DSP/MCU combination in which a dynamic power management (DPM) subsystem has been incorporated on chip, only one processor architecture is present, effectively reducing power consumption by at least half. Beyond this a combined architecture allows the incorporation of several intrinsic power modes to support a range of system performance levels. Additionally, clocks to unused peripherals and L2 memory can be selectively disabled. The PLL frequency can be adjusted over a wide range (typically 1 to 31 times ) to satisfy stratifications in DSP/MCU processing needs. Finally, the voltage can be adjusted — either externally or through an integrated switching controller — to offer exponential savings in power dissipation.

For reasons of system cost, development ease, parts procurement and upgradeability, designers are trending toward the use of a single-chip solution for embedded signal processing solutions. This single chip must perform DSP and MCU functions equally well, which necessitates a cohesive processor architecture. The challenge facing MCUs is that it's easier to incorporate MCU functionality into a high-performance DSP core than it is to do the opposite. Today a unified DSP/MCU platform already exists which will service many applications where both an MCU and DSP are presently used.