Control and signal processing: Can one processor do it all?

The trend toward aggregating multimedia applications into a single device supporting high-speed wired and wireless communication is driving a tighter coupling of control- and signal-processing requirements into contemporary system designs. On the other hand, primarily control-oriented applications, such as digital-motor control, robotics, and hard-disk controllers, are benefiting from access to DSP operations that speed math-oriented processing and allow more precise and sensorless control designs. Although control-oriented applications typically need fast interrupt response and an ability to efficiently process bit-level control and status information, signal-processing applications require continuous number-crunching performance with some limited I/O capabilities. The proliferation of systems that can benefit from mixed control and signal processing have spurred numerous competing architectures to meet designers' needs.

These new system designs require quicker implementation of both real-time control and signal processing at a lower cost than did previous designs. The potential advantages of a single device's performing real-time control and signal processing are reduced board space, lower system power consumption, lower system cost, more headroom for additional functions, and simplified system development. However, with device densities and resource integration increasing, a single device is not restricted to a single increasingly complex processing core. Rather, it can consist of multiple homogeneous or heterogeneous processing cores. Unfortunately, integrating multiple processors onto a single device does not greatly simplify software complexity. Therefore, it is important to consider how using single-threaded rather than multithreaded software will affect your design in mixed control/signal-processing applications.

Viewing these extended processors as stopgap measures to address an industry-capability inflection point, processor vendors, such as Analog Devices with Blackfin, Infineon with TriCore, Microchip with DSPic, Motorola with DSP56800, and STMicroelectronics with ST100, have developed unified architectures, or microsignal processors, to better optimize control and signal processing in one instruction engine. These architectures go beyond just tacking on a MAC-execution engine and include other DSP capabilities, such as multiple bus and memory structures and special-address generation. However, these blended processors must often yield to a pure DSP implementation for the highest performance signal-processing applications.

Until recently, integrating a dedicated microcontroller and a DSP into your design has meant using multiple devices or building your own integrated device. Standard dual-heterogeneous processor devices are now available; Texas Instruments' C5470 integrates a C5000 DSP and an ARM7 processor core into one device. Another way to address mixed control/signal processing is to integrate dedicated hardware accelerators and peripherals with your processor core. Each of these approaches address mixed control/signal processing to varying degrees and with different trade-offs (see sidebar "Different purposes").

As software development and maintenance consumes an increasing share of a design's life-cycle time and budget costs, software complexity directly drives a design's time to market and ability to adjust to market shifts. The speed of robust software development, ease of maintenance, and simplified reuse in succeeding design generations are critical considerations in choosing a processor approach. Using a single instruction engine is simpler than using multiple instruction threads, especially heterogeneous ones. But other considerations beyond application-performance requirements—such as tool maturity, code legacy, and your engineering team's experience with an architecture—can drive your processor decision.

Designers tend to choose components they are familiar with to minimize a project's risk. An engineer will favor a microcontroller that has the necessary features and memory to perform control tasks and provide enough headroom to satisfy the signal-processing requirements, especially if he or she is familiar with the development tools or the processor. Likewise, a DSP-software engineer will include control code in a DSP instruction stream as long as it does not compromise the signal processing. A designer will consider an unfamiliar unified processor or a complementary DSP or controller only if the project's control/signal-processing requirements exceed the preferred architecture's capabilities. What makes a DSP or microcontroller unfamiliar to a software engineer?

Software engineers working with microcontrollers develop an expertise in sequential processes, usually program in C, work with mature and complete development tools, rely on an RTOS to abstract and manage the low-level interaction with the hardware, and have access to a variety of reusable software modules. In contrast, software engineers working with DSPs develop an expertise in algorithmic processes, usually program in assembly language, work with younger tool sets than microcontrollers, are intimately familiar with the low-level hardware, cannot afford inefficiencies from using an RTOS, and generate the signal-processing code on a project-by-project basis. DSPs have multiple buses and memories and many specialized registers that complicate compiler-code generation; microcontrollers have more general-purpose, register-friendly architectures. Control processing is characterized by burst processing; signal processing is continuous and sustained. Additionally, signal processing requires more knowledge of mathematical techniques, such as DFTs, FFTs, digital filtering, and convolution. These differences were tolerable while signal processing remained a niche discipline, but signal processing is moving into the scope of many more applications that will require more software engineers to be familiar with signal processing. Unfortunately, most software engineers are more familiar with microcontrollers than with DSPs.

