Unite algorithm and hardware design flows

There are typically two groups involved in the design and realization of DSP algorithms in an FPGA: DSP architects and hardware design engineers. Unfortunately, there is a "wall of abstraction" between the architects who formulate the algorithms and the design engineers who are charged with their physical implementation (Figure 1).

1. A wall of abstraction separates DSP architects and hardware design engineers
(Click this image to view a larger version)

This article reviews past attempts to build a bridge between the DSP design domain and physical implementations. Also discussed are the ways in which each of these conventional approaches falls short. Next, we introduce a new DSP design methodology—true DSP synthesis—which integrates into existing design flows without any disruption. This solution bridges the gap between the algorithmic and implementation domains by automating the processes of system-level optimization and implementation-level mapping.

Background: RTL, MATLAB, and Simulink
Hardware design engineers typically visualize their world as a collection of blocks described in a hardware description language (HDL) such as Verilog and/or VHDL. These blocks are captured at a very low level of abstraction referred to as register transfer level (RTL).

In contrast, DSP architects typically create, explore, evaluate, and analyze DSP algorithms at a very high level of abstraction. These evaluations are usually performed using the de facto industry standard MATLAB environment from The MathWorks, Inc. It should be noted that MATLAB refers both to a language and an algorithmic-level simulation, visualization, and analysis environment. In order to avoid confusion, it is common to refer to M-code (meaning "MATLAB code") and M-files (meaning "files containing MATLAB code"). MATLAB allows DSP architects to represent a complex signal transformation, such as an FFT, using a single statement along the lines of:

y = fft(x);

This means that MATLAB can be used to describe complex systems in a concise manner that is suitable for analysis at a very high level of abstraction. However, real-world digital signals are characterized by varying sampling rates and discrete amplitudes. Thus, in order to verify DSP algorithms to a level suitable for implementation, the verification environment must efficiently represent discrete time in multi-rate DSP applications. Unfortunately, MATLAB does not support the concept of discrete time.

Furthermore, the native simulation engine in MATLAB is optimized for floating-point mathematical operations. MATLAB slows down significantly with fixed-point representations, in which each operation is "wrapped" with checks for overflow, underflow, rounding, and so forth.

In order to address these issues, The MathWorks introduced the Simulink environment, which has been designed to natively handle DSP issues such as multi-rate discrete time definitions and fast, efficient simulation for both floating-point and fixed-point design representations. At the time of this writing, Simulink is already being employed in the majority of existing design environments for which FPGAs are the target implementation technology.

Problems with conventional techniques
Once a suite of DSP algorithms have been proven in Simulink and the system architecture has been defined at a high level of abstraction, hardware design engineers have to transform the design into a physical implementation.

Traditional techniques for bridging the gap between the architectural and implementation domains typically fall into two main camps—language translation and IP instantiation and netlisting—as discussed below.

Before looking at these approaches, it is important to note that there are many ways to implement a given DSP design on a given FPGA. Each implementation will vary in terms of resource utilization (such as the number of logic blocks used) and performance. Thus, the ability to quickly evaluate a wide variety of alternative implementations is critical to achieving high-quality DSP realizations in a timely manner.

Page 2: Language translation: MATLAB/Simulink to RTL
Page 1 | 2 | 3 | 4