Times have changed. Today’s signal processing software developers expect—and require—much more help from their tools. The best tools have sophisticated, specialized features tuned specifically for developing signal processing software. Developers are increasingly relying on these features to help them write and optimize their signal processing software more efficiently. As a result, engineers today consider software development tools to be as important—or even more important—than processor architecture.

Complicated Apps and Architectures
Two key changes have caused software development tools to become critical. First, signal processing applications have become much bigger and more complex, making it impractical to write full applications in assembly language. Thus, good compilers and other high-level language tools have become essential.

Second, the processor architectures used in signal processing applications have become much more complicated. Today’s processors often execute multiple instructions per cycle. They have deep pipelines and multi-cycle instruction latencies; complex, multi-level memory architectures that may include dynamic caches; and a range of co-processors and smart peripherals. These processors are much more challenging software targets than the comparatively simple DSPs of a decade ago.

The increasing complexity of processor architectures is significant for signal processing software developers, who tend to work “closer to the metal” than other programmers. Signal processing applications generally have to be highly optimized to meet demanding speed, cost, and energy constraints. As a result, programmers must become intimately familiar with the processor’s architecture in order to develop tight, well-optimized code. The more complicated the architecture, the more complicated the programming and optimization effort. Good tools can make the difference between meeting key application constraints in a timely way and not.

How Applications are Developed
When a new signal processing application is developed, the programmer typically starts off by working in C. (For a discussion of C and other languages used in signal processing software development, see “Languages for Signal Processing Software Development.”)

Then the programmer evaluates the performance of the compiled code, which will almost certainly not be good enough to meet the constraints of the application. At this point the programmer may spend some time on C-level optimizations, trying to help the compiler do a better job. Or she might jump directly into assembly code. In either case, the programmer uses an iterative process of refining the code (whether in C or assembly), debugging it, and profiling it to identify bottlenecks.

The typical flow of signal processing software development is shown in Figure 1 along with the tools commonly used in each step.