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]

Should You Reuse RTL?
by Tom Dewey, Mentor Graphics Corporation

Introduction
Ever since hardware description languages (HDLs) were first put into use to specify electronic designs, designers have recycled code. New insights into the use of these HDLs for design are gained by copying and modifying – with the requisite permissions of course – existing examples. By placing that code into the new designs, everybody saves time since designers do not needlessly re-invent an existing block of code. Someone spent significant time and energy to design that code block and other designers rightfully want to leverage that work. Until the entire design community, standards groups and EDA vendors can deliver a methodology and supporting tools that enable designers to create code for reuse in an automatic and efficient manner, the recycling of existing code will certainly continue. This recycling occurs over a whole spectrum:

• Cutting & pasting a single routine or function
• Copying existing simple blocks or modules into the new design
• Copying large design blocks and building around them with new blocks
• Building around an existing platform by adding a few new blocks

In all these cases, code is recycled that probably was never originally meant to be used "as-is" as reusable code. This implies that there is some work involved in recycling the code. The key to recycling is to quickly figure out how much work is required in order to decide whether or not recycling is practical. [more]