1 expressdsp software technology seminar. 2 1.introduction 2.tms320 family of digital signal...
Post on 18-Jan-2018
215 Views
Preview:
DESCRIPTION
TRANSCRIPT
1eXpressDSP™ Software Technology Seminar
2
1. Introduction
2. TMS320™ Family of Digital Signal Processors
3. Software Development with Code Composer Studio™ IDE
4. Real-Time Software Analysis with DSP/BIOS
5. Real-Time Software Scheduling with DSP/BIOS
6. The TMS320™ DSP Algorithm Standard
7. Conclusion
Contents
3TMS320™ DSP Algorithm Standard (XDAIS)
eXpressDSP™ Software
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 ofThe Standard?
What makes a good standard?
4eXpressDSP™: The DSP Software Solution Set
Code Composer Studio™ IDE Powerful,integrated developmenttools
DSP/BIOSReal-time software foundation
TI DSPThird-Party NetworkSoftwareand support
TMS320™ DSP Algorithm StandardStandards for application interoperability and reuse
5
- IDE -
Elements of eXpressDSP™
Host Tools Target Content
TMS320™ DSP
• Program Build• Program Debug• Data Visualization• Host APIs
Your Application
• Plug-in Tools• Analysis• ADC Config
Host Computer DSP/BIOSRTDX Real-Time Analysis
TMS320™ DSPAlgorithm Standard
JTAG
6Problems with Non-Standardized Algorithms
Today it’s difficult to integrate real-time algorithms from more than a 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
7
ALGORITHMPRODUCERS
Write once, deploy widely
ApplicationAlgorithm
Ease of integration
SYSTEMINTEGRATORS
TMS320™ DSP AlgorithmStandard
Specification
Rules & Guidelines Programming rules Algorithm packaging Algorithm performance DSP platform
C5000™ C6000™
TEXASINSTRUMENTS
TI Enhances Vendor / User Process
8
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
9
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
eXpressDSP™ AlgorithmInterface Specificationmeets all these requirements
XDAIS
10TMS320™ 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?
11Types of Memory Needed by Algorithms
Stack Local variables; managed by algorithm
Man
aged
by
Appl
icat
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 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
12
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
13Scratch 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 Resourcee.g.: Internal RAM
Often an: Extensive Resourcee.g.: External RAM
14
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 ...
15Shared 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
16
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
17TMS320™ 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
18
AlgorithmKnows memory requirementsRequests appropriate resources from Application
Application “Framework”Manages memory requirementsDetermines what memories are available to which algorithms - and whenPhysical Memory Types:External (slow, plentiful, lower cost)Internal (fast, limited, higher cost) SARAM, DARAM
SizeAlignment
TypeScr/Persist
AddressSize
AlignmentType
Scr/PersistAddress
SizeAlignment
...
Memory Setup Model
19
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: These are 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 (e.g.: history buffers, etc.)
App may now call alg processing functions to run its 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: Deallocate any desired scratch memories for use by other components
Algorithm Memory Interrogation Sequence
20
Alg
orith
m In
stan
ce
App
licat
ion
“Fr
amew
ork”
Alg
orith
m M
odul
e
Call algNumAlloc() to get # of memory reqs
Call algAlloc() to get memory requests
Alg
orith
m 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
21
algNumAlloc()
algAlloc() algInitObj()
algDeactivate()algFree()
algActivate()
algMoved() PROCESS
Dynamic Systems: Run once: Activate, Process, Deactivate Run many: Activate, Process, Process, … , Deactivate 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
22TMS320™ 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?
23
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.
24
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
- - 2424
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
25
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
e.g.: “Shortcuts”
Interface Options
26
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 C62x™ targetMOD_VEN.a62e C62x™ target - big endianMOD_VEN.a54f C54x™ target - far call/rtn versionMOD_VEN.a54n C54x™ 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
27TMS320™ DSP Algorithm Standard
The Instance Object
App to Alg Control Flow
Reentrancy
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?
28
.textnum …alloc …
run …
.cinitcopy of V table
Algorithm code
.bss globals
vtable “XY”X_Y_numX_Y_allocX_Y_init…X_Y_run…
Module interface
.bss / stack handleXY
.sysmem instanceXY *IALG_Fxns
*a*xlen...
Instance Object:table of pointers to data structures1: ptr. to v.table2-N: alg data arrays and variables
Application-to-Algorithm Control Interface
29Application-to-Algorithm Chronology
.textalgcode....cinitcopy of V table
3. FIR_TI_Alloc() mem for: inst obj,x, a, x_stg
1. On build Alg code
.bss
x[100]
5. FIR_TI_Activate() fill scratch
x
+
6. 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
2. At boot V.table
globals
vtable XY
.bss / stack
.sysmem
4. FIR_TI_InitObj() fill inst.obj & persist
a[100]
x_stg[100]
instanceXY*IALG_Fxns*a*x*x_stg
handleXY
30
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?
Reentrancy & Multiple Instances
31Multiple 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 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]
32TMS320™ 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?
33
Application
Alg
Alg
Alg
Core Run-Time
A/D
D/A
ctrl
status
DSP
Alg
o St
anda
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” managesall hardware resources
Benefits: No hardware contention Portability to other DSPs
Algorithm Standard Coding Rules
34Threads 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.729X
DTMF
G.729Y
DTMF
Thread “B”
35Object-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
36TMS320™ 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
37
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™ DSP Algorithm Standard
38
Compliant algorithms must include: Libraries of the code provided Header files listing the implemented abstract interfaces Documentation defining the algorithm
LIB H DOC
TMS320™ DSP Algorithm Standard
Compliant Algorithm “Package”
39
All algorithms must characterize their:
Memory requirements
Execution time Interrupt latency
Standard basis for comparison and tradeoffs
Algorithm Performance Characterization
40Algorithm Developer Resources
Documents Manuals Application notes
Developer’s Kit Run-time support libraries and all interface headers Example algorithms and applications source code Development tools
Web resource www.ti.com/expressdsp
41TMS320™ DSP Algorithm Standard Overhead
Object and indirection:Limited to a few extra instructions
Code space overhead:Code space can be recovered in static systems
Data space overhead:One word per instance object minimum One function table per algorithm module
42Invent the Future ...
top related