Custom DSP Solutions

Custom (algorithm-specific) DSP solutions for ASIC or FPGA are primarily used in applications that require very high throughput or low power consumption. This leads to datapath-intensive architectures with only limited resource sharing and control flow. Many DSP algorithms can be described using data flow models and therefore map naturally to a datapath architecture. However, to avoid an excessive use of silicon area/resources, each processing block must be carefully designed to keep all bitwidths in the datapath at a minimum, while ensuring that the performance requirements are met. The choice of processing algorithm is also important, as certain algorithms are better suited than others for this type of architecture. In some cases (but far from all), a floating point algorithm is developed first and then converted to integer arithmetic. The integer algorithm is tested and if necessary fine tuned using a simulation model that describes the bit-exact behavior of the algorithm while leaving the architectural details unspecified.  Next, the details of the datapath are defined and a Register Transfer Level (RTL) model, coded in a hardware description language (HDL), is created. The RTL model is verified by comparing its output to that of the behavioral model. Nothing less than 100% bit match should ever be accepted.

Custom DSP solutions offer high performance, but the design cycle tends to be significantly longer than for programmable DSP. According to our experience, the most time consuming tasks in custom DSP design are 1) The development of integer algorithms including bitwidth minimization, and 2) The translation of behavioral models to RTL code. The problem is compounded by the fact that these two design tasks often have to be carried out in sequence rather than concurrently. Moreover, the two tasks seem to be at odds with each other: a design methodology that simplifies task 1 will typically complicate task 2, and vice versa. An example of this is high-level synthesis (HLS). After being almost abandened for a few years, HLS (aka behavioral synthesis) is now experiencing a revival. Driving this trend is the emergence of SystemC, a collection of C++ classes that allows a system designer to create models at multiple levels of abstraction: algorithmic, behavioral and RTL. By synthesizing RTL code from high-level models in SystemC,  RTL coding can effectively be replaced by C++ coding. This is a big deal, because the world is full of engineers who can write good C++ code, whereas good RTL programmers are scarce. So what's not to like? The problem is that a C++ compiler environment is a poor choice for algorithm exploration. MATLAB, both as a programming language and as a development environment, has many advantages over C++, including rapid code development, powerful vector matrix operations and extensive libraries (called tool boxes) with DSP algorithms, optimization algorithms, filter design tools etc. Basically, the C++ design flow offers a faster route from behavioral model to RTL model while slowing down algorithm development. Another recent development in behavioral synthesis is the Bluespec SystemVerilog (BSV) language and associated tools from Bluespec Inc. BSV has some distinct advantages over SystemC, such as being 100% synthesizable. However, it is a language designed explicitly for architectural exploration and hardware synthesis. In a design flow based on BSV, the algorithm exploration must be carried out in a separate environment such as MATLAB.

Being fully aware of the time-critical nature of custom DSP development, we are constantly working to improve the time-efficiency of our design methodology. The most important aspects of this methodology are listed below.

  • Proprietary tools are used to automate the design of many common processing blocks such as decimation filters, filter banks and synthesizers. These tools allow the system designer to go from a high-level system specification to a fully specified datapath in a matter of minutes, thereby eliminating the need for time-consuming system simulations. The system specification will typically include parameters such as stop-band attenuation (for a filter block), spurious-free dynamic range (for a synthesizer block) and noise figure (for all blocks). This approach is especially effective in the design of radio transceivers, since a digital transceiver can usually be assembled from "standard" DSP structures that are generic in nature and relatively easy to parameterize. For more on this, see the section on Wireless Transceivers.

  • In wireless modem design, a certain amount of algorithm exploration is unavoidable. We primarily use MATLAB for this task, with some processing intensive tasks coded in C/C++. An extensive library of MATLAB models (in floating point as well as integer arithmetic) is available to speed up the design work. However, to shorten the design cycle, simulations are kept to a minimum. The objective is to jump start the RTL coding effort as early as possible, so that the system design and digital design tasks can proceed concurrently. To achieve this, we use a methodology whereby processing blocks that have not yet been defined are given a black box characterization that captures the dependencies that exist between the defined and undefined blocks in the system. This makes it possible to set the bitwidths in the datapath without the use of lengthy bit-exact simulations. An illustration of this methodology is given in section Wireless Modems.

  • To bridge the divide between MATLAB  and RTL, we now offer behavioral models of processing blocks in SystemVerilog. Although not directly synthesizable, these models can be used to generate test vectors directly from within any simulator that supports standard SystemVerilog (IEEE 1800-2009), such as Modelsim from Mentor Graphics. Moreover, since the arithmetic operations inside these models are in fact synthesizable, the translation from behavioral model to RTL is greatly simplified. As a help in maintaining a consistent behavior across all models (MATLAB behavioral, Systemverilog behavioral and SystemVerilog RTL), we define algorithms using a set of basic integer operations with precisely defined behavior. These operations are implemented in both MATLAB and SystemVerilog and serve as a basic "dictionary" for translating algorithms from one language to the other.
Custom DSP solutions for wireless applications mainly fall into two categories: modems and radio transceivers. Although the boundary between the two is not always clear-cut, there are some distinct differences that affect the choice of design methodology. For more information on how we approach the design in each case, follow the links below.

Wireless Modems