eXpressDSP

1. eXpressDSP Modular Application Software Solutions for TMS320 DSPs 08.22.01

2. 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

3. Elevating The Platform EDN Innovation of the Year Code Composer Studio™  alg alg alg plug-in plug-in alg alg alg RTDX™ comm DSP/BIOS™ drivers eXpressDSP • integrated development tools • real-time software foundation • standards for interoperability • network of third-party partners target program application frameworks TMS320 DSP Algorithm Standard program build program debug real-time analysis host computer TMS320 DSP

4. Grow Your Own ... application application scheduler application application application alg alg alg alg alg alg scheduler I/O comm alg alg application scheduler I/O alg 00101 DSP GPP • too costly to develop • too costly to enhance • too costly to maintain • alg • app + alg • app + algA + algB + ... • app + sched + algAn + algBn + ... • app + sched + I/O + algAn + algBn + ... • app + sched + I/O + comm + algAn + algBn + ... alg DSP

5. ... Or Leverage Others application blueprints off-the-shelf algorithms DSP/BIOS™ real-time kernel Modular Application Software Solutions CUSTOMER eXpressDSP™ infrastructure VALUE-WEB FOUNDATION § BACKPLANE §some programming required • more time to innovate • less time to integrate • ability to differentiate

6. TMS320 Software Foundation target programs DSP/BIOS Kernel Interface scalable extensible DSP/BIOS Kernel Modules C5000 C6000 C2000 TMS320 DSP Platform • 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

7. Programming With DSP/BIOS Code Composer Studio  program sources CONFIGURATION kernel APIs kernel modules BUILD executable image VISUALIZATION   DEBUG multiple threads hardware abstraction RTDX EMULATION JTAG HOST DEVELOPMENT COMPUTER • C- and ASM-callable functions • interactive configuration tool • kernel-aware debug support • on-the-fly program analysis target application program DSP/BIOS Kernel Interface real-time capture TARGET TMS320 DSP HARDWARE

8. Mass-Market Algorithms 900 600 300 • 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

9. DSP Algorithm Standard ease-of-integration Rules & Guidelines ALGORITHM CONSUMERS static  alg1 chan1 dynamic  algn chann Resource Management Framework(s) Common Programmatic Interface ALGORITHM PRODUCERS write once, deploy widely • 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

10. Points To Remember innovate and differentiate — join the 1000s of active DSP customers already using CUSTOMER eXpressDSP VALUE-WEB FOUNDATION BACKPLANE 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

11. Let’s Get Started visithttp: //dspvillage.ti.com • app notes, bulletins, FAQs, discussion groups, ... • register at TI&ME for personalized content get first-hand experience with DSP/BIOS • enroll in our hands-on, one-day training course • prototype your application using our DSP Starter Kit explore the world of compliant DSP algorithms • query our on-line database of third-party products • download the Algorithm Standard Developer’s Kit

12. eXpressDSPTM Software Technology Seminar

13. TMS320TM DSP Algorithm Standard (XDAIS) • Introduction • Memory Types • Memory Setup Sequence • Abstract Interface • Instance Objects • Algorithm Coding Rules • Conclusions • eXpressDSP • Algorithms in Applications • Non-standard Algorithms • Connecting Vendors & Users • Benefits of the Standard • Requirements of a Standard • What is the benefit of the standard? • What makes a good standard?

14. eXpressDSPTM: The DSP Software Solution Set Code Composer StudioTMIDEPowerful,integrated developmenttools DSP/BIOSReal-time software foundation TMS320™ DSP Algorithm StandardStandards for application interoperability and reuse TI DSPThird-Party NetworkSoftwareand support

15. Elements of eXpressDSPTM Real-Time Analysis RTDX DSP/BIOS Host Tools Target Content Your Application • Program Build • Program Debug • Data Visualization • Host APIs • Plug-in Tools • Analysis • ADC Config TMS320TM DSPAlgorithm Standard - IDE - JTAG Host Computer TMS320TM DSP

16. 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 Application Alg Alg Alg Alg Alg TMS320 DSP

17. TI Enhances Vendor / User Process TEXASINSTRUMENTS TMS320TM DSP Algorithm Standard Specification Rules & Guidelines • Programming rules • Algorithm packaging • Algorithm performance • DSP platform • C5000 • C6000 ALGORITHM PRODUCERS SYSTEMINTEGRATORS Algorithm Application write once, deploy widely ease of integration

18. Benefits of the TI DSP Algorithm Standard • 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 • 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

19. Requirements of a Successful Standard TI’s eXpressDSP AlgorithmInterface Specification meets all these requirements XDAIS For a DSP Algorithm Standard to be successful, it must: • 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

20. 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?

21. Types of Memory Needed by Algorithms • 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 Managed by Application “Framework” • Stack • Local variables; managed by algorithm

22. Space Inefficient Memory Allocation Algorithm A Persistent A Scratch A Algorithm B Scratch B Persistent B Physical Scratch B Persistent B Scratch A Persistent A Memory May be OK for speed optimized systems, but may pose problems for systems where minimum memory usage is desired...

