Kenton Williston
Site Editor, DSP DesignLine
TechOnline

"East is East, and West is West, and never the twain shall meet," Rudyard Kipling famously wrote. Until recently, a similar perspective applied to the development process for signal processing systems. This process has three basic steps:

• Design the algorithms
• Design the hardware
• Implement the algorithms on the hardware

In most cases, each of these steps involves a separate design team and a separate set of tools. There is little overlap in the knowledge base of these three teams, or in the functionality of their tools. As in Kipling's famous line, these three teams might as well live on opposite ends of the earth—and with the increasing globalization of design teams, they often do!

The isolation of these teams from one another creates some serious problems. First, the fact that the teams use of separate tools means that there are major redundancies in the design process: Each team must start "from scratch," often replicating the functionality already implemented by another team. Second, there is often miscommunication between the teams, which can lead to inefficient or even incorrect designs. This can result in expensive and time-consuming re-work, or even products that fail in the field.

Perhaps most importantly, the lack of coordination between the teams can lead each team to make poor design decisions. To cite one simple example, algorithm designers usually work in floating-point, while the hardware and software teams usually work in a fixed point. This is an important distinction, because a design that works perfectly in floating-point may perform terribly in fixed point.

The obvious way to solve these problems is to create a unified tool flow that can be used by the algorithm designers, the hardware designers, and the software designers. In this approach, hardware and software are generated directly from the high-level representation of the algorithm, making the design process easy and guaranteeing correct operation.

This idea has been talked about for years, but there has been little to show for all of this talk. Tools that generated hardware or software had very limited capabilities. For example, a tool might be able to generate C code, but not the RTL needed for hardware design. What's worse, the generated designs were horribly inefficient—despite the fact that many of these tools promised to produce production-ready designs.

Happily, all of this is changing. Today's tools provide a much broader range of options: You can now transform MATLAB into C and Simulink into RTL. CoWare SPD models can be turned into SystemC, and you can generate FPGA implementations from LabVIEW models. Whether you use chips from TI, ADI, Xilinx, or Altera, you can find a high-level tool that will generate the designs you need.

The tools have also matured, and now produce much more useful output. Part of this maturation is that the tools focus less on producing production-ready designs, and more on helping designers perform rapid prototyping and design verification. These are no small matters. Rapid prototyping lets the algorithm designer experiment with different designs and understand the hardware—all of which greatly improves the quality of the design. The algorithm designer can then hand the hardware and software designers a known-good implementation. This minimizes the chances of miscommunication, and gives the hardware and software teams a "golden reference" to compare their designs against.

As we move into 2007, I expect this trend to accelerate. We may never get to the utopia of a truly "push-button" design process, but the tools are improving at impressive pace. This is a good thing: With the ever-increasing complexity of DSP systems—and the ever-shrinking development cycles—development teams can no longer afford to compartmentalize themselves. High-level design tools will be the key to breaking through to a new development model.