TMS320 DSP 
Algorithm Standard:
Overview & 
Rationalization

 

 

Agenda



Overview



Interactions with 

eXpressDSP Technologies



Rationalization and 

Benefits

 

 

TMS320 DSP Algorithm Standard

Rules & Guidelines



uniform naming conventions



register usage requirements



data addressing modes



re-entrant, relocatable code



memory allocation policies



access to HW peripherals



minimizing interrupt latency



performance characterization

Common Programmatic Interface

write once, deploy widely

ALGORITHM

PRODUCERS

ease-of-integration

ALGORITHM

CONSUMERS

static 

 

 alg

1

 



  chan

1

dynamic 

 

 alg

n

 

 

 chan

n

Resource Management Framework(s)

 

 

eXpressDSP

TM

 - Technology Interactions

Logical

Temporal

Physical

Code Composer Studio
get the code to work
Single channel, single 

algorithm
Single GUI for develop & 

debug
Graphical Data Analysis
Expandable by 3P plug-ins

DSP/BIOS II
meet real-time goals
Multi-algorithm
Software scheduling
Real-time analysis
Hardware abstraction

DSP Algorithm Standard
off-the-shelf software
Multi-Channel
Static or dynamic
Memory and DMA 

management
Single or multi-channel

eXpressDSP

TM

Different tools to solve
different problems

 

 

Algorithm Standard - Rules & 

Benefits

Portability/Flexibility
Re-entrant code
Code must be re-

locatable
No direct access 

peripherals

Consistency/Ease of 

Integration
Hands off certain 

registers
Access all data as far 

data
Little endian format
DSP/BIOS name 

conventions

Usability/Interoperability
Standardized memory 

management
Standardized DMA 

management

Measurability
Worst case memory usage
Worst case interrupt latency
Worst case execution time

 

 

Objective

Explain the rationale behind the 
rules of the eXpressDSP Algorithm 
Standard and their benefits to 
customers of compliant algorithms.

 

 

Definition

TMS320 DSP Algorithm 
Standard

 

A set of rules designed to ensure 
components interoperate with algorithms 
from different vendors in virtually any 
application.

 

 

All algorithms must follow the run-time 
conventions imposed by TI’s implementation of 
the C programming language

Need to avoid having algorithm interefere with 

application state

Top-most interface must be “C callable”

Most DSP systems run in C environment – common 

interface language and run-time support libraries used

Respect C Run-time 

Conventions

B

e

n

e

f

i

t

s

Ease of Integration

Binding algorithms to application
Control flow of data between algorithms
No run-time surprises

 

 

All algorithms must be re-entrant within a 
preemptive environment

Algorithm code running multiple times simultaneously

Multi-channel systems (e.g. servers)

Real-time systems with real-time OS

Tasks are independent of each other reentrancy must be 

ensured

memory or global variables shared by multiple instances 

must be protected 

Algorithms Must be Re-entrant

B

e

n

e

f

i

t

s

Flexibility

Optimized program memory usage (e.g. multiple 

channels will be running same code)

Maintains integrity of algorithm instance data

 

 

All algorithms data (code) references must be 
fully relocatable.  There must be no “hard 
coded” data (program) memory locations.

Data & Code Relocatability

Ability to run algorithm components from any type of 

memory

Optimized use of memory resources

Allows any number of instances without data collisions

B

e

n

e

f

i

t

s

Portability

Transfer algorithms between 

systems

Flexibility

Placement of algorithm 

components anywhere in 
memory

Running algorithms within a range 

of operating environments

 

 

No Direct Peripheral Access

Algorithms cannot know what peripherals exist or are 

available

Specific resources will vary from system to system
Multiple algorithms will compete for resources
Peripherals need to be configured differently for various 

algos

Algorithms must never directly access any 
peripheral device.  This includes, but is not limited 
to, on-chip DMA, timers, I/O devices, and cache 
control registers.

B

e

n

e

f

i

t

s

Interoperability

Framework manages 

resources

No resource competition

Portability

Transfer s/w between systems
Platform independence

 

 

•All external definitions must be either API 

references or API and vendor prefixed.

•All modules must follow the naming conventions 

of the DSP/BIOS for those external declarations 
exposed to the client.

•All external definitions must be either API 

references or API and vendor prefixed.

•All modules must follow the naming conventions 

of the DSP/BIOS for those external declarations 
exposed to the client.

