expressdsp
DESCRIPTION
eXpressDSP. Modular Application Software Solutions for TMS320 DSPs. The DSP Software Challenge. application complexity. hardware capability. just ship it !!. TIME-TO-MARKET PRESSURE. insufficient re-use. increased cost/risk. HW. %. SW. t. software — the critical factor. - PowerPoint PPT PresentationTRANSCRIPT
eXpressDSPModular Application Software Solutions
for TMS320 DSPs
The DSP Software Challenge
application complexity
software — the critical factor
hardware capability
just ship it !!
TIME-TO-MARKETPRESSURE
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 programapplication frameworksCode Composer Studio™
programbuild
programdebug
real-timeanalysis
plug-in plug-in TMS320 DSPAlgorithmStandard
EDN Innovation of the Year
00101
alg
DSP DSP GPP
Grow Your Own ...
app + sched + I/O + comm + algAn + algBn + ...
app + sched + I/O + algAn + algBn + ...
app + sched + algAn + algBn + ...
app + algA + algB + ...
app + alg
alg
too costly to develop
too costly to enhance
too costly to maintain
application
alg
alg alg
application
algalg
scheduler
application
algalg
scheduler
I/O
application
algalg
application
I/O
scheduler
comm
application
BACKPLANE
FOUNDATION
VALUE-WEB
... Or Leverage Others
CUSTOMER
applicationblueprints
applicationblueprints
off-the-shelfalgorithms
off-the-shelfalgorithms
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
ModularApplicationSoftwareSolutions§
TMS320 DSP Platform
extensiblescalable
DSP/BIOS Kernel Modules
TMS320 Software Foundation
C5000C5000 C6000C6000
target programs
DSP/BIOS Kernel Interface
C2000C2000
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 programexecutableimage
DEBUG
JTAGEMULATION
RTDX
kernel modules
CONFIGURATION
VISUALIZATION
C- and ASM-callable functions
interactive configuration tool
kernel-aware debug support
on-the-fly program analysis
real-timecapture
BUILD
programsources kernel APIs
multiplethreads
hardwareabstraction
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
ALGORITHMPRODUCERS
ease-of-integrationALGORITHMCONSUMERS
static alg1 chan1 dynamic algn chann
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
eXpressDSPTM Software Technology
Seminar
TMS320TM 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?
eXpressDSPTM: The DSP Software Solution Set
Code Composer StudioTM IDE Powerful,integrated developmenttools
DSP/BIOSReal-time software foundation
TI DSPThird-Party NetworkSoftwareand support
TMS320™ DSP Algorithm StandardStandards for application interoperability and reuse
- IDE -
Elements of eXpressDSPTM
Host Tools Target Content
TMS320TM DSP
• Program Build• Program Debug• Data Visualization• Host APIs
Your Application
• Plug-in Tools• Analysis• ADC Config
Host Computer
DSP/BIOSRTDX Real-Time Analysis
TMS320TM DSPAlgorithm 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
AlgAlg
Alg
Application
TMS320 DSP
Alg
ALGORITHMPRODUCERS
write once, deploy widely
ApplicationAlgorithm
ease of integration
SYSTEMINTEGRATORS
TMS320TM DSP AlgorithmStandard
Specification
Rules & Guidelines Programming rules Algorithm packaging Algorithm performance DSP platform
C5000 C6000
TEXASINSTRUMENTS
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
XDAIS
TMS320TM 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
StackLocal variables; managed by algorithm
Man
aged
by
App
licat
ion
“Fra
mew
ork” Heap
Contains algorithm objects and variable-length buffers Read/Write data May be allocated and freed at run-time (dynamic systems)
Scratch memoryUndefined pre & post condition of data in buffer
Persistent memory Pre-condition(t): data in buffer = post-condition(t - 1)
Static DataData allocated at link time; shared by all instances
Algorithm A Persistent A
Scratch BAlgorithm B
Scratch BPhysicalMemory
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
ScratchAlgorithm A
ScratchAlgorithm B
Persistent CScratchAlgorithm C
ScratchPhysicalMemory
Persistent B
Persistent A
Persistent A Persistent B Persistent C
Usually a: Limited Resourceeg: Internal RAM
Often an: Extensive Resourceeg: 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, soA-E are all Deactivated tomake 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_enableTSK_disable TSK_enable
• Task Semaphores (lock, unlock) SEM_pend SEM_post• Raise priority SWI_raisepri SWI_restorepri
TSK_setpri TSK_setpri
Instance0
Static Read-only Data
Instancen
… 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
TMS320TM 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 controlsare available?
How do we optimize forstatic 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
SizeSize
AlignmentAlignment
TypeType
Scr/PersistScr/Persist
AddressAddress
SizeSize
AlignmentAlignment
TypeType
Scr/PersistScr/Persist
AddressAddress
SizeSize
AlignmentAlignment
......
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
Alg
orit
hm I
nsta
nce
Ap
plic
atio
n “
Fra
mew
ork”
Alg
orit
hm M
odul
e
Call algNumAlloc() to get # of memory reqs
Call algAlloc() to get memory requests
Alg
orit
hm I
nsta
nce
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 Functions
Required Functions
IALG Sequencing & Options
TMS320TM 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
- - 3434
Algorithm interfaces are abstract interfaces derived from IALGIALG functions provide the methods to create/manage “instance objects”Additional module-specific functions are appended to accessthe algorithms themselves
Abstract interfaces define a “v-table” for accessing the module’s functionsAbstract 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 inferredInstallation is simplified; generic installation programs can be created
Supports vendor differentiation: Vendor specific operations can be addedSimplifies code audits: Understand one algorithm you know them all
Naming Rules
TMS320TM 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
…
.cinitcopy 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
...
.cinitcopy of V table
.bss / stack
handleXY
.sysmem
instanceXY
*IALG_Fxns
*a
*x
*x_stg
1. On build Alg code2. At boot V.table3. FIR_TI_Alloc() mem for: inst obj,
x, a, x_stg4. FIR_TI_InitObj() fill inst.obj & persist
5. FIR_TI_Activate() fill scratch6. FIR_TI_Run() process FIR filter7. FIR_TI_Deactiv() x[100] to x_stg, reclaim x8. 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 environmentReentrancy 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.textalgcode.cinitcopy 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 commonScratch can be common or separate
as desired
.bss
globals
vtable XY
a[100]
x[100]
x_stg[100]
x[100]
x_stg[100]
TMS320TM 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
Alg
o S
tan
dar
d
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” managesall 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 instancesAlgorithms are not, and may not uses threads
Algorithms are “data transducers” not schedulers
G.168
Thread “A”
G.729X
DTMF
G.729Y
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
TMS320TM 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 TMS320TM 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
TMS320TM DSP Algorithm Standard
Compliant Algorithm “Package”
All algorithms must characterize their:Memory requirementsExecution timeInterrupt 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 AlgorithmStandard:
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
ALGORITHMPRODUCERS
ease-of-integrationALGORITHMCONSUMERS
static alg1 chan1 dynamic algn chann
Resource Management Framework(s)
eXpressDSPTM - 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
eXpressDSPTM
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
Benefits
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 simultaneouslyMulti-channel systems (e.g. servers)
Real-time systems with real-time OSTasks 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
Benefits
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
Benefits
PortabilityTransfer algorithms between systems
FlexibilityPlacement 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 availableSpecific resources will vary from system to systemMultiple algorithms will compete for resourcesPeripherals 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.
Benefits
InteroperabilityFramework manages resources
No resource competition
PortabilityTransfer 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
Benefits
ConsistencyEnhanced code readability
Compliant algorithms intended for
use with DSP/BIOS
Ease of integrationNo 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
Benefits
ConsistencyEnhanced code readability
Compliant algorithms intended for
use with DSP/BIOS
Ease of integrationDSP/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.
Benefits
Interoperability/ConsistencyUniform abstract interface
Ease of integrationUniform abstract interface
Learn once apply many
Shorter system integration timeFlexibility
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.
Benefits
FlexibilityPlacement 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
Benefits
ConsistencyUniform 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
FlexibilitySupport different development systems
Performance and Requirements Metrics
Benefits
MeasurabilityUp-front assessment and
comparison tool
Ease of integrationDetermine 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