Recently I wrote about how the term “DSP” seems to be losing its cachet, and people are starting to use terms that are more application-specific. Instead of “DSP processors,” there are now “digital signal controllers,”  “multimedia processors,” and “video processors,” for example. These terms are fine with me.  But there’s one that really annoys me: “application processor.”

Digital video has become a killer app for signal processing technologies, and video analytics—that is, analysis of digital video to identify specific events or characteristics—is quickly becoming a significant driver in digital video.  Video analytics isn’t one of those solutions looking for a problem; it has an enormous range of potential applications, both commercial (such as intelligent surveillance and traffic monitoring) and military (such as target detection and tracking).

Late last year Hewlett Packard announced that it was exiting the digital camera market, citing a lack of growth in that business sector.  But just because HP has quit the camera business doesn’t mean it’s abandoning all of its digital camera technologies; the image processing algorithms originally developed for HP’s digital cameras will now be incorporated into cell phones, enabling users to create high-quality prints from pictures taken with camera phones.

Digital signal processing algorithms are increasingly important in an expanding range of embedded systems. For example, compute-intensive multimedia functions are finding their way into applications from toys to appliances to telephones. As a result, a growing number of system developers face a daunting challenge:  delivering implementations of DSP algorithms that are sufficiently optimized to meet demanding MIPS, memory, and cost requirements while also meeting aggressive schedules.

If you were getting ready to buy a new high-end camcorder or a new car, chances are you’d spend some time reading independent reviews. Maybe you’d pick up a copy of Consumer Reports or Road and Track. Perhaps you’d scan Amazon.com for user evaluations.  Whatever. The point is, you probably wouldn’t just make your choice based on the vendor’s marketing claims, right?  

Fifteen years ago DSP engineers expected to write and optimize most of their software in assembly language, and they did it on DSP processors with obscure and highly specialized instruction sets.  Back then, compilers for DSP processors were inefficient and couldn’t use many of the processors’ specialized performance-improving features. If you wanted to use bit-reversed addressing or circular buffers or fill delay slots, for example, you’d have to write that code yourself. 

When my partners and I founded BDTI back in the early 90’s, “DSP” was in the process of becoming both a hot technology and a widely used abbreviation. The abbreviation meant two distinct things: digital signal processing, and digital signal processor.  You could usually figure out which one was meant by the context, but in some ways they were interchangeable—if you were doing digital signal processing, you were probably doing it on a digital signal processor.