Presentation on theme: "eXpressDSP Modular Application Software Solutions for TMS320 DSPs."— Presentation transcript:
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 target program application frameworks Code Composer Studio program build program debug real-time analysis plug-in TMS320 DSP Algorithm Standard EDN Innovation of the Year
00101 alg 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 application alg scheduler application alg scheduler I/O application 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 extensiblescalable DSP/BIOS Kernel Modules TMS320 Software Foundation C5000 C6000 target programs DSP/BIOS Kernel Interface C library of essential application services 4 manages threads, memory, I/O, timers,... 4 support for C5000, C6000, C2000 families 4 consumes minimal MIPS & memory 4 integrated real-time analysis tools 4 royalty-free with every TMS320 DSP 4 robust, field-tested, industry-proven 4 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 CONFIGURATIONVISUALIZATION 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 catalog of standard, compliant algorithms 4 voice, telephony, video, imaging, audio,... 4 multiple suppliers over 50 third-parties 4 follow uniform set of rules and guidelines 4 simplifies benchmarking of alternatives 4 support for C5000, C6000, C2000 families 4 deployable in static or dynamic systems 4 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 ALGORITHM PRODUCERS ease-of-integration ALGORITHM CONSUMERS static alg 1 chan 1 dynamic alg n chan n Resource Management Framework(s)
Points To Remember dont 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
Lets Get Started get first-hand experience with DSP/BIOS 4 enroll in our hands-on, one-day training course 4 prototype your application using our DSP Starter Kit visit http: //dspvillage.ti.com 4 app notes, bulletins, FAQs, discussion groups,... 4 register at TI&ME for personalized content explore the world of compliant DSP algorithms 4 query our on-line database of third-party products 4 download the Algorithm Standard Developers 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 interoperability 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 its difficult to integrate real-time algorithms from more than single source because of a lack of standards. Integration times are extended Debugging is tricky (whats that black box doing ?) Its difficult or impossible to compare similar algorithms Its difficult or impossible to rapidly prototype a system 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 algorithms: memory, latency, speed For a DSP Algorithm Standard to be successful, it must: Requirements of a Successful Standard TIs eXpressDSP Algorithm Interface Specification meets all these requirements XDAIS
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 Managed by Application Framework 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 BScratch APersistent 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 CScratch Algorithm C Scratch Physical Memory Persistent B Persistent A Persistent BPersistent C Usually a: Limited Resource eg: Internal RAM Often an: Extensive Resource eg: External RAM
Scratch RAM 1Scratch 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 ABCDE 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 interruptsHWI_disableHWI_enable Disable schedulerSWI_disableSWI_enable TSK_disableTSK_enable Task Semaphores (lock, unlock)SEM_pend SEM_post Raise prioritySWI_raisepriSWI_restorepri TSK_setpriTSK_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 MemoryTypes: External (slow, plentiful, lower cost) Internal (fast, limited, higher cost) SARAM, DARAM Size Alignment Type Scr/Persist Address Size Alignment Type Scr/Persist Address Size Alignment... 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: Heres 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 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: de-allocate any desired scratch memories for use by other components Algorithm Memory Interrogation Sequence
Algorithm Instance Application FrameworkAlgorithm Module Call algNumAlloc() to get # of memory reqs Call algAlloc() to get memory requests Algorithm Instance Call algActivate() to prep instance for use Call algDeactivate() to prep for mem re-use Initialize scratch memory Call algorithm processing methodsProcess data, return result Save state to persistent memory Call algInitObj() to initialize instance object Initialize instance object Call algFree() to retrieve buffer pointersReturn 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
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); IntalgAlloc(const IALG_Params *,…); IntalgControl(IALG_Handle, …); IntalgDeactivate(IALG_Handle); IntalgFree(IALG_Handle, …); IntalgInit(IALG_Handle, …); VoidalgMoved(IALG_Handle, …); IntalgNumAlloc(); Voiddecode(IG729_Handle, IG729_Frm …); Voidencode(IG729_Handle, Int16 *in,…); Void… 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 access the algorithms themselves Abstract interfaces define a v-table for accessing the modules functions Abstract interfaces define module functions as a structure of pointers Algorithm Module Interface
Application StandardModuleVendor 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.a6262xx target MOD_VEN.a62e62xx target - big endian MOD_VEN.a54f 54x target - far call/rtn version MOD_VEN.a54n54x 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 interfacealgorithm 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 buildAlg code 2. At bootV.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 to x_stg, reclaim x 8. FIR_TI_Freereclaim inst.obj,x_stg, a x+x+.bss globals vtable XY a x x_stg
SWI A IDLE Hi Priority Low Priority 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 As context overwrite Bs? 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 x x_stg
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 Core Run-time A/D D/A ctrl status DSP Algo Standard 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 modules 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 algorithms: 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 LIBHDOC 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
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 TIs 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 BenefitsBenefits 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 BenefitsBenefits 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 BenefitsBenefits 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. BenefitsBenefits 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 BenefitsBenefits 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. Module External References Algorithms are as compliant as the modules they invoke Algorithm must not reference non-compliant modules BenefitsBenefits 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. BenefitsBenefits Interoperability/Consistency 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. BenefitsBenefits 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. Algorithm Packaging BenefitsBenefits 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 BenefitsBenefits 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 \XDAIS\spra094.pdf\XDAIS\spra094.pdf Reference Frameworks for eXpressDSP Software: API Reference \XDAIS\spra147.pdf \XDAIS\spra147.pdf Using the TMS320 DSP Algorithm Standard in a Static DSP System \XDAIS\spra577b.pdf \XDAIS\spra577b.pdf Making DSP Algorithms Compliant with the TMS320 DSP Algorithm Standard \XDAIS\spra579b.pdf \XDAIS\spra579b.pdf Using the TMS320 DSP Algorithm Standard in a Dynamic DSP System \XDAIS\spra580b.pdf \XDAIS\spra580b.pdf The TMS320 DSP Algorithm Standard \XDAIS\spra581b.pdf \XDAIS\spra581b.pdf Achieving Zero Overhead With the TMS320 DSP Algorithm Standard IALG Interface \XDAIS\spra716.pdf \XDAIS\spra716.pdf Real-Time Analysis in an eXpressDSP-Compliant Algorithm \XDAIS\spra732.pdf \XDAIS\spra732.pdf Reference Frameworks for eXpressDSP Software: RF1, A Compact Static System \XDAIS\spra791b.pdf \XDAIS\spra791b.pdf
Further Reading on XDAIS Reference Frameworks for eXpressDSP Software: RF3, A Flexible, Multi-Channel, Multi-Algorithm, Static System \XDAIS\spra793b.pdf \XDAIS\spra793b.pdf TMS320 DSP Algorithm Standard Rules and Guidelines \XDAIS\spru352d.pdf \XDAIS\spru352d.pdf TMS320 DSP Algorithm Standard API Reference \XDAIS\spru360b.pdf \XDAIS\spru360b.pdf TMS320 DSP Algorithm Standard Demonstration Application \XDAIS\spru361d.pdf \XDAIS\spru361d.pdf TMS320 DSP Algorithm Standard Developers Guide \XDAIS\spru424.pdf \XDAIS\spru424.pdf TMS320 DSP Algorithm Standard \XDAIS\spru427.pdf \XDAIS\spru427.pdf