2
Introduction to TMS320C55x
Digital Signal Processor
Digital signal processors with architecture and instructions specifically designed for
DSP applications have been launched by Texas Instruments, Motorola, Lucent Tech-
nologies, Analog Devices, and many other companies. DSP processors are widely used
in areas such as communications, speech processing, image processing, biomedical
devices and equipment, power electronics, automotive, industrial electronics, digital
instruments, consumer electronics, multimedia systems, and home appliances.
To efficiently design and implement DSP systems, we must have a solid knowledge of
DSP algorithms as well as a basic concept of processor architecture. In this chapter, we
will introduce the architecture and assembly programming of the Texas Instruments
TMS320C55x fixed-point processor.
2.1 Introduction
Wireless communications, telecommunications, medical, and multimedia applications
are developing rapidly. Increasingly traditional analog devices are being replaced
with digital systems. The fast growth of DSP applications is not a surprise when
considering the commercial advantages of DSP in terms of the potentially fast time to
market, flexibility for upgrades to new technologies and standards, and low design
cost offered by various DSP devices. The rising demand from the digital handheld
devices in the consumer market to the digital networks and communication infrastruc-
tures coupled with the emerging internet applications are the driving forces for DSP
applications.
In 1982, Texas Instruments introduced its first general-purpose fixed-point DSP
device, the TMS32010, to the consumer market. Since then, the TMS320 family
has extended into two major classes: the fixed-point and floating-point processors.
The TMS320 fixed-point family consists of C1x, C2x, C5x, C2xx, C54x, C55x, C62x,
and C64x. The TMS320 floating-point family includes C3x, C4x, and C67x. Each
generation of the TMS320 series has a unique central processing unit (CPU) with
a variety of memory and peripheral configurations. In this book, we chose the
TMS320C55x as an example for real-time DSP implementations, applications, and

Circular addressing mode supports up to five circular buffers.
.
Single-instruction repeat and block repeat operations of program for supporting
zero-overhead looping.
Detailed information about the TMS320C55x can be found in the manufacturer's
manuals listed in references [1±6].
2.2 TMS320C55x Architecture
The C55x CPU consists of four processing units: an instruction buffer unit (IU), a
program flow unit (PU), an address-data flow unit (AU), and a data computation unit
(DU). These units are connected to 12 different address and data buses as shown in
Figure 2.1.
2.2.1 TMS320C55x Architecture Overview
Instruction buffer unit (IU): This unit fetches instructions from the memory into the
CPU. The C55x is designed for optimum execution time and code density. The instruc-
tion set of the C55x varies in length. Simple instructions are encoded using eight bits
36
INTRODUCTION TO TMS320C55X DIGITAL SIGNAL PROCESSOR
BB

CB DB32 bits
Data
computation
unit
(DU)
Program
flow unit
(PU)
Address data
flow unit
(AU)

