Digital Signal Processors in Real-Time Embedded Systems

streethicksvilleAI and Robotics

Nov 24, 2013 (3 years and 8 months ago)

66 views

Digital Signal Processors in Real
-
Time Embedded Systems



Jeremy Kohel

Department of Software Engineering

University of Wisconsin Platteville

kohelj@uwplatt.edu



Abstract


Real world, real
-
time applications depend a great deal upon the processing of signa
ls,
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 gr
eat 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 i
s 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 process
ing. 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 in
stantly 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 sig
nal.


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. Be
cause 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 varieti
es 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 capabiliti
es. 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 be
fore 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
addre
ss 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 D
SP 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, whi
le 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
-
poin
t 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
counterpa
rts. [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,
includ
ing 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 Cov
erage



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, C
CS 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 c
hunks 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 o
f 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) ||
d
efined(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)

#end
if


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 containi
ng 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 th
e 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 p
arameter 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
c
ompiler. 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 rec
ognized 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 D
SP 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 t
o 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 operat
ing 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, the
re 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 su
fficient. 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. Lea
ving 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 th
en. 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 th
e 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
wri
te 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 softwa
re 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 Proc
essor”, Berkeley Design Technology white paper,
http://www.bdti.com/articles/choose_2000.pdf


[2] Jennifer Eyre and Jeff Bier, “The Evolution of DSP Processors”, Berkeley Design
Technology white paper, http://www.bdti.com/articles/evolution.pdf


[3] “Addin
g user defined C routines to real
-
time DSP code”, Signal Logic,
http://www.signalogic.com/index.pl?page=ccode#using


[4] "DSP Algorithm Development Tools" DSP & Multimedia Technology, November
1993


[5] “Digital Signal Processing, C6000 DSPs”, T
exas Instruments,
http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dsp&sectionId=2&tab
Id=57&familyId=132


[6] “C
-
Language Programming for DSP”, Pentek Inc white paper,
http://www.pentek.com/deliver/TechDoc.cfm/C_LangProg.pdf?Filename=C_Lang
Prog.p
df