With regard to designing and implementing DSP algorithms, the first step in the process is for the DSP architects to explore and analyze them at a high level of abstraction. This is almost invariably performed using the de facto industry-standard Matlab and/or Simulink environments from The MathWorks Inc. In the case of design environments in which the target implementation technology involves ASICs, Matlab typically holds the high ground. By comparison, I now understand that Simulink is employed in the majority of today's design environments for which FPGAs are the target implementation technology.

Later, when it comes to actually implementing these algorithms, there are two main ways we might choose to go: software or hardware. In the case of a software realization, we might decide to represent the little scamps in C/C++ and/or assembly code, compile and/or assemble these representations into machine code, and run this machine code on a general-purpose microprocessor or a special-purpose digital signal processor.

The main advantage of representing the algorithms in code is that this offers great flexibility in that it's relatively easy to make modifications. The downside is that microprocessors and digital signal processors are both von Neumann-type machines, which means that they spend a huge amount of time (and power and silicon real estate) fetching and decoding instructions; fetching and processing data; and then storing the results.

The alternative is to implement the algorithms directly in hardware (as logic gates/functions and registers) using ASICs and — more recently — FPGAs. Traditionally, this implementation process has relied on re-coding the algorithms by hand at the register transfer level (RTL) of abstraction. Sad to relate, there has typically been a wall of abstraction separating the DSP architects who formulate the algorithms and the design engineers who are tasked with their physical implementation (Figure 1).

In order to break through this wall, there are a number of companies fielding a variety of interesting solutions. Until now, the majority of these solutions have involved some form of language translation or IP block instantiation. Thus far, however, the majority of these options have not provided a clear hand-off between the DSP architects working in the Matlab/Simulink domain and the hardware design engineers working in the implementation domain. In fact, we often end up with the worst-case scenario which requires users to be experts in both domains, and such people are few and far between!

True DSP synthesis — dare we hope?

The folks at Synplicity are, of course, famous for their FPGA-centric synthesis technology. So you can only imagine my surprise and delight to hear about their new Synplify DSP product, which, they inform me, provides the world's first true DSP synthesis solution.

The idea is that Synplicity provides an architecture-independent, vendor-independent blockset (library) for use with Simulink. In order to aid in the quantization process (the conversion of the initial floating-point representations into their fixed-point counterparts), each of these library elements supports automatic data-type propagation. This means that the user need only specify the fixed-point data types (signed, unsigned) and bit-widths for selected signals; derived values will then automatically propagate throughout the design.

But the key point is that, unlike conventional IP blockset solutions, this library maintains the entry point for the DSP architects at the pure algorithmic level. That is, the architects are not required to define any low-level implementation decisions such as whether internal storage is to be based on FIFOs, registers, or memory. Instead, the only parameters with which the architects need concern themselves are high-level attributes such as filter coefficients and gain requirements.

This means that the resulting Simulink representation doesn't have any architectural implications and therefore provides the most appropriate hand-off point to the hardware design engineers. These engineers need only inform the Synplify DSP synthesis engine as to the target FPGA architecture, the desired sample rate(s) associated with the system, and the speed requirements for the design.

Synplify DSP then evaluates all of the different possible solutions so as to achieve the most optimal implementation and generates the appropriate RTL based on the supplied area/timing restraints. Furthermore, due to the fact that Synplify DSP is architecturally aware, the RTL it generates as output is "tuned" so as to provide the best possible solution for the target device (Figure 2).

Figure 2 — DSP Synthesis bridges the gap between domains

Synplify DSP performs system-level optimization techniques such as retiming, resource allocation, scheduling (folding), multichannelization, and architectural selection. In this context, "folding" refers to taking the operations associated with a datapath and folding those operations onto fewer resources operating at a higher rate.

For example, consider a FIR filter with 100 taps (stages) running at 1 MHz. Each tap has an associated multiplier and adder function. As opposed to using 100 multipliers and 100 adders running at 1 MHz, an equivalent filter can be created using only one multiplier and one adder running at 100 MHz with the intermediate results being stored in memory.

In the case of multichannelization, consider a video signal in which the same DSP operations are required to be performed on the Red, Green, and Blue channels. In this case, the user need only identify one channel and instruct Synplify DSP to use it for multiple signals if it can. If the sample rate is low enough compared to the system clock, the synthesis engine will automatically identify the additional channels and apply the multichannelization technique to them.

Well, I don't know about you, but I'm impressed. If Synplify DSP does half of the things the guys and gals at Synplicity claim, then it will be a very valuable addition to any DSP design team's arsenal, and it certainly deserves an official "cool beans" from me. Until next time, have a good one!

Clive (Max) Maxfield is president of Techbites Interactive, a marketing consultancy firm specializing in high-tech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and co-author of EDA: Where Electronics Begins, Max was once referred to as a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.