The evolving landscape of digital signal processing

Is the stand-alone DSP a dying breed? It may not exactly be dying, but the DSP is not front and center as it used to be. In 2006, EDN changed the name of its annual DSP Directory to the Digital Signal-Processing Directory (Reference 1). This subtle change recognizes that digital-processing options have commercially expanded beyond just software-programmable-processor devices and core offerings to include other options, such as programmable fabrics, IP (intellectual-property) blocks, and mixed-processing SOCs (systems on chips). These processing options complement as well as compete with each other because each faces a different set of constraints (Reference 2). Signal processing involves mathematical manipulation for transforming—using filtering, Fourier transform, compression, decompression, synthesizing, recognizing, enhancing, encoding, decoding, and other methods—a set of data or a stream of signals. The continual advancement of microprocessors and growing base of developers who need this technology are leading the trend away from stand-alone DSPs.

The war between FPGAs (field-programmable gate arrays) and DSPs has died down over the past few years. Both camps have realized that they best serve different types of problems and that it is common for an FPGA and a processor to be operating side by side in one design. FPGAs can leverage arbitrarily wide signal-processing algorithms acting as hardware-acceleration blocks. This ability gives them an advantage over DSPs when the signal-processing algorithm is sufficiently wide enough that it can efficiently use more than the available processing units in the DSP. However, working with FPGAs is more complex in part because of their hardware-design flow. For example, Xilinx is focusing on making the FPGA easier to use, according to Tom Hill, senior marketing manager for DSP solutions at the company. Xilinx accomplishes this task by abstracting the complexity of the design process, including accommodating a C-design flow and C-synthesis tools for hardware and software partitioning.

As microprocessors continue to benefit from Moore’s Law, they can incorporate multipliers and specialized circuits, including specialized bus architectures and memory hierarchies, to improve their computational performance. Some of today’s microprocessors deliver good computational performance, low cost, and high energy efficiency. If these parameters are good enough, these microprocessors let designers add and accommodate signal processing in a design—within a single chip. These processors do not necessarily deliver the best-in-class processing performance, cost, and energy efficiency, but they offer other system-level advantages, including bill-of-materials cost savings or a familiar design flow, and can thus be better choices than stand-alone DSPs.

What’s in a name?
As signal processing expands into more applications, ease of use becomes a critical concern despite the fact that designers historically often associate the term “DSP” with complexity. Early DSPs involved architectures that focused on extracting the maximum processing performance rather than on the ease of transforming mathematical algorithms into silicon and software implementations. As these processors evolved and were able to use more transistors with each new generation, they could better accommodate the transformation in various ways. Processors that allow programming in C, for example, help with this transformation.

Consider how Texas Instruments identifies its TMS320C2000 platform. The company once referred to these devices as DSPs with controller capabilities. A few years ago, however, these processors became known as DSCs (digital signal controllers). The company recently removed the C2000 from the 2009 EDN DSP Directory and now refers to it as a real-time microcontroller, even though the underlying architecture has not changed. The explicit focus has changed, however, to making the surrounding development-support environment more comfortable to microcontroller developers.

You may think that manufacturers taking this tack are being disingenuous, but keep in mind that many processor offerings place the focus on the target application and only imply the signal-processing capability. Examples include the Analog Devices Blackfin audio, video, and communications processors; ARM processors with Neon or accelerated multimedia IP; Freescale Power Architecture with Altivec extensions; Infineon TriCore automotive and industrial processors; Intel Pentiums with SSE (streaming single-instruction/multiple-data extensions); Microchip DSPic motor-control and power-conversion DSCs; NXP CoolFlux processors; Tensilica Xtensa audio and video engines; and Texas Instruments DaVinci and OMAP (open-multimedia-applications-platform) processors.

