eXpressDSP
Modular Application Software Solutions
for TMS320 DSPs
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
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
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
•
Reference Frameworks for eXpressDSP Software: API Reference
•
Using the TMS320 DSP Algorithm Standard in a Static DSP System
•
Making DSP Algorithms Compliant with the TMS320 DSP Algorithm Standard
•
Using the TMS320 DSP Algorithm Standard in a Dynamic DSP System
•
The TMS320 DSP Algorithm Standard
•
Achieving Zero Overhead With the TMS320 DSP Algorithm Standard IALG Interface
•
Real-Time Analysis in an eXpressDSP-Compliant Algorithm
•
Reference Frameworks for eXpressDSP Software: RF1, A Compact Static System
Further Reading on XDAIS
•
Reference Frameworks for eXpressDSP Software: RF3, A Flexible, Multi-Channel,
Multi-Algorithm, Static System
•
TMS320 DSP Algorithm Standard Rules and Guidelines
•
TMS320 DSP Algorithm Standard API Reference
•
TMS320 DSP Algorithm Standard Demonstration Application
•
TMS320 DSP Algorithm Standard Developer’s Guide
•
TMS320 DSP Algorithm Standard