eXpressDSP

Modular Application Software Solutions

for TMS320 DSPs

The DSP Software

Challenge

application complexity

software —

the

critical factor

hardware capability

just ship it !!

TIME-TO-MARKET

PRESSURE

insufficient re-use

%

HW

SW

t

increased cost/risk

host computer

Elevating The Platform

TMS320 DSP



integrated development tools



real-time software foundation



standards for interoperability



network of third-party partners

RTDX™

DSP/BIOS™

drivers

comm

alg

alg

alg

alg

alg

alg

target program

application frameworks

Code Composer Studio™



program

build

program

debug

real-time

analysis

plug-in

plug-in

TMS320 DSP

Algorithm

Standard

EDN Innovation of the Year

00101

alg

DSP

DSP

GPP

Grow Your Own ...



app + sched + I/O + comm + algA

n

+ algB

n

+ ...



app + sched + I/O + algA

n

+ algB

n

+ ...



app + sched + algA

n

+ algB

n

+ ...



app + algA + algB + ...



app + alg



alg



too costly to

develop



too costly to

enhance



too costly to

maintain

application

alg

alg

alg

application

alg

alg

scheduler

application

alg

alg

scheduler

I/O

application

alg

alg

application

I/O

scheduler

comm

application

BACKPLANE

FOUNDATION

VALUE-WEB

... Or Leverage Others

CUSTOMER

application

blueprints

application

blueprints

off-the-shelf

algorithms

off-the-shelf

algorithms

DSP/BIOS™

real-time kernel

DSP/BIOS™

real-time kernel

eXpressDSP™

infrastructure

eXpressDSP™

infrastructure



more time to innovate



less time to integrate



ability to differentiate

§

some programming required

M

odular

A

pplication

S

oftware

S

olutions

§

TMS320 DSP Platform

extensible

scalable

DSP/BIOS Kernel Modules

TMS320 Software

Foundation

C5000

C5000

C6000

C6000

target programs

DSP/BIOS Kernel Interface

C2000

C2000



library of essential application services



manages threads, memory, I/O, timers, ...



support for C5000, C6000, C2000 families



consumes minimal MIPS & memory



integrated real-time analysis tools



royalty-free with every TMS320 DSP



robust, field-tested, industry-proven



used in 1000s of active DSP designs

HOST DEVELOPMENT COMPUTER

Code Composer Studio



Programming With DSP/BIOS

TARGET TMS320 DSP HARDWARE

DSP/BIOS Kernel Interface

target application program

executable
image

DEBUG

JTAG

EMULATION

RTDX

kernel modules

CONFIGURATION

VISUALIZATION







C- and ASM-callable
functions



interactive configuration
tool



kernel-aware debug
support



on-the-fly program
analysis

real-time

capture

BUILD

program

sources kernel APIs

multiple

threads

hardware

abstraction

Mass-Market Algorithms

600

300

900



catalog of standard, compliant algorithms



voice, telephony, video, imaging, audio, ...



multiple suppliers — over

50

third-parties



follow uniform set of rules and guidelines



simplifies benchmarking of alternatives



support for C5000, C6000, C2000 families



deployable in static or dynamic systems



E-commerce channel for “one-stop” shop

http//dspvillage.ti.com

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)

Points To Remember

don’t re-invent the wheel

—

build upon the

DSP/BIOS foundation designed & optimized for
DSP applications

shop our value web

— take advantage of our extensive

catalog of

compliant DSP algorithms

FOUNDATION

VALUE-WEB

CUSTOMER

BACKPLANE

innovate and differentiate

— join the 1000s of active

DSP customers already using

Let’s Get Started

get first-hand experience with DSP/BIOS



enroll in our hands-on, one-day training course



prototype your application using our DSP Starter Kit

visit http: //dspvillage.ti.com



app notes, bulletins, FAQs, discussion groups, ...



register at TI&ME for personalized content

explore the world of

compliant DSP algorithms



query our on-line database of third-party products



download the Algorithm Standard Developer’s Kit

