|
Domesticating DSP
The Shifting Sands of Datapath Design
In the good old days, (those would be the EARLY 2000s) digital signal processing (DSP) was a well-behaved wild animal. It stayed outside in the pasture, grazed off the land, and never harmed the house pets. DSP didn't
disturb the neighbors and didn't bite unless provoked. If we had a big, complex system, we often hired a specialist, a kind-of DSP
whisperer, to handle the care and feeding of our little DSP. He knew all sorts of tricks and techniques for training and taming the
little fellows. He spoke MATLAB. He was fluent in DSP processor assembly. He was one with the s-plane.
Lately, though, we've needed DSP more often in our day-to-day design lives. We've been inviting DSP into the
yard, and even into the house occasionally. Increased integration, tighter power budgets, greater cost consciousness, and more
performance-hungry algorithms have rallied us to rethink and de-segregate the DSP-like functions in many of our system designs. The
tighter relationship between core applications and massive streams of data in applications such as video and wireless have caused
us to call into question the practice of throwing down a special-purpose processor and phoning in the DSP guy. We have to learn to
handle DSP ourselves.
If you're a digital designer, you may have forked away from the path of the continuous-looking mathematical
function at about the same time that Laplace transforms kicked in. Your RTL would never betray you like that. Logic design was
domesticated, domain and range both under control, discretion assured - nothing imaginary going on. You could work away with your
Karnaugh maps, truth tables, and bubble diagrams safe from those scary squiggly lines of frequency response and protected from your
polynomial paranoia. [more]
|