Many DSP vendors are investing significant resources in their contemporary DSP architectures to bring DSP development tools on par with microcontroller tool sets and expand the number of engineers that can effectively program DSPs (Reference 1). Although these architectures prioritize the need for efficient compiler-code generation, technical, business, and cultural barriers minimize the adoption of C coding for signal processing.

DSP compiler code is considered good if it can reach 80% efficiency when compared with hand-optimized assembly (see sidebar "Optimizing your C"). This practice conflicts with DSP-programming practices that push the mathematical processing to the processor's limits and cannot afford such inefficiency. Complicating compiler optimizations, the standard C specification does not accommodate key DSP architectural features, such as fixed-point arithmetic, divided memory spaces, and circular buffers. Compilers can support some DSP characteristics, such as hardware loop registers and constraints on the register set, without inclusion in the C specification, but examining three approaches to implement fixed-point arithmetic in C illustrates the trade-offs and impact to compiler-code efficiency and the software engineer's effort. One method—mapping fixed-point types onto integer types—prevents the compiler from optimizing fractional arithmetic and places the burden on the programmer to keep the notation unambiguous and to manually manage the scaling. Another method uses abstract data types to encapsulate fixed-point types, but the function-call syntax can complicate arithmetic expressions and incurs non-value-added-procedure overhead. Last and critical for the compiler to provide optimizations, a language extension can add the fixed-point data type to the specification.

Proprietary intrinsic functions provide a mechanism for language extensions, but they complicate portability issues because they are architecture- and compiler-specific. The ISO (International Organization for Standardization) is considering the DSP-C specification to standardize language extensions, and a number of DSP vendors have adopted the specification for their own processors and tools (Reference 2). Unfortunately, specialized DSP architectural optimizations are not universal, and standardized extensions will not eliminate the use of proprietary intrinsics to accommodate them.

Aside from whether a compiler can produce efficient code, a more subjective but significant barrier to adoption of compilers for DSP programming is the inertia of the prevailing engineering culture. Assembly programming is the status quo, and compiled code needs to prove itself against the perceptions and prejudice that earlier DSP compilers and tools acquired. If signal processing were not expanding into so many diverse applications, the cultural barrier would be insurmountable. Fortunately, 20% of the embedded code often accounts for 80% of the execution time. Focusing your low-level, assembly-language talent at this critical 20% of the code opens the door for compilers and development tools to address the remaining 80%, helping to balance available experienced DSP software engineers, time to market, ease of use, and maintainability.

Software is a critical-path item in embedded designs. Software engineers view the system differently from hardware engineers in that they target an instruction set, an RTOS, or both. Using different languages, or even just variants of the same language, adds to the software complexity and affects function partitioning and software reuse. With software making up an increasing share of development time and budget, it is critical to consider whether a project should use one or two software-development teams. You also need to consider whether one development tool set is sufficient how the control and signal-processing tasks communicate and synchronize how the project can leverage legacy code; and the challenges to system integration and debugging.

Generally, but especially for systems with no legacy code to contend with, single-threaded software development is easier than multithreaded software development. Unified architectures present an incremental increase in processor features that make it easier for designers to ease into signal processing with formerly control-only applications. Unified instruction engines give engineers immediate access to both control and DSP functions under a single memory map and a single set of tools and reduce asynchronous threads that simplify interprocess communication. Data and time dependencies are easier to see in a single-threaded implementation. An RTOS plays an important role in single-threaded implementations, managing scheduling for high-latency/low-priority through low-latency/high-priority tasks. Unified instruction architectures simplify system integration, because all of the software targets the same instruction set, and one tool set supports all debugging.

Dual-heterogeneous core systems are more complex than unified architectures. Designers must obtain and learn two languages or variants as well as the idiosyncrasies of two tool sets. Some development environments help simplify this situation by providing a "shell" around the two tool sets and imposing a consistent interface and command structure. Unlike unified architectures, in heterogeneous core implementations, no immediate access exists between the microcontroller and DSP; developers must build the interprocessor-communication mechanisms and protocols. These mechanisms can employ semaphores through shared memory or link ports designed for interprocessor communication. Processing resources are separate and exclusive between the controller and the DSP with some shared resources, such as small blocks of memory. The controller may still employ an RTOS, but the DSP will usually gain no direct benefit from it. It is more difficult to use and even more challenging to emulate conventional debugging techniques to simulate coupled heterogeneous-processor architectures. A dual-processor configuration enjoys a degree of autonomy between the instruction threads so that software changes on one processor may have little or no effect on the other processor. Changing the user-interface code in a dual-configuration system rarely impacts the signal-processing thread; this situation is less true for single-threaded implementations.