Each of these processors incorporates signal-processing architectural features from which their target application benefits. Application-specific algorithms or signal-processing libraries are available with many of these devices not only to improve time to market but also to enable developers to add capabilities to their designs without becoming experts about the new functions. Processor vendors are bundling silicon and software to simplify audio and video processing and other applications.

Casual-user adoption
Identifying processors by their target application reflects the trend for silicon providers to offer application-targeted products or implemented reference designs that comprise not only the hardware but also the appropriate software components that work with that hardware. Developers can buy or license targeted implementations for a growing array of signal-processing functions, such as compression, audio, and video encoding and decoding. These developers’ focus is shifting from how to build core functions to whether an implementation meets performance, price, energy, time-to-market, and integration goals. Algorithm and system providers who can find the balance between delivering processing performance, energy efficiency, algorithm flexibility, and robust system integration should stand out in this increasingly competitive area.

The signal-processing nature of the bundled software in these offerings is sometimes less obvious. For example, touch sensing is such a popular capability that many processor vendors this year rolled out or updated touch-sensing support for their devices. These packages include processor targets with software and demonstration kits to ease the learning curve for developers trying to use the technology. The developer targets an API (application-programming interface), which hides from the developer much of the complexity of accessing the touch sensors. Managing and interpreting the touch-sensor inputs usually require significant amounts of signal processing, especially with the multitouch products, to filter and calibrate the sensor to deliver a consistent and reliable input source. Processor vendors are building their own in-house touch-sensing expertise and abstracting the complexity from the end developer. This step allows the developer to focus on higher-level interpretations of the touch inputs, such as recognizing command gestures.

This industrywide trend is moving digital signal processing to the level of a deeply embedded technology in which a growing percentage of developers are not concerned with the implementation details of “commodity” signal processing. This trend enables silicon providers to reach the larger set of developers who are not signal-processing experts without encumbering them with the learning curve of implementing these algorithms from scratch. It also makes irrelevant the dirty secret of the most optimized signal-processing implementations—that the software is often hand-optimized assembly or C code with heavy usage of compiler intrinsics to squeeze the best performance from the underlying hardware. Developers can continue to use the familiar C-code design flow for their value-added part of the system without concern for implementing the coding of the licensed, timing-critical “heavy lifting.” It also provides the groundwork for certifying the algorithmic implementations as the silicon providers continue to build their core group expertise.

This emerging abstraction layer helps support the exploding increase in the number of casual users who are adopting signal processing. However, it represents another layer of complexity for the silicon providers’ development support because the power and intermediate users of these processors still need visibility down to the metal to support their innovation explorations. Piergiovanni Bazzana, an application developer at Atmel, describes two of the company’s customers that wanted to employ the same Atmel dual-core microcontroller/DSP processor for the same type of end product. The smaller company wanted to use a single graphical programming tool to develop both the microcontroller and DSP cores because the company had fewer resources to dedicate to the project and was interested in implementing compliant standard algorithms. The larger company wanted separate development tools for each target processor because it not only had more development resources but also planned to incorporate some innovations into its algorithm implementation that required the company’s designers to be able to see deeply into the target system.

Designs that target standard signal-processing algorithms are appropriate for a library approach. The developer needs to read and understand the standard documentation or reference code to understand compliance issues; the effort then becomes a way for designers to optimize their designs to the target architecture. For a given processing option, the silicon provider can amortize its expertise with the signal-processing function and its architecture as a package across several customers. In contrast, designers who are implementing algorithmic innovations must optimize not just the implementation to the target but also the physical phenomena to provide insight in refining the algorithm. In this case, a C-based approach, with compiler intrinsics if necessary, is more appropriate because it provides the flexibility that a library approach cannot.

