Software compatibility wasn't always a high priority for DSP vendors. Back in the '80s and early '90s, most new DSP architectures were not compatible with their forebears. Two key factors began to push DSP vendors to rethink this issue. First, signal-processing applications grew larger and more complicated, making it more difficult to port code between incompatible processors. It's one thing to rewrite application software from scratch when the entire application consists of 1,000 lines of code; it's entirely another to do so when the application comprises tens of thousands or even millions of lines.

Second, general-purpose processors (GPPs), such as Pentium-class chips and ARM cores, became increasingly competent at signal-processing tasks. For some applications the GPPs offered an attractive alternative to DSPs, particularly because general-purpose processors-unlike DSPs-usually maintained software compatibility, typically at the binary level, among successive processor generations.

To meet their customers' increasing desire for compatibility and to avoid being supplanted by GPPs, DSP vendors have focused significant attention on software compatibility in recent years. This is a good thing for all concerned. A troubling development, however, is the vendors' sometimes loose interpretation of "compatible."

Texas Instruments Inc., for example, characterizes the TMS-320C55x as assembly-source-code-compatible with the predecessor TMS320C54x. In fact, typical assembly code written for the TMS320C54x requires significant rework to function correctly on the TMS320C55x. This is particularly true for optimized algorithm inner loops, which are likely to rely on features of the TMS320C54x pipeline that are not maintained in the TMS320C55x, and for I/O-related code, such as device drivers.

Similarly, Analog Devices Inc. has made intrafamily changes in the instruction sets and microarchitectures of its ADSP-TSxxx and ADSP-BF53x that limit compatibility within those families. Some instructions can produce different results on the ADSP-BF535 than on other ADSP-BF53x family members. You won't find prominent warnings in vendors' press releases about such exceptions.

It's good to see DSP vendors paying attention to compatibility. But DSP architectures still have a way to go to achieve the level of software compatibility long offered by GPPs.

Jeff Bier is the general manager of Berkeley Design Technology Inc. (www.BDTI.com), a DSP technology analysis and software development company. Jennifer Eyre of BDTI contributed to this column.