eXpressDSP

TM

Software

Technology

Seminar

TMS320

TM

DSP Algorithm Standard

(XDAIS)



eXpressDSP



Algorithms in

Applications



Non-standard

Algorithms



Connecting Vendors &

Users



Benefits of the Standard



Requirements of a

Standard



Introduction



Memory Types



Memory Setup Sequence



Abstract Interface



Instance Objects



Algorithm Coding Rules



Conclusions



What is the benefit of the

standard?



What makes a good

standard?

eXpressDSP

TM

: The DSP Software Solution

Set

Code
Composer
Studio

TM

IDE

Powerful,
integrated
development
tools

DSP/BIOS

Real-time
software
foundation

TI DSP
Third-
Party
Network

Software
and support

TMS320™
DSP
Algorithm
Standard

Standards for
application
interoperabili
ty and reuse

- IDE -

Elements of eXpressDSP

TM

Host Tools

Target Content

TMS320

TM

DSP

•Program Build

•Program Debug

•Data Visualization

•Host APIs

Your Application

•Plug-in Tools

• Analysis

• ADC Config

Host Computer

DSP/BIOS

RTDX

Real-Time Analysis

TMS320

TM

DSP

Algorithm Standard

JTAG

Problems with Non-Standardized

Algorithms

Today it’s difficult to integrate real-time algorithms from

more than single source because of a lack of standards.

• Integration times are extended
• Debugging is tricky (what’s that black box doing ?)
• It’s difficult or impossible to compare similar algorithms
• It’s difficult or impossible to rapidly prototype a system

Alg

Alg

Alg

Alg

Application

TMS320 DSP

Alg

ALGORITHM
PRODUCERS

write once,

deploy widely

Application

Algorithm

ease of

integration

SYSTEM

INTEGRATORS

TMS320

TM

DSP

Algorithm

Standard

Specification

Rules & Guidelines



Programming
rules



Algorithm
packaging



Algorithm
performance



DSP platform



C5000



C6000

TEXAS

INSTRUMENTS

TI Enhances Vendor / User

Process



An algorithm can be inserted into practically any

application



for vendors: larger potential market



for users: yields larger number of algorithms

available



The same code can be used in static or dynamic

systems



for vendors: more reuse potential



for users: more reliability



Algorithms are distributed in binary form



for vendors: Intellectual Property (IP) protection



for users: “black box” simplicity



An application can use algorithms from multiple

vendors



for users: allows greater selection based on system

needs:

power, size, cost, quality, etc



for vendors: levels the playing field

Benefits of the TI DSP Algorithm

Standard



Be easy to adhere to



Be measurable/verifiable as conformed to by algorithms



Enable host tools to simplify:



Configuration



Performance modeling



Standard conformance



Debugging



Incur little or no overhead



Quantify the algorithm’s: memory, latency, speed

For a DSP Algorithm Standard to be successful, it must:

Requirements of a Successful
Standard

TI’s
eXpressDSP
Algorithm
Interface
Specification
meets all these requirements

X

D

A

IS

TMS320

TM

DSP Algorithm

Standard



Algorithm Memory Types



Scratch vs. Persistent



Controlling Memory

Sharing



Static Shared Memory



Introduction



Memory Types



Memory Setup Sequence



Abstract Interface



Instance Objects



Algorithm Coding Rules



Conclusions



What kinds of memory can

algorithms specify?



How do I minimize

memory usage?



What system options do I

have?

Types of Memory Needed by

Algorithms

Stack

Local variables; managed by algorithm

M

a

n

a

g

e

d

b

y

A

p

p

li

c

a

ti

o

n

“

F

ra

m

e

w

o

rk

”

Heap

Contains algorithm objects and variable-length
buffers
Read/Write data
May be allocated and freed at run-time (dynamic
systems)

Scratch memory

Undefined pre & post condition of data in buffer

Persistent memory

Pre-condition(t): data in buffer = post-condition(t -
1)

Static Data

Data allocated at link time; shared by all instances

