Digital Signal Processing
As a case study, let's consider the most common function in the digital domain: filtering. Simply put, filtering is to process the signal to improve its characteristics. For example, filtering can remove noise or electrostatic interference from the signal, thereby improving its signal-to-noise ratio. Why use a microprocessor instead of an analog device to filter the signal? Let's take a look at its advantages: the performance of analog filters (or more generally, analog circuits) depends on environmental factors such as temperature. The digital filter is basically not affected by the environment.
Digital filtering is easy to replicate within a very small tolerance, because its performance does not depend on the combination of devices whose performance has deviated from the normal value. Once an analog filter is manufactured, its characteristics (such as passband frequency range) are not easy to change. Using a microprocessor to implement a digital filter, you can change the characteristics of the filter by reprogramming it.
Comparison of DSP processors and general-purpose processors
Consider an example of digital signal processing, such as a finite impulse response filter (FIR). In mathematical language, the FIR filter is a series of dot products. Take an input and an ordinal vector, multiply between the coefficient and the sliding window of the input sample, and then add up all the products to form an output sample. Similar operations are repeated in large numbers in the process of digital signal processing, so that the devices designed for this must provide special support, which has contributed to the shunt of DSP devices and general-purpose processors (GPP):
1 Support for intensive multiplication operations
GPP is not designed to do intensive multiplication tasks. Even some modern GPPs require multiple instruction cycles to do a multiplication. The DSP processor uses specialized hardware to implement single-cycle multiplication. The DSP processor also adds an accumulator register to handle the sum of multiple products. The accumulator register is usually wider than other registers, and extra bits called result bits are added to avoid overflow. At the same time, in order to fully reflect the benefits of specialized multiply-accumulate hardware, almost all DSP instruction sets include explicit MAC instructions.
2 memory structure
Traditionally, GPP uses a von Neumann memory structure. In this structure, only one memory space is connected to the processor core through a set of buses (an address bus and a data bus). Normally, 4 memory accesses will occur for one multiplication, which consumes at least four instruction cycles. Most DSPs use the Harvard structure, which divides the memory space into two to store programs and data respectively. They have two sets of buses connected to the processor core, allowing simultaneous access to them. This arrangement doubles the bandwidth of the processor memory, and more importantly, provides data and instructions to the processor core at the same time. Under this layout, DSP can realize single-cycle MAC
instruction. There is another problem, that is, the typical high-performance GPP actually contains two on-chip caches, one for data and one for instructions, which are directly connected to the processor core to speed up the access speed at runtime. Physically speaking, the structure of this on-chip dual memory and bus is almost the same as that of Harvard. However, logically speaking, there are still important differences between the two.
GPP uses control logic to determine which data and instruction words are stored in the on-chip cache, which the programmer does not specify (or may not even know). In contrast, DSP uses multiple on-chip memories and multiple sets of buses to ensure multiple accesses to the memory in each instruction cycle. When using DSP, the programmer must clearly control which data and instructions are stored
In on-chip memory. When a programmer writes a program, he must ensure that the processor can effectively use its dual bus. In addition, DSP processors hardly have data caches. This is because the typical data of a DSP is a data stream. In other words, after the DSP processor calculates each data sample, it is discarded and is almost never reused.
3 Zero overhead loop
If you understand a common feature of DSP algorithms, that is, most of the processing time is spent on executing smaller loops, it is easy to understand why most DSPs have specialized hardware for zero-overhead loops. The so-called zero-overhead loop means that when the processor executes the loop, it does not need to spend time checking the value of the loop counter, the condition is transferred to the top of the loop, and the
Decrement the loop counter by 1. In contrast, the GPP cycle is implemented using software. Some high-performance GPPs use transition prediction hardware, which almost achieves the same effect as the zero-overhead loop supported by hardware.
4 Fixed-point calculation
Most DSPs use fixed-point calculations instead of floating-point. Although the application of DSP must pay great attention to the accuracy of numbers, it should be much easier to do it with floating point, but for DSP, low cost is also very important. Fixed-point machines are cheaper (and faster) than corresponding floating-point machines. In order not to use a floating-point machine and to ensure the accuracy of the numbers, the DSP processor supports saturation calculation, rounding and shifting in both the instruction set and hardware.
5 Special addressing mode
DSP processors often support specialized addressing modes, which are very useful for common signal processing operations and algorithms. For example, module (cyclic) addressing (useful for implementing digital filter delay lines), bit-reversed addressing (useful for FFT). These very specialized addressing modes are not often used in GPP, and can only be implemented by software.
6 Forecast of execution time
Most DSP applications (such as cellular phones and modems) are strictly real-time applications, and all processing must be completed within a specified time. This requires the programmer to determine exactly how much processing time is required for each sample, or, at least, how much time is required in the worst case. If you plan to use a low-cost GPP to complete the task of real-time signal processing, the prediction of the execution time will probably not be a problem. It should be that the low-cost GPP has a relatively straightforward structure and is easier to predict the execution time. However, the processing power required by most real-time DSP applications cannot be provided by low-cost GPPs. At this time, the advantage of DSP over high-performance GPP is that even if a cached DSP is used, the programmer (not the processor) decides which instructions will be put in, so it is easy to determine whether the instruction is from the cache or Read from memory. DSP generally does not use dynamic features, such as branch prediction and inference execution. Therefore, it is completely straightforward to predict the required execution time from a given piece of code. This allows the programmer to determine the performance limits of the chip.
7 Fixed-point DSP instruction set
The fixed-point DSP instruction set is designed according to two goals:
Enable the processor to complete multiple operations in each instruction cycle, thereby improving the computational efficiency of each instruction cycle. Minimize the memory space for storing DSP programs (because the memory has a great impact on the cost of the entire system, this problem is particularly important in cost-sensitive DSP applications). In order to achieve these goals, the instruction set of the DSP processor usually allows the programmer to specify several parallel operations within one instruction. For example, a MAC operation is included in an instruction, that is, one or two data moves at the same time. In a typical example, one instruction contains all the operations needed in the section to calculate the FIR filter. This kind of efficient payment
The price is that its instruction set is neither intuitive nor easy to use (compared to GPP's instruction set).
GPP programs usually don't care whether the processor's instruction set is easy to use, because they generally use high-level languages like C or C++. For DSP programmers, unfortunately, the main DSP applications are written in assembly language (at least partly optimized in assembly language). There are two reasons for this: First, most of the widely used high-level languages, such as
Like C, it is not suitable for describing typical DSP algorithms. Second, the complexity of the DSP structure, such as multiple memory spaces, multiple buses, irregular instruction sets, and highly specialized hardware, makes it difficult to write efficient compilers for it. Even if the C source code is compiled into DSP assembly code with a compiler, the task of optimization is still very heavy. Typical DSP applications have a lot of computational requirements and strict overhead limits, making program optimization indispensable (at least for the most critical part of the program). Therefore, a key factor in considering the choice of DSP is whether there are enough programmers who can better adapt to the instruction set of the DSP processor.
8 Requirements for development tools
Because DSP applications require highly optimized code, most DSP vendors provide some development tools to help programmers complete their optimization work. For example, most manufacturers provide processor simulation tools to accurately simulate the activity of the processor in each instruction cycle. Whether for ensuring real-time operation or optimizing code, these are very useful tools. GPP vendors usually do not provide such tools, mainly because GPP programmers usually do not need detailed information at this level. The lack of simulation tools accurate to the instruction cycle of GPP is a big problem faced by DSP application developers: it is almost impossible to predict the number of cycles required by high-performance GPP for a given task, so it is impossible to explain how to improve the performance of the code.
Our other product:
