The use of DSPs has greatly expanded beyond military applications and scientific experimentation in university labs. DSPs are integral to many applications, including real-time motor control, digital-audio and imaging, wired and wireless broadband networks, and telecommunications. As DSPs continue to deliver more power at a lower cost, it becomes cost-effective to consider them for new applications that would benefit from improved self-diagnostics, failure management, and sensorless algorithms. The upshot is that a flood of new applications can cost-effectively benefit from a DSP with each succeeding processor generation. DSPs are complex and can be poor targets for compiled code that require hand assembly to harness the maximum performance they are capable of, and skilled DSP programmers are in limited supply to support all of these potential development opportunities. DSP and tool vendors have not missed this trend and have been investing to accommodate it.

One strategy for encouraging more people to become DSP-proficient is to introduce them to DSPs earlier, such as during their undergraduate studies or even during high school. Businesses are promoting embedded programming and signal processing as engineering curricula through donations of training and development equipment to school faculty, educational discounts on tools, the development of textbooks that include signal processing, undergraduate embedded-design competitions, and conferences that aim to bring together the educational and DSP communities. Besides the opportunity for a larger pool of DSP-proficient people, this strategy moves the initial learning curve for embedded design and signal processing out of the commercial environment, reducing the time it takes to bring new developers up to speed.

Just increasing the talent pool is not enough to meet development requirements and shorter time-to-market pressures. Excellent development tools are in high demand, because they are critical for increasing engineering design efficiency and decreasing the time to market. This situation is especially true for engineering staffs that are unfamiliar with emerging technologies but must quickly learn and apply them. Processor vendors have invested significantly in acquiring or developing their own integrated-development tools, such as Analog Devices' VisualDSP++, Texas Instruments' Code Composer Studio, ARC's Metaware and Precise, and Motorola's Metrowerks, or have partnered with third-party development-tool vendors, such as Green Hills, Tasking, and Wind River.

Tools have been evolving beyond independent assemblers, compilers, and debuggers, and vendors are packaging these basic components with emulators, behavioral and cycle-accurate simulators, code profilers, and coordinated multiprocessor and heterogeneous-processor debugging within an IDE (see sidebar "Multicore or hybrid?"). An IDE imposes a consistent personality for designing systems (look and feel, visualization tools, command structures, terminology, and documentation) that abstracts the processor target. Using a consistent tool set across projects means that programmers have fewer things to learn and provides the opportunity for reuse of legacy assets in every project, which can significantly reduce development effort. The significance becomes apparent when a design trade excludes a processor from consideration because the tool set that the team uses does not support it.

Complementing the IDE, development suites are including access to BIOS, RTOS, demonstration kits, project management, and libraries of optimized application-specific functions. Demonstration kits are crash-study learning devices that allow engineers to integrate new support technologies, such as connecting devices to networks, into their applications. These kits include working boards, schematics, software, and notes explaining how they work so that engineers can use or modify the circuits to meet their applications' needs. Project management ranges from version control to access control and can even support large, geographically separated team collaboration over the Internet. Library functions supplied by tool vendors and third-party developers are valuable for those necessary functions, such as standard encryption and audio algorithms, but are not the core competency on which designers should focus. Frameworks and algorithm-coding standards are strategies for modules delivered as object code and not source code to simplify their integration into an application. Modules following these guidelines can shorten the time and reworking required because system integrators know the assumptions that the module made about the underlying software foundation.

A goal during development is to get the application running at sufficient performance with minimal effort, materials, and time. As processors continue to increase in performance and decrease in cost and as time-to-market pressures for application development become a first-order consideration, programming with compiled languages, such as C and C++, can deliver better coding efficiency and maintainability than assembly coding. Even though C compilers for DSPs have been around for many years, they have had limited efficiency because the processors have lacked those things that make compilers effective, such as instruction orthogonality, and their register files are too small. DSPs with multiple cores or functional units are making stronger compilers a necessity. Imagine the complexity of manually writing assembly code to maximize the performance of the eight functional units in a TI C6x DSP.

A convergence of DSP architectural design and tool design is happening, creating processors and tools better suited to compiled-application development. Designing development tools and processor architectures separately is an open-loop design process and generally results in hardware-centric instruction sets and datapaths that may not provide a target that a compiler can effectively optimize. In open-loop designs, the architectural designers may write prototype, hand-tailored assembly-code segments to determine the processor's peak performance. Unfortunately, these code segments are rarely indicative of compiled-code performance.

Closed-loop-processor design integrates algorithmic and heuristic approaches in an iterative process stressing a system-design approach (Figure 1 ). The compiler team is in a better position to generate code that customers will use and determine the peak performance that they will experience. Designers for the targeted applications can contribute to application-specific extensions. The compiler and application teams can provide insights about, for example, how often you use each instruction, which opcodes the instruction set should include, whether the instruction interactions hinder compiler optimization, whether instructions efficiently use the datapath, which instruction combinations are necessary to improve parallel flow, and the optimum number of registers. The teams can then jointly assess what kind of changes in the hardware and compiler will better meet the requirements and perform another iteration. Processor families, such as Analog Devices' Blackfin DSPs, TI's C6x DSPs, and Microchip's dsPICs, benefit from a closed-loop design process.