Will simpler, single-threaded, unified architectures replace dual-heterogeneous processor implementations? Realize that unified architectures must balance features and make trade-offs to deliver good performance for both control- and signal-processing capabilities. Unified architectures require higher clock rates, because they must do the work of two processors. In a dual-processor implementation, you can independently clock each core at the rate the application requires, and you can select each core for best of class for each type of processing. Single-instruction-issue, unified architectures, by definition, leave the computational engine idle while the control code is executing. Therefore, the clock rate must be higher than just the sum of the dual-clock approach. Higher clock rates affect power consumption and may be inappropriate for power-sensitive applications. For high-performance signal processing, the bus and memory architecture must be able to continuously feed the computational engine so there are no stalls. In this situation, just adding a MAC to a microcontroller becomes a weaker option as performance thresholds move forward. Give attention to your preferred processor's road map and how the architecture will accommodate the higher signal-processing rates your application demands. If you are adding signal processing to a control-oriented application and a unified processor can grow with your performance requirements, then it makes sense to leverage your company's legacy microcontroller code and the control-coding experience of your engineers with a unified control/signal processor. Likewise, if your application pushes the edge of DSP performance, and the signal and control processing are loosely coupled, you will probably better benefit from a dual-threaded configuration.

Unified processors do not eliminate the need for integrated multithreaded software-development tools. Using multiple unified processors in a design can address some of the clock-rate and performance constraints by assigning one of the processors as the signal processor and the other as the host controller. Because they are identical devices executing the same instruction set, the processors present an opportunity to rebalance software loading that does not exist with heterogeneous processors. Another example of using a unified processor in a multiple-system is to initialize and supervise an array of DSPs. In this case, the unified processor can act as the host controller with some light but tightly coupled signal processing, whereas the DSP array handles the autonomous, heavy-duty signal processing.

The only way software can continue to provide more functions in less development time is through heavy code reuse, more analysis, and more assisted decision-making from tools earlier in the design cycle. Your ability to divide a problem into manageable parts depends on your ability to glue solutions together, and development tools can assist if they mature to encompass a broader view as systems continue to increase in complexity. Today's software-development tools are becoming more multiprocessor-aware for debugging, but that awareness does not extend deeper into the development cycle. Today's multi-processor-aware debuggers are incomplete; they still have trouble with intermixing trace buffers for each processor in the system. When a problem exists in the system, it is essential to have a coherent and synchronized snapshot of each system component to track down the origin of the trouble. Multithreaded software development, even for homogeneous processors, is still a technically demanding, manual process. Getting to tool-assisted (versus automated) multithreaded software development or multiple-heterogeneous RTOSs is a huge challenge that is still an academic exercise.

Whether the software is single-threaded or multithreaded, there is only one system program. Managing the software complexity is an issue of system integration. Tools address DSP-software development; controller-software development; system integration, including shared resource arbitration; verification tools; and production-testing tools. Little integration and two-way interaction exist between these tools. The efforts to make C programming useful for signal processing is a step toward a consistent high-level language that tomorrow's tools can leverage. Academic discussions say that the way to meet tomorrow's complex design requirements is to reveal the details of the hardware resources. The reasoning is that, as clock cycles get faster, you can no longer reach every corner of a chip in a single cycle, and it grows increasingly difficult to hide that latency from the software.

It is hard to see these processor architectures converging on a single approach when you recognize that they exist in response to widely varying application-specific constraints of performance, power, size, cost, and ease of use. A system- rather than component-level perspective is a key driver for design decisions. As an example, deciding whether to go with single-threaded or multithreaded programming depends heavily on your application requirements for performance, time to market, software maintainability and reusability; your company's engineering experience and development infrastructure; and system cost.

Author Information

Technical Editor Robert Cravotta's experience with multithreaded control/signal-processing development includes dynamically tunable laser-sensor applications and autonomous spacecraft that uses vision processing to close the guidance and navigation-control loop. You can reach him at 1-661-296-5096, fax 1-661-296-1087, e-mail rcravotta@cahners.com.