Algorithm A

Persistent A

Scratch B

Algorithm B

Scratch B

Physical

Memory

Persistent B Scratch A Persistent A

Persistent B

Scratch A

May be OK for speed optimized systems, but may pose problems for
systems where minimum memory usage is desired...

Space Inefficient Memory

Allocation

Scratch Allows for Minimized Memory

Size

Scratch

Algorithm A

Scratch

Algorithm B

Persistent C

Scratch

Algorithm C

Scratch

Physical

Memory

Persistent B

Persistent A

Persistent APersistent BPersistent C

Usually a:
Limited Resource
eg: Internal RAM

Often an:
Extensive Resource
eg: External RAM

Scratch RAM 1

Scratch RAM 2

A

B

C

D

E

A, B, and C are sequential to
each other.

D & E are parallel to A,B, or C,
but sequential to each other

Scratch RAM

A

B

C

D E

F

A-E have enough
space to
all run in parallel.
F needs all the
scratch, so
A-E are all
Deactivated to
make room for F

Scratch management is entirely at the discretion of the application.
The algorithm is not perturbed by the implementation choices selected.

Examples of Scratch RAM

Management...

Shared Scratch Memory

Synchronization

Inhibit preemption when running code that accesses shared memory

• Assign concurrent processes to the same priority = automatic FIFO

otherwise, any number of desired methods can be considered:

• Disable interrupts

HWI_disable

HWI_enable

• Disable scheduler

SWI_disable

SWI_enable

TSK_disable

TSK_enable

• Task Semaphores (lock, unlock) SEM_pend

SEM_post

• Raise priority

SWI_raisepri SWI_restorepri

TSK_setpri

TSK_setpri

Instance

0

Static Read-only Data

Instance

n

…

Static global data

Instance heap data

Shared Persistent Memory

• Static read-only tables

– Optimize reuse (e.g., in on-chip memory) by sharing global read-only

data for multiple instances of an algorithm

– Separate object referenced by multiple instances

Example: 2 FIR filters with identical - fixed - coefficient tables

TMS320

TM

DSP Algorithm

Standard



Introduction



Memory Types



Memory Setup Sequence



Abstract Interface



Instance Objects



Algorithm Coding Rules



Conclusions



What are the steps to

setting up the memories

needed?



What optional controls

are available?



How do we optimize for

static and dynamic

systems?



Memory Setup Model



Memory Setup Sequence



IALG Options



IALG Interface

Algorithm
Knows memory requirements
Requests appropriate

resources from Application

Application “Framework”
Manages memory

requirements
Determines what

memories are available to

which algorithms - and

when

Physical Memory

Types:

External (slow, plentiful, lower

cost)
Internal (fast, limited, higher

cost)
SARAM, DARAM

Size

Size

Alignme

nt

Alignme

nt

Type

Type

Scr/Persi

st

Scr/Persi

st

Address

Address

Size

Size

Alignme

nt

Alignme

nt

Type

Type

Scr/Persi

st

Scr/Persi

st

Address

Address

Size

Size

Alignme

nt

Alignme

nt

...

...

Memory Setup Model



To Alg: How many blocks of memory do you need?

algNumAlloc()

To App: n App: make 5*n words of memory table (memtab) available



To Alg : Write the needs of each block to memtab.

algAlloc()

Alg: writes 4 values describing block info (size, alignment, type, scratch/persistent)
App: set aside specified memories, fill in address of blocks in memtab



To Alg: Here’s the memories I got for you.

algInitObj()

Alg: copy address pointers to my instance structure and set up persistent arrays



To Alg: Get ready to run - prepare your scratch memory.

algActivate()

Alg: fill up my scratch memory as desired (eg: history buffers, etc)



App may now call alg processing functions to run it’s routines…



To Alg: I need your scratch memory back. algDeactivate()
Alg: copy needed scratch values to persistent memory



To Alg: Update memtab so I know what I can free up. algFree()
Alg: update 5*n values in memtab
App: de-allocate any desired scratch memories for use by other components

