expressdsp tm software technology seminar. tms320 tm dsp algorithm standard (xdais) expressdsp ...
TRANSCRIPT
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
ori
thm
In
stan
ce
Ap
pli
cati
on
“F
ram
ewo
rk”
Alg
ori
thm
Mo
du
le
Call algNumAlloc() to get # of memory reqs
Call algAlloc() to get memory requests
Alg
ori
thm
In
stan
ceCall 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
- - 2323
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