A closed-loop-design process not only yields a processor and tool set that better satisfies application requirements with compiled code, but also immediately provides production-quality tools at release of the new processor. Such tools are critical to accelerating the acceptance of the technology into the industry. As the closed-loop-design process matures, the market may create pressure for the design team to consider how the architecture-design decisions affect tools for automating the emulation or porting of legacy code to the new processor.

Just because you wrote your legacy code in a compiled language does not mean that porting it to a new processor is merely a matter of recompiling it, or that a new development tool will support your code out of the box. You still need to hand-optimize by using custom compiler extensions and intrinsics to tell the compiler how to produce better-performing, target-optimized code. Unfortunately, hand-optimizing and -tuning your source code may create a conflict with the code's portability. On the other hand, optimized C code is faster and easier to write, maintain, and eventually port to another target than hand-coded assembly.

The likelihood that an application will eventually migrate to another platform is increasing, especially when you consider the rates at which processor performance is improving and the cost of parts is decreasing. Additionally, the scale of emerging applications using new technologies further exacerbates the support costs for the continued use of older processors and tools. Designing with the goal of reusable software components for future applications is a strategy for simplifying portability in future migrations. Reusable software should have well-defined interfaces to simplify integration with other software modules, be re-entrant, maintain as much processor independence as possible, and encapsulate processor dependence to support portability. Software is only as reusable as tool technology and programming practices allow it to be.

Even if the software is 100%-portable code from which the target compiler can generate acceptable code, other considerations can affect an application's migration. For example, when the source code is unavailable, such as with a vendor-supplied object module for a purchased algorithm, you must still obtain a ported version of the module or a license to the source. Another consideration is that the quality of source code ranges from ported generic code from another platform to hand-optimized code. Today's DSP compilers strive for 80 to 90% efficiency of hand-coded assembly when compiling hand-optimized source code. Their challenge is to deliver comparable efficiency with generic code that will support new companion tools using code generators to open the door for people who can complete a viable DSP design.

As embedded systems become faster and more complex, the software-development-and-integration effort is taking more of the application-development time to market. All that new and available processor performance encourages the inclusion of many more lines of code to add new capabilities with each application. Evolving system-level and intelligent-DSP-development tools are crucial to making products with increasingly more complicated embedded functions easier to develop and more quickly bringing them to market.

The Mathworks' developer's kit for Texas Instruments' DSP is a plug-in to TI's Code Composer Studio and is an example of a system-level design tool that plugs in and integrates with a downstream software-development tool. This combined tool set represents an approach to expanding the engineering pool for DSP development to include people without traditional programming backgrounds. The integrated set of tools provides a bridge between algorithm design and software implementation by invoking an automated code generator to convert system-level models to C source code that can be compiled and then debugged on a target processor using either tool for visualization.

As DSP compilers continue to mature, tools are becoming available to help developers enhance their source-code efficiency without an intimate understanding of the target's underlying architecture. An example is Code Composer Studio's profile-based compiler. Using programmer-supplied criteria, the tool builds and profiles the optimizing options, such as unrolling or restructuring loops, pipelining loops, or serial loop execution for the software's key functions. The results are displayed as a plotted curve that represents the different trade-off values for code size and performance (Figure 2 ). The optimum combinations of small code size and low cycle counts lie closest to the origin. Programmers can select the appropriate trade-off from the curve for the design's requirements, such as the fastest execution within a specific memory size, or the smallest code for a given performance profile.

Some tools can provide greater information and recommendations for tuning source code, providing specific feedback—especially with loops—when small changes can make a big difference in performance. Eventually, compilers will query programmers for more information that will help optimize the code. For example, suppose a compiler optimization could use a status or mode bit to communicate with a different routine. The compiler ordinarily cannot use the bit because its value is not guaranteed to remain unchanged during runtime. With an interactive query, the compiler might confirm that the programmer is not using the bit, so it can use the status bit for optimizations before finishing compiling.

As DSP architectures become more complex to obtain higher performance, being able to efficiently compile the growing sea of C source code will become more important. The closed-loop processor-design process integrating the DSP-architecture and -development tools is a vehicle that better uncovers architecture- and tool-specific optimizations that can provide the necessary gain in compilation efficiency. Finally, Moore's Law continues to lower the threshold for an acceptable level of compiler efficiency for many applications, opening the door for even more companion tools that move the coding process from the processor level to the system level.

Author Information

Technical Editor Robert Cravotta developed assemblers and compilers in the early 1980s. Graphical debugging and data visualization has changed a lot from the days of the text-line-console output. You can reach Technical Editor Robert Cravotta at 1-661-296-5096, fax 1-661-296-1087, e-mail rcravotta@cahners.com.