Buying unassembled toys for your kids is always risky. Although the package may assure you of "quick and easy assembly," those of us who have had to put the darn things together know better.
Buying unassembled toys for your kids is always risky. Although the package may assure you of "quick and easy assembly," those of us who have had to put the darn things together know better. Having all the pieces is not the same thing as having, say, a tricycle that actually works.
Signal-processing applications are the same way. Even if you have all of the major intellectual-property (IP) blocks you need to build a complete application, you can't assume that getting your product up and running will be simple. In fact, instead of being like my tricycle example, putting together a modern signal-processing application is more like having to assemble a jet aircraft-without instructions.
These days, many signal-processing application developers prefer off-the-shelf software components for most of the application and reserve expensive inhouse development for a few key features that will differentiate their product. That is a sensible strategy, but it has implications for the type of expertise required to pull the product together.
By using off-the-shelf IP, companies are able to reduce the amount of engineering time devoted to implementing, optimizing and testing software components. What system developers often fail to realize, however, is that they still will be faced with complex design and integration challenges, many of which lie beyond the capabilities of typical DSP engineers.
A key issue that will need to be addressed is how the various components will interact with one another. How will the data be buffered? How will functions be synchronized? How will real-time constraints be met? How will signal fidelity be maintained? How will the system be tested? Whether those questions are hard or easy to answer depends to some extent on the quality of the available software components, and whether pieces from various vendors adhere to a consistent set of interoperability guidelines.
Chip, IP and tools vendors can help ease the process by providing additional infrastructure, such as reference designs. But, even in the best case, putting together a complex system requires system architecture skills-which are not the same as DSP programming skills.
As DSP systems become more complex and increasingly rely on off-the-shelf software components, system developers must recognize the subtle workload shift from low-level coding to high-level system integration.
Don't underestimate just how hard it's going to be to put all those pieces together and get the darn thing running.
Jeff Bier is the general manager of Berkeley Design Technology Inc. (www.BDTI.com), the DSP technology analysis and software development company. Jennifer Eyre of BDTI contributed to this column.