Of Forests and Trees and DSP

When Stephane invited me to write a blog for dsprelated.com I immediately came up with a flood of ideas for highly detailed, technical, narrowly focused articles related to the intersection of DSP and control systems.

Then the USENET groups that I frequent received a spate of posts from people that were either asking about how to implement highly detailed, narrowly focused algorithms in ways that were either fundamental misapplications or were flawed because they were having problems with some neglected detail of the application.

So I thought I would rant a little bit about the danger of not seeing the forest for the trees in the way, and of not seeing the trees because you've pulled back far enough to see the whole forest.

Normally when engineers think of digital signal processing, they think of DSP algorithms.  These algorithms are, after all, the fundamental element that makes DSP DSP.  But it is easy, when working on a system that includes a healthy dose of DSP, to forget the system, and concentrate only on the algorithm.  When you do this, you can end up designing a product or solution that has a very good algorithm indeed, yet is, overall, a poor solution to the larger problem you wished to solve.

As a counter example to the above, I present the Korg CA-20 chromatic tuner.  All four of the people in my household are amateur musicians.  When our eldest kid was a bit younger he could understand the notion of having his instrument in tune, and could adjust it, but he wasn't good at identifying whether it was sharp or flat.  So we bought a Korg CA-20 chromatic tuner.

From a consumer's perspective, the tuner is a nifty little box.  One pushes the 'on' button and plays a note.  The tuner tells you what the note is, and it tells you if it is sharp or flat.  From an engineer's perspective it is clear that this thing has a good solid pitch detection algorithm in it -- but just having that DSP portion of the system, while technically impressive, is not even close to sufficient to making the tuner the good product that it is.

What makes that little tuner a good consumer product is the fact that it has the algorithm, a sufficient processor on which to run the algorithm, a good microphone, amplifier, and ADC to present good data to the processor (and hence the algorithm), buttons, a display, and a case that are well laid out and rugged enough to survive handling by children, and a set of non-DSP interface software that doesn't require someone with a PhD in button-pressing to get the thing to cough up the right answers.  To top that all off, the thing is affordable enough that when the first one got lost under the couch for a month, we could easily afford to buy the second one.

The evidence of the USENET postings that I sometimes see (and an unfortunate number of products that I have had to use or fix) is that we DSP engineers are a bit too ready to latch onto an algorithm and run with it, without doing what's necessary to make sure that the algorithm is going to succeed.

A DSP system has to have a sufficiently good algorithm, to be sure.  But this algorithm needs to get good data, which means that if it is part of an overall product you have to verify that the data acquisition portion of the product is good enough -- and if it isn't then you have to assess whether you need to cook up a different algorithm or whether you need to insist on better source data.  A DSP algorithm needs to have sufficiently wide data paths.  I have seen plenty of algorithms that are held back because someone (myself included) did not think about just how wide its data paths needed to be, and starved it of the precision necessary for it to function.  Most fundamentally, a DSP algorithm (once you've written the code with wide enough data paths) needs enough processing power and memory to do its job in the time allotted; use too wimpy a processor and you just can't get there from here.  Finally, the output of your algorithm needs to be treated sufficiently well -- this is easy if the output is digital data, but if you are displaying some information extracted then that display has to look good, and if you are processing audio data then you have to make sure that your output DACs and all the circuitry following is of a quality commensurate with the signal you've generated.

So here are a few do's and don'ts for successful DSP system designs:

Do select the right algorithm.  The algorithm that makes the best academic paper in the IEEE Transactions may not be the best algorithm for you, the same goes for the algorithm that makes a good white paper for some DSP vendor's web site.  Decide what you want, then evaluate all the algorithms you can, then understand them well to modify them if need be.

Don't take things for granted.  Pull back far enough to see the forest (the whole system design), then fly in close enough to take in every tree.  If the system is too large for you to be personally responsible for everything, make sure you can trust the people who are responsible, and think of ways you can verify their work.

Do check word widths.  This may not be everyone's worst bugaboo, but it is certainly one area where I trip up most often.  Remember that floating point math levies an 'exponent tax' -- a 32-bit long fixed point word gives you 32 bits of precision if you use it right, where a 32-bit floating point number only gives you 25 bits of precision.

Don't focus on one part of the system to the exclusion of the others -- the World's Best Graphics Equalizer isn't good at all if the total harmonic distortion of it's output stage is worse than the quantization noise introduced by an 8-bit DAC.

Do pay attention to hardware issues (if applicable) -- good algorithms + bad data = bad application.

Don't forget any one part of the system, even if its not 'sexy' -- a handheld device that shatters when it's dropped from four feed high may have the best algorithms, electrical design and software design, but it'll still be a pain to own.

Do remember that your algorithm only lives in a physical device, and through software that someone writes.  A mathematically correct algorithm that's implemented in software with one dumb bug isn't going to look good, that algorithm with bug-free software that's running on hardware that locks up every three minutes isn't going to look good either.

Do balance your whole design.  One superlative element combined with four good ones may only be good, but at a slight price premium.  Four superlative elements combined with one good one  may still be limited to 'good', but at a big price premium.

That's my rant for today.  Stand by for some excruciatingly detailed treatments of IIR filters, and how to implement digital control systems. 

Sign in