Abstract

What impact does (or should) algorithm selection have in the trade-offs performed to define the architecture of a new signal processing system? How can the systems architect take algorithms into account to improve the efficiency of the system? How important is efficiency to the user? How do we measure efficiency? How do the algorithm and architecture axes mentioned by John Hershey in the opening editorial of this issue interact with each other? These questions are among the many factors which the systems architect must consider when selecting the architecture of a new signal processing system. In this article, I will attempt to answer some of these questions and lift part of the veil of mystery from signal processor design and selection. In answering some of these questions I will more than likely raise some hackles, provoke controversy, and generate more questions than I answer. If this leads to a better understanding of signal processing systems, then this article will be successful. What is a signal processor? What defines it and what measures its efficiency for a given application? From an applications view, signal processors are realtime systems executing numerically intense algorithms. Translated, this means that there is some time frame allowed for the algorithm to execute a series of repetitive operations on a large collection of data. This real-time requirement is usually the driver in the design of the system. There are some other common characteristics that are shared by many signal processors. Most have a Harvard architecture; i.e., the program memory and the data memory are separate entities. General purpose processor designs use the Princeton architecture which shares program and data memory. The Harvard architecture prevents self-modifying code (originally thought to be a good thing, but now it is often the source of hard to locate bugs) and allows the instruction memory to be wider than the data memory. This allows signal processors to be very long instruction word (VLIW) machines, providing concurrent control for the large complement of functions typically found in signal processors. Another characteristic of signal processors is the use of pipelined functional units. Pipelining is the use of registers within the data path of the functional unit to allow higher clock speeds. This allows data to enter the functional unit at the clock rate regardless of the number of cycles required to complete the function. It also allows multiple functional units to be strung together to perform more complex functions. The domain of signal processing stretches from systems which swallow data day in and day out, performing the same operations for extracting information, to a multimode radar processor which must switch algorithms on a minute by minute basis during a mission. The first example belongs in the domain of the special purpose processor. A system which never changes algorithms and whose sole purpose is to crank out answers to the same question day in and day out at high speed will be better served with a special purpose design. No matter how clever the architect, a system designed from inception to efficiently process only one algorithm will always beat out a more general purpose signal processor. An efficient signal processor will devote lo-20% of its resources to operations which change data, while a special purpose processor routinely achieves a 50% ratio of arithmetic to control and data routing. Computing can be considered to be a continuum with special purpose processors on one end and general purpose processors on the other. As you move from special purpose to general

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call