Symbol Naming 
Conventions



 Algorithms must avoid name space collisions



 Different algorithms may have same name for data types and 

functions



 Application cannot resolve multiply-defined symbols

B

e

n

e

f

i

t

s

Consistency

Enhanced code readability
Compliant algorithms 

intended for use with 
DSP/BIOS

Ease of integration

No name space collision
Single consistent naming 

convention

Shorter system integration time

 

 

All undefined references must refer to operations 
from a subset of C runtime support library 
functions, DSP/BIOS or other eXpressDSP-
compliant  modules. 

All undefined references must refer to operations 
from a subset of C runtime support library 
functions, DSP/BIOS or other eXpressDSP-
compliant  modules. 

Module External 
References



Algorithms are as compliant as the modules they 
invoke



Algorithm must not reference non-compliant modules

B

e

n

e

f

i

t

s

Consistency

Enhanced code readability
Compliant algorithms 

intended for use with 
DSP/BIOS

Ease of integration

DSP/BIOS and C RTS part of CCS
Single consistent naming 

convention

Shorter system integration time

 

 

Abstract Interface 

Implementation



Defines communication protocol between client and 

algorithm



Enables client to create, manage and terminate algorithm 

instances



Run in virtually any system (preemptive and non-

preemptive, static and dynamic)



Common to all compliant algorithms

All algorithms must implement the IALG 
interface. 

All algorithms must implement the IALG 
interface. 

B

e

n

e

f

i

t

s

Interoperability/Consiste

ncy

Uniform abstract interface

Ease of integration

Uniform abstract interface
Learn once apply many
Shorter system integration 

time

Flexibility

Running algorithms in 

virtually any execution 
environment

 

 

Abstract Interface 

Implementation



Need for design/run-time creation of algorithm 
instances



Ability to relocate algorithm interface methods in 
memory



Ability to discard unused functions to reduce code size



Optimized use of program memory

Each of the IALG methods implemented by an 
algorithm must be independently relocatable.

Each of the IALG methods implemented by an 
algorithm must be independently relocatable.

B

e

n

e

f

i

t

s

Flexibility

Placement of  algorithm components anywhere in 

memory

Support for design/run-time (static/dynamic) integration

(SPRA577, SPRA580, SPRA716) 

 

 

Each compliant algorithm must be packaged in an archive 
which has a name that follows a uniform naming 
convention.

Each compliant algorithm must be packaged in an archive 
which has a name that follows a uniform naming 
convention.

Algorithm Packaging

B

e

n

e

f

i

t

s

Consistency

Uniform naming 

convention

Ease of integration

Single consistent naming 

convention

Unique archive names (no symbol 

collision)

Shorter system integration time



Integrate different algorithms without symbol collision



Unique archive names between different/versions of 

algorithms



Uniform format for delivering algorithms



All algorithm modules built into a single archive



Use of algorithms in different development platforms 

(UNIX, Win)



Archive names are case sensitive

Flexibility

Support different development 

systems

 

 

Performance and Requirements 

Metrics

B

e

n

e

f

i

t

s

Measurability

Up-front assessment 

and comparison tool 

Ease of integration

Determine algorithm compatibility with 

system

Optimum data/code placement in memory
Optimum resource allocation (static, stack, 

etc.)

Optimum scheduling (latency, execution, 

etc.)



Planning integration of algorithm A vs. B into system



Assess performance metrics and compatibility with 

system



Assess resource requirements and compatibility with 

system

All compliant algorithms must characterize:

•Program/heap/static/stack memory requirements

•Worst case interrupt latency

•Typical period and worst case execution for each 
method

All compliant algorithms must characterize:

•Program/heap/static/stack memory requirements

•Worst case interrupt latency

•Typical period and worst case execution for each 
method

 

 

Summary of Key Benefits

Flexibility

–

Algorithm components anywhere in memory

–

Algorithms run in virtually any execution 
environment

–

Design/run-time integration

–

Different development systems

–

Multi-channel

Interoperability



Uniform abstract 
interface



No resource competition

Portability



Transfer s/w between 
systems



Platform independence

Consistency



Uniform naming 
conventions



Enhanced code 
readability

Measurability



Up-front assessment and 
comparison tool for 
planning algorithm A vs. 
B

Ease of Integration



Uniform abstract interface (learn 
once apply many)



Single consistent naming 
convention



Shorter system integration time



Determine algorithm 
compatibility with system



No run-time surprises