program-read data bus. At the same time, the IU can decode up to six bytes of program.
After four program bytes are fetched, the IU places them into the 64-byte instruction
buffer. At the same time, the decoding logic decodes an instruction of one to six bytes
previously placed in the instruction decoder as shown in Figure 2.2. The decoded
instruction is passed to the PU, the AU, or the DU.
The IU improves the efficiency of the program execution by maintaining a constant
stream of instruction flow between the four units within the CPU. If the IU is able to
TMS320C55X ARCHITECTURE
37
hold a segment of the code within a loop, the program execution can be repeated many
times without fetching additional code. Such a capability not only improves the loop
execution time, but also saves the power consumption by reducing program accesses
from the memory. Another advantage is that the instruction buffer can hold multiple
instructions that are used in conjunction with conditional program flow control. This
can minimize the overhead caused by program flow discontinuities such as conditional
calls and branches.
Program flow unit (PU): This unit controls DSP program execution flow. As illus-
trated in Figure 2.3, the PU consists of a program counter (PC), four status registers, a
program address generator, and a pipeline protection unit. The PC tracks the C55x
program execution every clock cycle. The program address generator produces a 24-bit
address that covers 16 Mbytes of program space. Since most instructions will be exe-
cuted sequentially, the C55x utilizes pipeline structure to improve its execution effi-
ciency. However, instructions such as branches, call, return, conditional execution, and
interrupt will cause a non-sequential program address switch. The PU uses a dedicated
pipeline protection unit to prevent program flow from any pipeline vulnerabilities
caused by a non-sequential execution.
Address-data flow unit (AU): The address-data flow unit serves as the data access
manager for the data read and data write buses. The block diagram illustrated in Figure
2.4 shows that the AU generates the data-space addresses for data read and data write.
It also shows that the AU consists of eight 23-bit extended auxiliary registers (XAR0±

DAB
CB

DB
D
A
T
A
M
E
M
O
R
Y
S
P
A
C
E
XAR0
XAR1
XAR2
XAR3
XAR4
XAR5
XAR6
XAR7
XCDP
XSP
16-bit

AC2
AC3
MAC
MAC
16-bit
16-bit
16-bit
Figure 2.5 Simplified block diagram of the C55x data computation unit
and a 40-bit addition or subtraction operation with a saturation option. The ALU can
perform 40-bit arithmetic, logic, rounding, and saturation operations using the four
accumulators. It can also be used to achieve two 16-bit arithmetic operations in both the
upper and lower portions of an accumulator at the same time. The ALU can accept
immediate values from the IU as data and communicate with other AU and PU
registers. The barrel shifter may be used to perform a data shift in the range of 2
À32
(shift right 32-bit) to 2
31
(shift left 31-bit).
2.2.2 TMS320C55x Buses
As illustrated in Figure 2.1, the TMS320C55x has one 32-bit program data bus, five 16-
bit data buses, and six 24-bit address buses. The program buses include a 32-bit
program-read data bus (PB) and a 24-bit program-read address bus (PAB). The PAB
carries the program memory address to read the code from the program space. The unit
of program address is in bytes. Thus the addressable program space is in the range of
TMS320C55X ARCHITECTURE
39
0x000000±0xFFFFFF (the prefix 0x indicates the following number is in hexadecimal
format). The PB transfers four bytes of program code to the IU each clock cycle.
The data buses consist of three 16-bit data-read data buses (BB, CB, and DB) and
three 24-bit data-read addresses buses (BAB, CAB, and DAB). This architecture sup-

user to develop efficient DSP software. The basic software tools include an assembler,
linker, C compiler, and simulator. As discussed in Section 1.4, DSP programs can be
written in either C or assembly language. Developing C programs for DSP applications
requires less time and effort than those applications using assembly programs. However,
the run-time efficiency and the program code density of the C programs are generally
worse than those of the assembly programs. In practice, high-level language tools such
40
INTRODUCTION TO TMS320C55X DIGITAL SIGNAL PROCESSOR
MMRs 00 0000-00 005F 00 0000-00 00BF Reserved
00 0060
00 FFFF
00 00C0
01 FFFF
01 0000
01 FFFF
02 0000
03 FFFF
02 0000
02 FFFF
04 0000
05 FFFF
7F 0000
7F FFFF
FE 0000
FF FFFF
Page 0

Page 1

Page 2

In this section, we will briefly describe the C compiler, assembler, and linker. Afull
description of these tools can be found in the user's guides [2,3].
SOFTWARE DEVELOPMENT TOOLS
41
C
source files
C compiler
Assembler
Assembly
source files
COFF
object files
Linker
Run-time
support
libraries
COFF
executable
file
Library-build
utility
Archiver
Library of
object files
Archiver
Macro
library
Macro
source files
TMS320C55x

42
INTRODUCTION TO TMS320C55X DIGITAL SIGNAL PROCESSOR
Table 2.1 An example of C code and the C55x compiler generated assembly code
Code Mnemonic assembly code Algebraic assembly code
mov *SP(#0), AR2 AR2  *SP(#0)
add #_sineTable, AR2 AR2  AR2  #_sineTable
in_buffer [i]  sineTable [i]; mov *SP(#0), AR3 AR3  *SP(#0)
add #_in_buffer, AR3 AR3  AR3  #_in_buffer
mov *AR2, *AR3 *AR3  *AR2
parameters and prompting the options. It is still beneficial for the user to understand
how to use these tools individually, and set parameters and options from the command
line correctly.
We can invoke the C compiler from a PC or workstation shell by entering the
following command:
c155 [-options][filenames][-z[link_options][object_files]]
The filenames can be one or more C program source files, assembly source files,
object files, or a combination of these files. If we do not supply an extension, the
compiler assumes the default extension as .c, .asm,or.obj. The -z option enables
the linker, while the -c option disables the linker. The link_options set up the way
the linker processes the object files at link time. The object_files are additional
objective files for the linker to add to the target file at link time. The compiler options
have the following categories:
1. The options that control the compiler shell, such as the -g option that generates
symbolic debug information for debugging code.
2. The options that control the parser, such as the -ps option that sets the strict ANSI
C mode for C.
3. The options that are C55x specific, such as the -ml option that sets the large
memory model.
4. The options that control the optimization, such as the -o0 option that sets the
register optimization.

data alignment, section content, etc. Binary object files contain separate blocks (called
sections) of code or data that can be loaded into memory space.
Assembler directives are used to control the assembly process and to enter data
into the program. Assembly directives can be used to initialize memory, define global
variables, set conditional assembly blocks, and reserve memory space for code and data.
Some of the most important C55x assembler directives are described below:
.BSS directive: The .bss directive reserves space in the uninitialized .bss section for
data variables. It is usually used to allocate data into RAM for run-time variables such
as I/O buffers. For example,
.bss xn_buffer, size_in_words
where the xn_buffer points to the first location of the reserved memory space, and the
size_in_words specifies the number of words to be reserved in the .bss section. If
we do not specify uninitialized data sections, the assembler will put all the uninitialized
data into the .bss section.
.DATA directive: The .data directive tells the assembler to begin assembling the
source code into the .data section, which usually contains data tables or pre-initialized
variables such as sinewave tables. The data sections are word addressable.
.SECT directive: The .sect directive defines a section and tells the assembler to
begin assembling source code or data into that section. It is often used to separate long
programs into logical partitions. It can separate the subroutines from the main pro-
gram, or separate constants that belong to different tasks. For example,
44
INTRODUCTION TO TMS320C55X DIGITAL SIGNAL PROCESSOR
.sect "section_name"
assigns the code into the user defined memory section called section_name. Code
from different source files with the same section names are placed together.
.USECT directive: The .usect reserves space in an uninitialized section. It is similar
to the .bss directive. It allows the placement of data into user defined sections instead
of.bss sections. It is often used to separate large data sections into logical partitions,
such as separating the transmitter data variables from the receiver data variables. The

object files for the C55x processor. The following command invokes the C55x mne-
monic assembler:
masm55 [input_file [object_file [list_file]]] [-options]
The input_file is the name of the assembly source program. If no extension is
supplied, the assembler assumes that the input_file has the default extension
SOFTWARE DEVELOPMENT TOOLS
45
.asm. The object_file is the name of the object file that the assembler creates. The
assembler uses the source file's name with the default extension .obj for the object
file unless specified otherwise. The list_file is the name of the list file that the
assembler creates. The assembler will use the source file's name and .lst as the default
extension for the list file. The assembler will not generate list files unless the option -l
is set.
The options identify the assembler options. Some commonly used assembler
options are:
.
The -l option tells the assembler to create a listing file showing where the program
and the variables are allocated.
.
The -s option puts all symbols defined in the source code into the symbol table so
the debugger may access them.
.
The -c option makes the case insignificant in symbolic names. For example, -c
makes the symbols ABC and abc equivalent.
.
The -i option specifies a directory where the assembler can find included files such
as those following the .copy and .include directives.
2.3.3 Linker
The linker is used to combine multiple object files into a single executable program for
the target DSP hardware. It resolves external references and performs code relocation to

We can put the filenames and options inside the linker command file, and then invoke
the linker from the command line by specifying the command file name as follows:
lnk55 command_file.cmd
The linker command file is especially useful when we frequently invoke the linker with
the same information. Another important feature of the linker command file is that it
allows users to apply the MEMORY and SECTION directives to customize the pro-
gram for different hardware configurations. Alinker command file is an ASCII text file
and may contain one or more of the following items:
.
Input files (object files, libraries, etc.).
.
Output files (map file and executable file).
.
Linker options to control the linker as given from the command line of the shell
program.
.
The MEMORY and SECTION directives define the target memory configuration
and information on how to map the code sections into different memory spaces.
The linker command file we used for the experiments in Chapter 1 is listed in Table
2.2. The first portion of the command file uses the MEMORY directive to identify the
range of memory blocks that physically exist in the target hardware. Each memory
block has a name, starting address, and block length. The address and length are given
in bytes. For example, the data memory is given a name called RAM, and it starts at the
byte address of hexadecimal 0x100, with a size of hexadecimal 0x1FEFF bytes.
The SECTIONS directive provides different code section names for the linker to
allocate the program and data into each memory block. For example, the program in
the .text section can be loaded into the memory block ROM. The attributes inside the
parenthesis are optional to set memory access restrictions. These attributes are:
R ± the memory space can be read.
W ± the memory space can be written.

emulator (XDS). The CCS supports both C and assembly programs.
The C55x simulator is available for PC and workstations, making it easy and
inexpensive to develop DSP software and to evaluate the performance of the processor
before designing any hardware. It accepts the COFF files and simulates the instructions
of the program such as the code running on the target DSP hardware. The C55x
simulator enables the users to single-step through the program, and observe the con-
tents of the CPU registers, data and I/O memory locations, and the current DSP states
of the status registers. The C55x simulator also provides profiling capabilities that tell
users the amount of time spent in one portion of the program relative to another. Since
all the functions of the TMS320C55x are performed on the host computer, the simula-
tion may be slow, especially for complicated DSP applications. Real world signals can
only be digitized and then later fed into a simulator as test data. In addition, the timing
of the algorithm under all possible input conditions cannot be tested using a simulator.
As introduced in Section 1.5, the various display windows and the commands of the
CCS provide most debugging needs. Through the CCS, we can load the executable object
code, display a disassembled version of the code along with the original source code, and
48
INTRODUCTION TO TMS320C55X DIGITAL SIGNAL PROCESSOR
Code Composer Studio
.out.asm
.C
.lst/.map/.obj
lnk.cmd
Probe
file in
Probe
file out
Graphic
display
Profile

reading and maintenance, it is strongly recommended that we use meaningful mnemonics
for labels, variables, and subroutine names, etc. An example of a C55x assembly state-
ment is shown in Figure 2.9. In this example, the auxiliary register, AR1, is initialized to a
constant value of 2.
Label field: Alabel can contain up to 32 alphanumeric characters (A±Z, a±z, 0±9, _ ,
and $). It associates a symbolic address with a unique program location. The line that is
labeled in the assembly program can then be referenced by the defined symbolic name.
This is useful for modular programming and branch instructions. Labels are optional,
but if used, they must begin in column 1. Labels are case sensitive and must start with an
alphabetic letter. In the example depicted in Figure 2.9, the symbol start is a label and
is placed in the first column.
Mnemonic field: The mnemonic field can contain a mnemonic instruction, an assem-
bler directive, macro directive, or macro call. The C55x instruction set supports both
SOFTWARE DEVELOPMENT TOOLS
49
my_symbol .set 2 ; my_symbol = 2
start mov #my_symbol,AR1 ; Load AR1 with 2
label
start at
column 1
mnemonic
mov
operand
src,dst
comments
begin with
a semicolon
Figure 2.9 An example of TMS320C55x assembly statement
DSP-specific operations and general-purpose applications (see the TMS320C55x DSP
Mnemonic Instruction Set Reference Guide [4] for details). Note that the mnemonic