What is a DSP Engineer

Let me digress a bit from the light theory of DSP, which have been discussing till now, to offer a viewpoint on what is a DSP Engineer. I reproduce below, an opinion, which I also hold, to some extent.


Comment What is a DSP Engineer

Feb 12 2008


By Shiv Balakrishnan, Forward Concepts


Once upon a time, DSP stood for Digital Signal Processing. In the late 1980’s, however, our beloved acronym began move inexorably towards meaning Digital Signal Processors. By then of course, TI and other chip companies had spent many millions of dollars in creating a new market segment, so who’s to grudge them hijacking the very end of an old piece of jargon?

Some of us nit-picky curmudgeons, that’s who. My own anecdotal experience is that the field of Digital Signal Processing has lost out in subtle ways. Here’s the background:

In the 1960’s, DSP art developed around two broad areas: digital filtering and FFTs. When someone said they did DSP, you knew what they did. You also knew where they congregated: The International Conference on Acoustics, Speech, and Signal Processing (ICASSP) was the main international watering hole. The ICASSP acronym gives away the dominance of “Acoustics” and “Speech” at the time

You even knew what DSP engineers were reading. Quality textbooks from Oppenheim, Schafer, Rabiner, Gold, Rader, and a host of others joined earlier guideposts like Blackman and Tukey’s “Measurement of Power Spectra.” Other sources of knowledge included the classic Cooley-Tukey FFT paper, Widrow and Hoff’s LMS work, and a collection of seminal work from Bell Labs—the latter including early vocoder work from Dudley and speech breakthroughs from Flanagan’s group. There was quantization analysis (Jackson and many others) and the elegant Remez Exchange-based FIR design work of Parks and McClellan.

Thanks to this training, DSP practitioners had a firm grasp of the signal processing chain. They worked with algorithms, hardware, and software. They understood the interplay between analog and digital signals, and the effects of noise and non-linearity in both domains. Most could recognize when an analog implementation was more efficient—an important talent, in my opinion.

Fast forward to 2008. Acoustics and speech still matter, but there is much more emphasis on multimedia and communications. The hardware options are replete with DSPs, microprocessors, FPGAs, IP cores, ASICs, ASSPs and what not accompanied by a wealth of tools: compilers, debuggers, high-level design tools and more. So what’s the meaning of “DSP” now? What’s our new-millennium DSP engineer doing?

Here are my observations (and I’d love to have them challenged): “DSP” means Processors a la TI, ADI et al. (Note to self: get over it!) A DSP engineer typically does one of the following:

  1. Writes C/C++ code to implement a function (e.g., a Viterbi decoder) on a DSP or core. The engineer then optimizes the code for performance/size/power, sometimes even having to (shudder) write assembly code to wring out the last iota of performance
  2. Architects a hardware block (e.g., Viterbi decoder), implements it in VHDL/Verilog, verifies it, and optimizes it. The engineer checks the RTL against a high-level model (e.g., in MATLAB) as well as the correctness at the logic level with black box testing, test vectors and such.
  3. Architects the system and designs algorithms. These engineers typically use MATLAB and C, and have domain expertise. They usually do not deal with assembly code or Verilog.

Now let me stick my neck out and make some wild generalizations:

Engineers in categories 1 and 2 never use their basic DSP theory after college—not that I can blame them. They can’t tell you why and when an IIR filter might be unstable, or who needs any transform other than a DCT or radix-2 FFT. As far as quantization noise and round off effects are concerned, fuggedaboutit. The systems guy took care of that.

The #3 folks are closest to the DSP engineers of a couple of decades ago, though they tend to be “Architects” or “System Designers” as opposed to DSP programmers. They are also the ones closest to understanding the complete system, although they are lmited by increasing system complexity. Thus one has MPEG engineers, and WiMAX engineers, and Graphics engineers, etc. These systems engineers normally don’t get too close to the hardware in large projects.

Here’s a scenario: the product is a complex SoC or system; the chip comes back and it’s bring-up time. I’m guessing that

  • 70% of the above folks will not be dying to get in the lab
  • 80% will want nothing to do with the hardware
  • 90% will want nothing to do with the analog and data converters
  • 100% will want nothing to do with the RF

Bottom line: complexity and the concomitant specialization have forced most engineers on any large project to limit themselves to a small part of the product or solution. This is not unique to DSP, of course. So who are today’s DSP engineers and which direction is they going?

The answer seems to be: C / MATLAB programmer with some application knowledge. Software skills (compilers, tools, RTOS, IDEs, etc.) help in any job and DSP work is no exception. Knowledge of Z-transforms, FFTs, etc. is optional—there are cookbooks for these things anyway.

So why do I say that the discipline of DSP has lost out? My contention is that if engineers are not fluent in the basics of DSP, perhaps they should not be called DSP engineers. Since it is a bit late for that, maybe we need a better term for those who are concerned with how the bits arrived at the processor and where they are headed.

On the systems issue, this curmudgeon feels lucky to have been able to work on some pretty complex products. I am surprised by one thing: many DSP engineers I have encountered in the last ~15 years in Silicon Valley are not interested (!) in learning the other stuff even if they have the chance. Maybe they’re doing the next big thing that will make today’s DSP engineers will seem as quaintly old-fashioned as I am today.


More later…

Nalin Pithwa

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.