High-Performance DSPs -> A case for superscalar DSPs

Studies have shown up to 80 percent of all embedded product development costs are associated with software development. This is largely due to reliance on assembly-level coding. Although it is desirable to use C compilers, as of today, much of the computation-intensive code is still hand-written in assembly in order to meet the performance requirements.

One key advantage of superscalar processors is that it is not necessary for the programmer to factor in data hazards because of parallel execution, or the pipeline latencies for writing a piece of code that would function correctly. Therefore, it is possible to break down the problem of code development into two subtasks. The first is that of writing software in a linear fashion and debugging it. The second is that of reorganizing the software instructions in the computationally intensive inner loops of the algorithms to achieve the maximum amount of instruction-level parallelism.

The compiler design process is similarly simplified, as the developers can focus more on compiler performance-related issues rather than pipeline-related issues. Thus the superscalar nature of the processor accelerates the software development process.

Equipment manufacturers that use high-performance DSPs are under constant pressure to upgrade their equipment and to provide additional functionality. For a convenient and cost-effective product evolution plan, it is desirable for software to maintain compatibility with the next generation of hardware. Because instruction scheduling is performed in hardware, a superscalar architecture facilitates code migration from one generation of architecture to the next. Maintaining bi nary or even assembly-level code compatibility is difficult with processors that are not superscalar.

As silicon vendors migrate to deep-submicron process technologies, the area occupied by the DSP core is a shrinking fraction of the die area. The SoC die size, and therefore its cost are increasingly dominated by the peripheral logic, and in particular, on-chip memory. Large memory systems require more sophisticated support logic to achieve high speed than smaller memory systems, with associated increases in both gate count and power consumption. Therefore, to minimize overall system costs, it is critical to control the performance and associated power consumption in any DSP memory system design.

By treating each instruction independently, a superscalar DSP can achieve relatively high code density. Instruction memory size is usually an issue with VLIW processors, where a long instruction word consisting of several operations is fetched and executed every clock cycle. If the programmer cannot squeeze in a sufficient number of useful instructions into this instruction word, whether because of data hazard or resource conflicts, the void has to be filled with placeholder no-operation instructions. Benchmarks comparing the code densities of superscalar and VLIW architectures show that superscalar architectures often require less than half the memory required by VLIW architectures.

It is often assumed that a superscalar architecture will require complex logic for pipeline control, and therefore will have high overhead in terms of power consumption. This assumption stems from the fact that general-purpose processors typically employ such superscalar techniques as operand scoreboards, reservation stations and register renaming. Those techniques enable the processor to issue and execute instructions out of order, taking advantage of the fact that not all sequential operations have operand dependencies and that different types of operand hazards can be resolved at different stages of the pipeline.

Supers calar architectures, however, do not necessarily support out-of-order execution. A superscalar architecture is simply one that is responsible for resolving the operand and resource hazards and that has the resources to achieve an instruction throughput that is greater than one instruction per clock.

For example, in the ZSP architecture, logic dedicated to pipeline control is kept to a minimum by enforcing in-order execution and by isolating the control to a single stage at the head of the pipeline. This stage issues sequential groups of instructions that have no data dependencies or other resource conflicts. Once a group of instructions has been issued, they advance through the pipeline in lock step. In addition, the address generation units are kept separate from the arithmetic logic units, with their own set of registers. This further simplifies the resource allocation problem, thus reducing the pipeline control logic.