Over the last month I've done a lot of thinking about the development flow for signal processing applications. The more I think about it, the more the traditional approach seems badly broken. The typical development process goes something like this:
- Development starts out at the block diagram level, usually in Simulink. Environments like Simulink are inherently parallel, so it is often easy—and sometimes necessary—for the block diagram to explicitly represent the parallelism in the system.
- The system is ported to C, which is inherently a sequential language. All of the parallelism in the block diagram is "lost in translation." Some of this parallelism can be re-captured using intrensics and other techniques, but it is difficult to express some types of the parallelism in C.
- The C code is fed into a compiler. The compiler will recognize some opportunities for parallelism—particularly where intrensics and similar techniques have been used—but it will miss many other opportunities.
- A programmer fine-tunes the compiler's assembly code output. The assembly-language programmer can add parallelism back into specific functions, but generally cannot modify the overall system architecture.
The obvious problem with this design flow is that it takes a highly-parallel design, strips out the parallelism, and then attempts to restore parallelism. It would make a lot more sense to skip the C port and go straight from a block diagram to assembly code.
There are a few tools that do exactly this. One of the better examples I've seen is Analog Devices' VisualAudio tool. This tool is a brilliant solution, but it has two major drawbacks: (1) it only supports Analog's SHARC and Blackfin DSP families and (2) it is only useful for audio systems.
There are a few other tools that have wider applicability, such as the Hyperception RIDE environment, but I rarely hear anything about them. This really puzzles me. Have I overestimated the value of these tools? Are engineers just being stubborn about sticking with C? I really don't know why these tools have failed to catch on—stop by the forum and let me know what you think.
(By the way, I know that plenty of engineers use Simulink and National Instruments' LabVIEW Embedded to generate code. But these tools generate C code, not assembly code. This still leaves you working with an inherently sequential language, which is a bad thing in my view. You can get a good overview of the pros and cons of the language and tool options in this article from BDTI.)