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