Necessary skills
Building a signal-processing system requires exploring and refining the algorithm, implementing the algorithm on a target, and specifying and verifying the system-level timing. These skills can reside within a single person or a team. According to Ken Karnofsky, senior strategist for signal-processing applications at The MathWorks, communication among people with any of these skills involves a translation challenge because they each have different natural work products, data, and work flow. Algorithm exploration is math-intensive and requires an understanding of the physical phenomenon that you are modeling. Implementing the algorithm on a target processor does not require the same level of understanding of the mathematics or the physical phenomena. Rather, the developer’s expertise focuses on how to organize and schedule the processing resources to provide robust delivery of good-enough performance and energy efficiency. Verifying the system-level timing requires identifying the various operating conditions that the end system must support for robust operation.

Tools such as The MathWorks’ Matlab and Simulink and National Instruments’ LabView development tools help algorithm developers with the exploration of algorithms with varying levels of abstraction and high-level mathematics simulation (Figure 1). Working at a high abstraction level is generally useful when defining problems and exploring design possibilities. In the LabView example, Express VIs (virtual instruments) present an interactive, configuration-based user interface to, for instance, synthesize test signals, see the result of applying a window, or examine a spectrum. Less abstract tools, such as those from the array/point-by-point library, are more flexible and programmable to enable custom algorithm development and implementation.


Figure 1

These tools are also helping to bridge some of the transitional challenges between algorithm development and implementation by supporting autogenerated code that executes on a target processing board. For low-volume or high-margin applications, the autogenerated code may be sufficient for rapid prototyping or fast time-to-market exploration. Using the autogenerated code on a target board can provide the algorithm developer a more direct understanding of the challenges facing the implementation developer.

Implementing and optimizing the algorithm on the target architecture involves using the development tools the silicon provider supports for the target system. The autogenerated code can assist in comparing the trade-offs among target architectures with the increasing use of compilation-time replacement technology that allows target substitutions to take place. For those algorithms that require special resources to attain their processing-performance constraints, the developer may have to use compiler intrinsics or hand-optimized assembly. Standard ANSI C code does not provide compilers with visibility into dynamic memory usage, so the compiler must make a number of assumptions to generate good code. Compilers are strong on scheduling register and internal-memory accesses because they have direct management over those resources, but they are weak on scheduling DMA (direct memory access) because they do not have complete control over the resources they are accessing. Compiler intrinsics allow the developer to more directly specify assumptions and resource allocations.

System-level timing skills become more important as the system performs more tasks with shared resources. Early DSPs focused on low-overhead looping at the expense of interrupt support. Contemporary processors support many interrupt sources, especially for connectivity capabilities. Signal-processing algorithms are increasing in complexity, including performing processing on a data-point-by-data-point basis, potentially complicating system-timing analysis. Manufacturers are increasingly commoditizing successful signal-processing algorithms and embedding them—whether as bundled software with a silicon target or as licensable software implementations—in the processing components of embedded designs. As this situation evolves, developers will spend more time specifying and verifying the system-level performance and then developing and implementing the algorithms.

The quality of a system depends on the guarantee of the algorithm’s real-time system-level maximum load or worst-case latency. The highest-quality system bases the design on the worst-case path or latency impact and meets the real-time threshold under all cases. A moderate-quality system defines a threshold in which it is acceptable to experience some error and miss the real-time threshold but still recover; the system is robust enough to handle discontinuities.

Gene Frantz, principal technical fellow at Texas Instruments, observes that many DSP users are more inexperienced than their predecessors. This fact should influence how universities teach signal processing. As more signal-processing algorithms become subject to commodity implementations, most designers will find more value in focusing on how to combine the building blocks in innovative ways rather than building all of the blocks from the ground up.
Author Information
You can reach Technical Editor Robert Cravotta at 1-661-296-5096 and rcravotta@edn.com.

References
1. Cravotta, Robert, “DSP Directory,” EDN.
2. Cravotta, Robert, “Tee up your multiprocessing options,” EDN, June 11, 2009, pg 24.

Captions
Figure 1: The stacked blocks represent categories of functions, based on the level of abstraction of their programming interface and number of encapsulated functions (courtesy National Instruments).