Digital Signal Processors in Real-Time Embedded Systems
Jeremy Kohel
Department of Software Engineering
University of Wisconsin Platteville
Abstract
Real world, real-time applications depend a great deal upon the processing of signals, both analog and digital, to meet the needs of today’s society. Now, more than ever, programs are getting larger, more data is being used, and people’s demands are increasing, causing new innovations to be spawned in order to meet these challenges head on. At the heart of this movement, started back in the 1970’s, lies the key building block that makes this possible: the DSP (digital signal processor). This paper will explore and address the basics of how these processing units are able to make such a great impact on the real-time embedded systems field and how companies choose to support and advance their technology.
What is a DSP?
To understand the importance of digital signal processors, the knowledge of what a DSP is must first be acquired. A DSP is a specifically engineered microprocessor that is used to process, and change mathematically, digital signals to achieve a higher quality signal. [1] This is a stepping-stone in the middle of the entire chain of events that constitute digit signal processing. Below is a description of how the process works and the DSP’s role in it:
Step 1: First, the real world signal has to be received through an ADC (analog-to-digital converter) before the DSP can even do its job. The reason for this first component is due to the fact that all real world signals are inherently analog, or continuous. They make smooth transitions from state to state. However, computer equipment deals with digital signals, which are discontinuous and discrete. They make sharp transitions instantly from one state to another. An example of this would be converting a person talking into a cell phone. Their voice is a smooth, analog signal so it must be converted into a digital signal in the phone.
Step 2: Once the analog signal is converted to a digital one, the DSP can receive the signal and start manipulating it. After altering the binary data of the signal and compressing it, the DSP sends the digital signal to a DAC (digital-to-analog converter) to change the signal back to a continuous signal.
Step 3: The DAC sends the newly converted analog signal to whatever output device is assigned to use it. This may depend on the device however, as some outputs may have to remain in a digital format.
The cell phone example in Figure 1 below clearly illustrates this process in action:
Figure 1: Digital Signal Processing [5]
Common Features of all DSPs
Though DSPs are customizable components that have to be designed for the specific task at hand, there are a few characteristics shared by all. Because of the fact that their purpose is to perform mathematical operations at lighting speed, all the similarities between DSPs have to do with executing tasks in parallel not to waste any time. [1]
First, they are expected to be able to execute multiple “Macs” in parallel. The name comes from performing a multiply-accumulate instruction. These instructions do a multiply on two operands, and then add them to an accumulator register(s) in a single instruction cycle. Macs are extremely useful in many varieties of DSP algorithms because they are the most efficient at calculating dot products, which coincidentally are used quite often in problems requiring a digital signal processor. [1]
Secondly, DSPs are expected to have efficient memory accessing capabilities. It’s imperative that the processor can access a slot in memory while at the same time fetching the next instruction to be executed. [2] General purpose microprocessors require separate instruction cycles to fetch an instruction and access the memory before fetching the next cycle. [1] This loss of time would cause a delay in the signal causing it to be distorted on the other end by the device using it.
Finally, the ability to generate addresses in parallel with the execution is a must for all digital signal processors. The program must next address needed before it is forced to wait. That way while the instruction is being executed the next needed address can be formed without wasting any clock cycles. In fact, some DSPs actually require multiple address generation units to increase the speed at which the addresses can be generated. General purpose microprocessors require extra cycles to accomplish the task. [1]
Different DSPs for Different Jobs
When deciding which DSP to use in a particular project there are a few things that need to be considered. The hardware should be able to accomplish the goals set forth in the analysis of the system. However, using better hardware increases the cost of the project. Therefore it is imperative that the costs and benefits be weighed before selecting a DSP for the job. Texas Instruments, a major manufacturer in the DSP manufacturing business, has a line of processors for any size project on almost any budget. [5]
One very important issue to consider in choosing a DSP pertains to the number of instructions that can be executed simultaneously. Since these processors have to perform mathematical manipulations at extremely fast speeds this characteristic is very critical. TI’s C5000 series has many affordable DSPs that have sufficient bus sizes for most moderately sized projects. For example, the TMS320VC5416-120 has three separate 16-bit data buses and one 16-bit program bus, so up to 48 bits of data can be accessed while at the same time accessing a 16-bit instruction from the program memory. [5] For a little extra money, one of the C6000 series chips can be purchased gaining a decent size jump in bus architecture. The TMS320DM642-500 from TI has eight separate functional units each supporting 32-bit instructions, thus yielding up to eight 32-bit instructions per cycle. [5]
Another important hardware issue to consider is the mathematical architecture, either fixed-point or floating-point. Fixed-point arithmetic has the decimal point always staying in the same place, while floating-point arithmetic allows the decimal point to move around at will. This may seem like a trivial aspect of the DSP, but in fact, by definition, it’s not because the main function of all digital signal processors is to rapidly perform mathematical operations on binary data. With millions of these manipulations being done every second the locations of the decimal points are of extreme importance. [1] With fixed-point arithmetic the programmer must keep track of the precision, while the floating-point architecture handles the problem automatically. However, since floating-point arithmetic can be implemented on fixed-point hardware, it is more economically efficient to use a fixed-point DSP as they are less expensive than their floating-point counterparts. [4]
Software Support
Almost every manufacturer of DSPs includes some sort of software package with their chips to aid in developing and operating the hardware. Most of this software includes tools for writing, debugging, compiling code, simulating programs, and building the applications. [3]
DirectDSP
Signalogic offers a package called DirectDSP, which implements an interface between the DSP hardware and well-known development environments on different operating systems.
Figure 2: Diagram of DSP development system [3]
Supporting such tools as Visual Studio, .NET, and MATLAB this software makes developing programs much easier. It interfaces directly with the DSP hardware drivers, and includes advanced drivers for communicating with Windows or Linux.
DirectDSP provides a user-friendly GUI that allows the programmer to watch variables change in real-time without ever having to stop the process currently running on the hardware. In addition, the waveform of the signal is also generated for the developer to view while running or debugging a program. [3]
Code Composer Studio
In Figure 2 there is a black box labeled “Code Composer Studio”, which is TI’s main software package. It shares many of the same features as most other DSP software, including DirectDSP, however there are some features that really make life easier for the software developer.
Some of the features include:
- A user-friendly IDE
- C/C++ supported compiler
- Code generation tools
- Project Manager
- Simulator
- Real-time Analysis
- Code Coverage
- Fully customizable
Of the features listed above the most unique to CCS are code coverage and, indirectly, customizability. They help the developer to produce higher quality software with fewer bugs.
For example, when performing coverage testing, CCS highlights the lines of source code executed, and therefore informs the developer what code isn’t covered by the tests. New, more complete tests can be implemented to test everything. Code coverage is so important to the system because it can identify chunks of code that get executed most often, thereby giving the developer a chance to optimize the most rigorously executed parts of the system. [5]
The customizability of Code Composer Studio allows the developer to increase the performance of the system with just the click of a mouse. One way it accomplishes this is by allowing the developer to view a cache access log. Here, the amount of cache hits, misses, and conflicts are displayed. With having the knowledge of cache access patterns the developer has the ability to customize the system accordingly. The software color-codes each type of memory access thereby making it easy to place the cache algorithms to most efficiently make use of the cache memory. [5]
Writing Code for DSPs
The following segment of C code illustrates a simple example of how a DSP can be used to manipulate the incoming digital signal:
void UserProc(void* ptrIn, void* ptrOut, long nLen, short int nNumTrace) {
#ifdef defined(TMS320C3x) || defined(TMS320C4x) || defined(DSP5600x) || defined(ADSP2106x)
#define x ((long*)ptrIn)
#define y ((long*)ptrOut)
#endif
#ifdef defined(DSP32C) || defined(DSP3210) || defined(TMS320C2x) || defined(TMS320C5x)
|| defined(ADSP21xx)
#define x ((short int*)ptrIn)
#define y ((short int*)ptrOut)
#endif
short int n;
for (n=0; n<nLen; n++) {
x[n] = 0.75*x[n] + 1000;
y[n] = x[n];
}
}
In this example, the variable x is the input buffer containing the newly acquired input signal, and the variable y is the output buffer containing the outgoing, manipulated signal.
The variable nLen is the length of each buffer. However, each element in the buffer may contain more than one sampling of data depending on the variable nNumTrace, which defines how many channels were used to obtain the element. [3]
In the “for” loop above each element of the incoming buffer is being manipulated according to the equation “x[n] = 0.75*x[n] + 1000” before it is sent the output buffer on channel n. The loop continues for nLen elements, the buffer length parameter of the function. [3]
Programming with higher level languages
One of the most important issues to a software developer regards the choice of language with which to develop the application. For DSP systems the main choices include basic assembly, or any supported higher-level language (C, C++, Ada, etc.). Manufacturers of DSPs include software with compilers that support many languages, but C is still the most popular for real-time, DSP applications. Why? C is very versatile, highly portable, and useful for structured programming. [6] However, many developers choose to employ optimized assembly code instead of the slow executing assembly code produced by most standard C compilers. [1] It is possible, in some situations, to get better code using a compiler. However, most of the time there will at least be part of the code that needs to be optimized further.
Other than execution speed, what are some of the hoops that need to be jumped through in order to develop a C application? First, it must be recognized that there is a difference between the object code for a DSP and a workstation CPU. This difference prevents a program from actually running on the same computer the code was written on. If the hardware is present, then the program can be executed and tested using it. However, without a DSP board at hand a simulator must be used instead to run the program in a virtual environment similar to that of the actual DSP hardware. A question might be asked as to why not develop the entire application on a DSP supplied workstation. This might be a good idea if the I/O architecture of a DSP was similar to that of a regular CPU. However, it is not, and the key difference is that the regular CPU has vastly more required I/O resources, thus making it impossible to develop for a DSP without using a CPU-driven workstation. [6]
The C language requires a large amount of external libraries to perform functions not built into the language itself. For example, it needs an I/O library specifically designed for the operating system it will be running on. In addition, C requires an extensive set of Run-Time libraries to provide routines to provide support for string operations, math functions, and memory management.
Despite what is already required for the C language, there are a few DSP libraries that must be included to provide support for the DSP and the hardware. Since DSPs require different sections of code to be allocated to different types of memory (SRAM, DRAM, ROM, etc.), the standard C memory management is not sufficient. Therefore special memory libraries must also be part of the compilation process. In addition to memory management, DSP systems require libraries to add support for specialized mathematical functions regarding vectors, matrices, and filtering. Leaving out these libraries would prevent the basic manipulations that define digital signal processing. [6]
Figure 3: Compiling process for a C-based DSP application [6]
The diagram above illustrates the entire compilation process. It is similar to most other C-based applications with the exception of the extended libraries and the cross compiler/assembler.
Conclusion
As real-time, embedded systems evolve and expand, so too must the digital signal processors fueling those applications. With speed and performance the paramount considerations in DSP applications, the future will see newer chips with faster speeds, more efficient bus systems, and more compact architectures. However, many of the issues plaguing software developers today will still exist then. They have the daunting task of designing the application with the best DSP for the job while considering such issues as cost, ease of use, and efficiency.
The choices are abundant, but no decision comes without some sacrifice. To lower the cost of the project an architecturally inferior chip may be used, or a software package with fewer useful tools may be used to implement the system. If the software includes compiler support for higher-level languages, then the developer will have the ability to write more compact, succinct code. The disadvantage of this is that the program will not be as efficient as manually optimized assembly code, and it may require a great deal of external libraries to provide all of the desired functionality.
As better software is created to help implement DSP applications, developers will finally be able to keep up with the hardware advancements of the DSP chips and fully utilize them to engineer the real-time applications of the future.
References
[1] “Choosing a DSP Processor”, Berkeley Design Technology white paper,
[2] Jennifer Eyre and Jeff Bier, “The Evolution of DSP Processors”, Berkeley Design Technology white paper,
[3] “Adding user defined C routines to real-time DSP code”, Signal Logic,
[4] "DSP Algorithm Development Tools" DSP & Multimedia Technology, November 1993
[5] “Digital Signal Processing, C6000 DSPs”, Texas Instruments,
[6] “C-Language Programming for DSP”, Pentek Inc white paper,