Algorithm Memory Interrogation

Sequence

A

lg

o

ri

th

m

In

st

a

n

c

e

A

p

p

li

c

a

ti

o

n

“F

ra

m

e

w

o

rk

”

A

lg

o

ri

th

m

M

o

d

u

le

Call algNumAlloc() to get # of memory reqs

Call algAlloc() to get memory requests

A

lg

o

ri

th

m

In

st

a

n

c

e

Call algActivate() to prep instance for use

Call algDeactivate() to prep for mem re-use

Initialize scratch memory

Call algorithm processing methods Process data, return result

Save state to persistent memory

Call algInitObj() to initialize instance object

Initialize instance object

Call algFree() to retrieve buffer pointers

Return all buffers and sizes

malloc()

free()

IALG Object Creation Sequence

Diagram

algNumAlloc()

algAlloc()

algInitObj()

algDeactivate()

algFree()

algActivate()

algMoved()

PROCESS

Dynamic Systems:



Run Once: Activate, Process, De-activate



Run Many: Activate, Process, Process, … , De-activate



Run Always: Activate, Process, Process, …



Change Resources: “algMoved()”

Static Systems:



Setup memory at build-time



At run-time: “Process” only

Optional

Function

s

Required

Function

s

IALG Sequencing &
Options

TMS320

TM

DSP Algorithm

Standard



IALG Abstract Interface



Module Interface



Interface Options



Naming Rules



Introduction



Memory Types



Memory Setup Sequence



Abstract Interface



Instance Objects



Algorithm Coding Rules



Conclusions



How do I access IALG

functions?



How do I access algorithm

functions?



Is there a naming style I

can rely upon?

algNumAlloc

return maximum number of

memory requests
algAlloc

return all memory allocation

requests to application
algInitObj

initialize allocated instance

memory
algActivate

initialize scratch memory from

persistent memory
algMoved

instance memory moved

algControl

algorithm specific control

operations
algDeactivate

save persistent data in scratch

memory
algFree

return pointers to all instance

memory

IALG Interface

IALG is an abstract interface that separates the algorithm

from application scheduling and memory management
policies.

Compliant algorithms are packaged in modules that include

the IALG implementation.

IALG_Fxns

Void algActivate(IALG_Handle);
Int

algAlloc(const IALG_Params *,…);

Int

algControl(IALG_Handle, …);

Int

algDeactivate(IALG_Handle);

Int

algFree(IALG_Handle, …);

Int

algInit(IALG_Handle, …);

Void

algMoved(IALG_Handle, …);

Int

algNumAlloc();

Void

decode(IG729_Handle, IG729_Frm …);

Void

encode(IG729_Handle, Int16 *in,…);

Void

…

IG729_Fxns

-

-

34

34

Algorithm interfaces are abstract interfaces derived from IALG

IALG functions provide the methods to create/manage “instance
objects”
Additional module-specific functions are appended to access
the algorithms themselves

Abstract interfaces define a “v-table” for accessing the module’s
functions
Abstract interfaces define module functions as a structure of
pointers

Algorithm “Module”
Interface

Application

Standard

Module

Vendor

Algorithm

Standard Interface:

Abstract Template

Defined by TI

IALG table only

Module Interface:

Required for compliance

Defined by Vendor

IALG + Alg Fxns

Vendor Interface:

Optional Method

Defined by Vendor

eg: “shortcuts”

Interface Options

All external identifiers follow the format: MODule_VENder_xxx



example: Line Echo Canceller from Texas Instruments: LEC_TI_run



extensions to the library file types define the target architecture :
MOD_VEN.a62

62xx target

MOD_VEN.a62e 62xx target - big endian
MOD_VEN.a54f 54x target - far call/rtn version
MOD_VEN.a54n 54x target - near call/rtn version

Avoid name space pollution (target symbols, development system

files)

Enable tool support

Semantics of operations and object files can be inferred
Installation is simplified; generic installation programs can be

created

Supports vendor differentiation: Vendor specific operations can be