23. Scratch Allows for Minimized Memory Size Algorithm A Scratch Persistent A Algorithm B Scratch Persistent B Algorithm C Scratch Persistent C Physical Scratch Persistent A Persistent B Persistent C Memory Usually a: Limited Resourceeg: Internal RAM Often an: Extensive Resourceeg: External RAM

24. Examples of Scratch RAM Management... Scratch RAM Scratch RAM 1 Scratch RAM 2 A B C D E A D B F E C A-E have enough space to all run in parallel. F needs all the scratch, soA-E are all Deactivated tomake room for F A, B, and C are sequential to each other. D & E are parallel to A,B, or C,but sequential to each other Scratch management is entirely at the discretion of the application. The algorithm is not perturbed by the implementation choices selected.

25. Shared Scratch Memory Synchronization Inhibit preemption when running code that accesses shared memory Assign concurrent processes to the same priority = automatic FIFOotherwise, 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

26. 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 Static Read-only Data Static global data … Instance Instance 0 n Instance heap data

27. TMS320TM DSP Algorithm Standard • Memory Setup Model • Memory Setup Sequence • IALG Options • IALG Interface • 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?

28. Memory Setup Model Size Algorithm Knows memory requirements Requests appropriate resources from Application Alignment Type Scr/Persist Address Application “Framework” Manages memory requirements Determines what memories are available to which algorithms - and when Size Alignment Type Scr/Persist Physical Memory Types: External (slow, plentiful, lower cost) Internal (fast, limited, higher cost) SARAM, DARAM Address Size Alignment ...

29. Algorithm Memory Interrogation Sequence • 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

30. IALG Object Creation Sequence Diagram Call algNumAlloc() to get # of memory reqs Call algAlloc() to get memory requests malloc() Initialize instance object Call algInitObj() to initialize instance object Call algActivate() to prep instance for use Initialize scratch memory Application “Framework” Algorithm Module Call algorithm processing methods Process data, return result Algorithm Instance Algorithm Instance Call algDeactivate() to prep for mem re-use Save state to persistent memory Call algFree() to retrieve buffer pointers Return all buffers and sizes free()

31. IALG Sequencing & Options Static Systems: • Setup memory at build-time • At run-time: “Process” only algNumAlloc() algAlloc() algInitObj() algActivate() algMoved() PROCESS algDeactivate() algFree() Dynamic Systems: • Run Once: Activate, Process, De-activate • Run Many: Activate, Process, Process, … , De-activate • Run Always: Activate, Process, Process, … • Change Resources: “algMoved()” Optional Functions Required Functions

32. 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?

33. IALG Interface 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 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.

34. Algorithm “Module” Interface 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 … IALG_Fxns IG729_Fxns • 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 accessthe algorithms themselves • Abstract interfaces define a “v-table” for accessing the module’s functions • Abstract interfaces define module functions as a structure of pointers - 34

35. Interface Options 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”

36. Naming Rules 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

37. 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?

38. Application to Algorithm Control Interface .bss globals vtable “XY” X_Y_num X_Y_alloc X_Y_init … X_Y_run … .bss / stack handleXY .sysmem instanceXY *IALG_Fxns *a *x len ... .text num … alloc … run … .cinit copy of V table Instance Object: table of pointers to data structures 1: ptr. to v.table 2-N: alg data arrays and variables module interface algorithm code

39. Application to Algorithm Chronology .bss / stack handleXY .sysmem instanceXY *IALG_Fxns *a *x *x_stg .text alg code ... .cinit copy of V table .bss globals vtable XY a[100] x[100] x_stg[100] x+ 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

40. Re-entrancy & Multiple Instances Process Process Process Hi Priority SWI A SWI B During this time, both A and B are running the same function. How do we avoid having A’s context overwrite B’s? IDLE Low Priority 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”

41. Multiple Instances of an Algorithm .bss/stack handleXY1 handleXY2 instanceXY1 *IALG_Fxns *a *x *x_stg instanceXY2 *IALG_Fxns *a *x *x_stg .bss globals vtable XY a[100] .text alg code .cinit copy of V table 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 x[100] x_stg[100] x[100] x_stg[100]

42. 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?

43. Algorithm Standard Coding Rules • 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 DSP A/D Alg D/A Alg Algo Standard ctrl Alg status Application Core Run-time

44. 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 Thread “B” Thread “A” G.729X G.729Y G.168 DTMF DTMF

45. 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

46. 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

47. Value of the TMS320TMDSP Algorithm Standard • 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

48. Compliant Algorithm “Package” Compliant Algorithms must include: • Libraries of the code provided • Header files listing the implemented abstract interfaces • Documentation defining the algorithm TMS320TM DSP Algorithm Standard LIB H DOC

49. Algorithm Performance Characterization All algorithms must characterize their: Memory requirements Execution time Interrupt latency Standard basis for comparison and tradeoffs

50. 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