Achieving Better Code Optimization in DSP Designs

But, whether the source is created in C, in assembly, or in a combination of the two, programmers need to understand the DSP architecture in order to optimize code. Knowing how the object code created by the compiler or assembler operates on the underlying hardware enables the programmer to write code that uses the tool more effectively. It also permits fine-tuning of the software in order to maximize the DSP's performance.

This article will look at the coding tools that are available to designers working with DSPs. The article will also provide some techniques that designers can employ to optimize code.

Coding Tools
With traditional DSPs, programmers turned to the machine's assembly language for almost all code development. However, the VLIW architecture of high-performance DSPs makes assembly coding more difficult due to the increased programming complexity, such as multiple functional units with instructions that are statically scheduled and dispatched.

While the complexity of assembly coding increases, the vastly greater performance gives the program developer more latitude to trade off a little performance for ease of development. As a result, the C language, which is more familiar than DSP assembly to most programmers, has become the first choice for software development. C compilers have a high degree of efficiency in VLIW machines, so developers naturally turn to C when they are trying to create and test software quickly.

One of the disadvantages of C compilers in taking full advantage of high-performance DSP architectures is that they cannot always efficiently map complex algorithms to the multiple VLIW functional units. For example, architecture-specific details such as single-instruction multiple-data (SIMD) instructions, which exploit inherent parallelism in many applications, cannot be represented in generic C.

In these instances, a machine-specific approach is required in order to extend the utility of C for high-performance DSP architectures. VLIW compilers often support C intrinsics, function-like statements within C that represent assembly instructions. As an example, Code Lists 1 and 2 show generic C and intrinsic C codes, respectively, for a finite impulse response (FIR) algorithm implemented on a VLIW DSP.

List 1. Generic C code for FIR filter
Click here for Code List 1

List 2. C code with intrinsics for FIR filter (partial list).
Click here for Code List 2

Even with C instrinsics, some important architectural details cannot be represented, which is why assembly coding is often required to achieve maximum attainable performance. Partitioning code for clusters is a good example.

In most VLIW DSPs, the functional units are divided into groups called clusters, and each cluster has its own local register file. This clustered approach substantially reduces the hardware complexity due to the smaller number of ports required for each register file.

In cluster-based architectures, one of the critical steps that the C compiler performs is to balance or partition instructions over multiple clusters. But the compiler is imperfect, and there is no way to explicitly give it partitioning hints. Therefore, it is often necessary to rewrite blocks of code in assembly in order to perform partitioning effectively.

Code List 3 shows an example of assembly code with partitioning that corresponds to the FIR code in Lists 1 and 2.

List 3: Assembly code for FIR filter (partial list).
Click here for Code List 3

Code List 3 is manually written with an optimization technique called software pipelining to maximally utilize multiple functional units. Doing this by hand is tedious and opens more possibilities for errors. Linear assembler is one tool that can automatically perform software pipelining. This assembler allows a programmer to write assembly code serially, as if it were to be performed by a single functional unit. The assembler then turns the serial code into parallel code for multiple functional units.

Code List 4 shows an example of assembly code developed using linear assembler.

List 4: Linear assembly code for FIR filter (partial list).
Click here for Code List 4

Table 1 compares the four code segments. Note that the cycle count becomes closer to the ideal cycle count as more architectural details can be specified.

Table 1: Performance of FIR Filter Codes

¹The outer and inner loops are merged and unrolled four times for better performance.
²The ideal cycle count is the maximum attainable number of cycles for the loop only. The number of multiply instructions required is 1152, and it is a limiting factor in this code. Since the target DSP can perform 4 multiplies per cycle, the ideal cycle count is 288.

What typically happens in software development is that the vast majority of the code, which is necessary for control but is lightly used in operation, is written and remains in C. The remaining small percentage of the code performs the computationally intensive signal processing portions of the algorithm. This code, for the most part within loops, is being performed most of the time that the system is operating.

For the program developer, it pays to rewrite and optimize these blocks of code in C intrinsics or linear/hand assembly languages, since a small gain in efficiency can have a great deal of leverage in improving the overall performance of the machine.²

Optimizing Performance
Different DSPs are designed with different characteristics, such as the number of parallel functional units, instructions supported by the units individually, support for instructions with unique data handling capabilities such as SIMDs, and instruction latencies for different instructions. Optimizing code, therefore, begins with choosing the right algorithm for the target DSP.

It is necessary to set a clear, reasonable optimization goal that takes into account the underlying architectural details. Several important considerations for optimizing code include instruction latency, resource constraints, recurrence constraints, and nested loops. Let's look at these four issues in more detail starting with instruction latency.

1. Instruction Latency
An important factor that affects code optimization and throughput in both the C and assembly languages is instruction latency. Although an instruction can be issued to the functional units every cycle, the number of cycles before the output is available is typically long due to the deeply pipelined hardware architecture. When the code does not take this latency into account, the delay can considerably offset the advantage of hardware pipelining. To reduce the negative impact of long instruction latency and also to maximally utilize multiple functional units in the VLIW architectures, software optimization techniques such as loop unrolling and software pipelining need to be considered.

Unrolling loops not only reduces branch overhead but also allows more instructions to be grouped together for more efficient instruction scheduling. Software pipelining, which overlaps multiple iterations of a loop, can also largely offset the negative impact of the long latency on performance, typically in conjunction with proper loop unrolling.

Figure 1 illustrates an example of modulo software pipelining where loop iterations are initiated at a constant rate known as iteration interval (II).