added

Simplifies code audits: Understand one algorithm you know them

all

Naming Rules

TMS320

TM

DSP Algorithm

Standard



The Instance Object



App to Alg Control Flow



Re-entrancy



Multiple Instances



Introduction



Memory Types



Memory Setup Sequence



Abstract Interface



Instance Objects



Algorithm Coding Rules



Conclusions



How does the application

find and interact with the

algorithm functions?



How do we assure no

hardware conflicts

between algorithms?



What about the case of re-

entrancy or multiple

instances of an algorithm?

Application to Algorithm Control

Interface

.text
num
…
alloc
…

run

…

.cinit
copy of
V table

.bss
globals

vtable “XY”

X_Y_num
X_Y_alloc
X_Y_init
…
X_Y_run
…

module interface algorithm code

.bss / stack
handleXY

.sysmem
instanceXY
*IALG_Fxns

*a
*x
len
...

Instance Object:
table of pointers to data

structures
1:

ptr. to v.table

2-N: alg data arrays and

variables

Application to Algorithm

Chronology

.text
alg
code
...
.cinit
copy of
V table

.bss / stack
handleXY

.sysmem
instanceXY

*IALG_Fxns
*a
*x
*x_stg

1. On build

Alg code

2. At boot

V.table

3. FIR_TI_Alloc()

mem for:

inst obj,

x, a, x_stg

4. FIR_TI_InitObj() fill inst.obj

& persist

5. FIR_TI_Activate()

fill

scratch
6. FIR_TI_Run()

process FIR

filter
7. FIR_TI_Deactiv()

x[100] to

x_stg, reclaim x
8. FIR_TI_Free

reclaim

inst.obj,x_stg, a

x

+

.bss
globals

vtable XY

a[100]

x[100]

x_stg[100]

SWI A

IDLE

Hi

Priority

Low Priority

Process

Process

SWI B

Process

Concurrent running of multiple instance of the same

algorithm must be supported. Allow repeated entries in a

preemptive environment

Reentrancy enables multiple channel (instance) systems

“Reentrancy is the attribute of a program or routine that

allows the same copy of a program or routine to be used

concurrently by two or more threads”

During this time, both A

and B are running the

same function. How do we

avoid having A’s context

overwrite B’s?

During this time, both A

and B are running the

same function. How do we

avoid having A’s context

overwrite B’s?

Re-entrancy & Multiple

Instances

Multiple Instances of an

Algorithm

.text
alg
code
.cinit
copy of
V table

.bss/stack
handleXY1

handleXY2

instanceXY1

*IALG_Fxns
*a
*x
*x_stg

instanceXY2

*IALG_Fxns
*a
*x
*x_stg

Allocate, Activate as many

instances as required

Uniquely named handles

allow control of individual
instances of the same
algorithm

All instance objects point to

the same v.table

Constant tables are common
Scratch can be common or

separate as desired

.bss
globals

vtable XY

a[100]

x[100]

x_stg[100]

x[100]

x_stg[100]

TMS320

TM

DSP Algorithm

Standard



Coding Rules



Threads vs Algorithms



Object Based

Programming



Introduction



Memory Types



Memory Setup Sequence



Abstract Interface



Instance Objects



Algorithm Coding Rules



Conclusions



What rules do compliant

algorithm functions

follow?



How do algorithms relate

to

the DSP/BIOS scheduling

environment?



How do the various

concepts relate to each

other?

Application

Alg

Alg

Alg

Core Run-time

A/D

D/A

ctrl

status

DSP

A

lg

o

S

ta

n

d

a

rd



General Coding:



No self-modifying code



C callable



Re-entrant



Processor Access



No direct memory allocation



Relocatable data and code



No direct peripheral interface

Application “Framework” manages

all hardware resources

Benefits:



No hardware contention



Portability to other DSPs

Algorithm Standard Coding

Rules

Threads vs Algorithms

Compliant algorithms are
• “pure” data transducers with state: not threads
• “black box” components - accessed by v.table
• extensible via vendor interface option

– Allows for unique methods and creation parameters
– Users may directly access these features but lose interchangeability

A thread may call multiple algorithm

instances

Algorithms are not, and may not uses threads

Algorithms are “data transducers” not

schedulers

G.168

Thread “A”

G.729

X

DTMF

G.729

Y

DTMF

Thread “B”

Object Based Programming

Environment

• Module

– Smallest logical unit of software
– Each module has, defined in the module’s header file, a particular

• Interface and calling conventions
• Data structures

• Interface

– Used by the client to systematically interact with a module
– Relates a set of constants, types, variables & functions visible to

client

• Instance Object

– Unique set of parameters that define the state of each instance

TMS320

TM

DSP Algorithm

Standard



Value of the Standard



Algorithm “Package”



Algorithm

Documentation



Developer Resources



System Overhead



Introduction



Memory Types



Memory Setup Sequence



Abstract Interface



Instance Objects



Algorithm Coding Rules



Conclusions



An application can use algorithms from multiple

vendors



An algorithm can be inserted into practically any

application



The same code can be used in static or dynamic

systems



Algorithms can be distributed in binary form



Be measurable/verifiable as conformed to by

algorithms



Enable host tools to simplify:



Configuration



Performance modeling



Standard conformance



Debugging



Quantify the algorithm’s: memory, latency, speed



Be easy to adhere to



Incur little or no overhead



off-the-shelf DSP
content



Faster, easier
algorithm
integration

Value of the TMS320

TM

DSP Algorithm

Standard

Compliant Algorithms must include:



Libraries of the code provided



Header files listing the implemented abstract interfaces



Documentation defining the algorithm

LIB

H

DOC

TMS320

TM

DSP Algorithm Standard

Compliant Algorithm
“Package”

All algorithms
must
characterize
their:
Memory
requirements
Execution time
Interrupt
latency

Standard basis
for
comparison
and tradeoffs

Algorithm Performance

Characterization

Algorithm Developer
Resources



Documents

– Manuals
– Application notes

Developers kit

– Runtime support libraries and all interface headers
– Example algorithms and applications source code
– Development tools

Web resource


www.dspvillage.ti.com

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 interfere 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 and 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

Further Reading on XDAIS

•

Reference Frameworks for eXpressDSP Software: A White Paper

\XDAIS\spra094.pdf

•

Reference Frameworks for eXpressDSP Software: API Reference

\XDAIS\spra147.pdf

•

Using the TMS320 DSP Algorithm Standard in a Static DSP System

\XDAIS\spra577b.pdf

•

Making DSP Algorithms Compliant with the TMS320 DSP Algorithm Standard

\XDAIS\spra579b.pdf

•

Using the TMS320 DSP Algorithm Standard in a Dynamic DSP System

\XDAIS\spra580b.pdf

•

The TMS320 DSP Algorithm Standard

\XDAIS\spra581b.pdf

•

Achieving Zero Overhead With the TMS320 DSP Algorithm Standard IALG Interface

\XDAIS\spra716.pdf

•

Real-Time Analysis in an eXpressDSP-Compliant Algorithm

\XDAIS\spra732.pdf

•

Reference Frameworks for eXpressDSP Software: RF1, A Compact Static System

\XDAIS\spra791b.pdf

Further Reading on XDAIS

•

Reference Frameworks for eXpressDSP Software: RF3, A Flexible, Multi-Channel,
Multi-Algorithm, Static System

\XDAIS\spra793b.pdf

•

TMS320 DSP Algorithm Standard Rules and Guidelines

\XDAIS\spru352d.pdf

•

TMS320 DSP Algorithm Standard API Reference

\XDAIS\spru360b.pdf

•

TMS320 DSP Algorithm Standard Demonstration Application

\XDAIS\spru361d.pdf

•

TMS320 DSP Algorithm Standard Developer’s Guide

\XDAIS\spru424.pdf

•

TMS320 DSP Algorithm Standard

\XDAIS\spru427.pdf