eXpressDSP Modular Application Software Solutions for TMS320 DSPs

eXpressDSP Modular Application Software Solutions for TMS320 DSPs

eXpressDSP Modular Application Software Solutions for TMS320 DSPs The DSP Software Challenge hardware capability application complexity TIME-TO-MARKET PRESSURE just ship it !! increased cost/risk insufficient re-use HW % SW t software the critical factor Elevating The Platform EDN Innovation of the Year integrated development tools real-time software foundation standards for interoperability network of third-party partners Code Composer Studio plug-in program build target program

application frameworks plug-in program debug real-time analysis RTDX host computer alg alg alg alg alg alg DSP/BIOS TMS320 DSP TMS320 DSP Algorithm Standard comm

drivers Grow Your Own ... application application application alg alg alg alg alg alg application I/O comm scheduler scheduler application alg alg scheduler I/Oalg DSP

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 + ... 00101 DSP too costly to develop GPP ... Or Leverage Others application application blueprints blueprints more time to innovate less time to integrate

ability to differentiate off-the-shelf off-the-shelf algorithms algorithms DSP/BIOS DSP/BIOS real-time real-timekernel kernel eXpressDSP eXpressDSP infrastructure infrastructure CUSTOMER VALUE-WEB FOUNDATION BACKPLANE some programming required Modular Application Software Solutions TMS320 Software Foundation target programs DSP/BIOS Kernel Interface scalable

extensible library of essential application services manages threads, memory, I/O, timers, ... support for C5000, C6000, C2000 families DSP/BIOS Kernel Modules consumes minimal MIPS & memory integrated real-time analysis tools C5000 C6000 C2000 royalty-free with every TMS320 DSP robust, field-tested, industry-proven TMS320 DSP Platform used in 1000s of active DSP designs Programming With DSP/BIOS Code Composer Studio program sources CONFIGURATION kernel APIs kernel modules

C- and ASM-callable functions interactive configuration tool kernel-aware debug support on-the-fly program analysis BUILD executable image target application program VISUALIZATION DSP/BIOS Kernel Interface DEBUG EMULATION HOST DEVELOPMENT COMPUTER RTDX JTAG

real-time capture multiple threads hardware abstraction TARGET TMS320 DSP HARDWARE Mass-Market Algorithms 900 600 catalog of standard, compliant algorithms voice, telephony, video, imaging, audio, ... multiple suppliers over 50 third-parties 300 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 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 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 innovate and differentiate join the 1000s of active DSP customers already using CUSTOMER VALUE-WEB FOUNDATION BACKPLANE Lets Get Started visit http: //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 Developers Kit eXpressDSPTM Software Technology Seminar TMS320TM DSP Algorithm Standard (XDAIS) Introduction eXpressDSP Memory Types Algorithms in Applications Memory Setup Sequence Non-standard Algorithms Abstract Interface

Connecting Vendors & Users Instance Objects Benefits of the Standard Algorithm Coding Rules Requirements of a Standard 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 development

tools DSP/BIOS Real-time software foundation TMS320 DSP Algorithm Standard TI DSP Third-Party Network Standards for application interoperability and reuse Software and support Elements of eXpressDSPTM Host Tools Target Content Program Build Program Debug Data Visualization Host APIs Plug-in Tools Your Application Analysis

ADC Config - IDE Real-Time Analysis Host Computer TMS320TM DSP Algorithm Standard RTDX JTAG DSP/BIOS TMS320TM DSP 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 Application Alg Alg Alg Alg Alg TMS320 DSP TI Enhances Vendor / User Process ALGORITHM PRODUCERS Algorithm

write once, deploy widely TEXAS INSTRUMENTS TMS320TM DSP Algorithm Standard Specification Rules & Guidelines Programming rules Algorithm packaging Algorithm performance DSP platform C5000 C6000 SYSTEM INTEGRATORS Application ease of integration 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 Requirements of a Successful Standard

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: TIs Configuration Performance modeling Algorithm Standard conformance Interface Debugging Specification

XDAIS eXpressDSP meets all these requirements Incur little or no overhead Quantify the algorithms: memory, latency, speed TMS320 DSP Algorithm Standard TM Introduction Algorithm Memory Types Memory Types Scratch vs. Persistent

Memory Setup Sequence Controlling Memory Sharing Abstract Interface Static Shared Memory Instance Objects Algorithm Coding Rules What kinds of memory can algorithms specify? How do I minimize memory usage? Conclusions

What system options do I have? Types of Memory Needed by Algorithms Stack Managed by Application Framework Local variables; managed by algorithm 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 Space Inefficient Memory Allocation Algorithm A Algorithm B Physical Memory Scratch B Persistent B Scratch B

Persistent B Scratch A Persistent A Scratch A Persistent A May be OK for speed optimized systems, but may pose problems for systems where minimum memory usage is desired... Scratch Allows for Minimized Memory Size Algorithm A Scratch Algorithm B Scratch Algorithm C Scratch Physical Memory Scratch Usually a: Limited Resource eg: Internal RAM Persistent A

Persistent B Persistent C Persistent A Persistent B Often an: Extensive Resource eg: External RAM Persistent C Examples of Scratch RAM Management... Scratch RAM 1 A A B C Scratch RAM Scratch RAM 2 B C D E 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 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. 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 TSK_disable SWI_disable TSK_enable SWI_enable Task Semaphores (lock, unlock)

SEM_pend SEM_post Raise priority SWI_raisepri TSK_setpri SWI_restorepri TSK_setpri 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 Static Read-only Data Static global data Instance Instance Example: 2 FIR filters with identical - fixed - coefficient tables 0 n Instance heap data TMS320 DSP Algorithm Standard TM

Introduction Memory Setup Model Memory Types Memory Setup Sequence Memory Setup Sequence IALG Options Abstract Interface IALG Interface Instance Objects

What are the steps to setting up the memories needed? Algorithm Coding Rules Conclusions What optional controls are available? How do we optimize for static and dynamic systems? Memory Setup Model 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

Size Size Alignment Alignment Type Type Scr/Persist Scr/Persist Address Address Size Size Alignment Alignment Type Type Scr/Persist Scr/Persist Address Address Size Size Alignment Alignment ...... 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: 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. 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 algDeactivate() IALG Object Creation Sequence Diagram Call algNumAlloc() to get # of memory reqs

free() Call algActivate() to prep instance for use Call algorithm processing methods Initialize instance object Initialize scratch memory Process data, return result Call algDeactivate() to prep for mem re-use Save state to persistent memory Call algFree() to retrieve buffer pointers Return all buffers and sizes Algorithm Instance Call algInitObj() to initialize instance object Algorithm Module malloc() Application Framework Call algAlloc() to get memory requests IALG Sequencing & Options Static Systems: Setup memory at build-time

At run-time: Process only algNumAlloc() algAlloc() algInitObj() algActivate() algMoved() PROCESS algFree() algDeactivate() 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 TMS320 DSP Algorithm Standard TM Introduction IALG Abstract Interface Memory Types Module Interface Memory Setup Sequence Interface Options Abstract Interface

Naming Rules Instance Objects How do I access IALG functions? How do I access algorithm functions? Is there a naming style I can rely upon? Algorithm Coding Rules Conclusions 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. Algorithm Module Interface IALG_Fxns Void

Int Int Int Int Int Void Int algActivate(IALG_Handle); algAlloc(const IALG_Params *,); algControl(IALG_Handle, ); algDeactivate(IALG_Handle); algFree(IALG_Handle, ); algInit(IALG_Handle, ); algMoved(IALG_Handle, ); algNumAlloc(); Void Void Void decode(IG729_Handle, IG729_Frm ); encode(IG729_Handle, Int16 *in,); 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 - 34

Interface Options Application Standard Module Vendor Algorithm Standard Interface: Module Interface: Vendor Interface: Abstract Template Required for compliance Optional Method Defined by TI Defined by Vendor Defined by Vendor IALG table only IALG + Alg Fxns eg: shortcuts 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 TMS320 DSP Algorithm Standard TM Introduction The Instance Object Memory Types App to Alg Control Flow

Memory Setup Sequence Re-entrancy Abstract Interface Multiple Instances Instance Objects Algorithm Coding Rules 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? Conclusions Application to Algorithm Control Interface .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 .bss .text globals num vtable XY

alloc X_Y_num X_Y_alloc run X_Y_init X_Y_run module interface .cinit copy of V table algorithm code Application to Algorithm Chronology .bss / stack handleXY .sysmem instanceXY *IALG_Fxns *a *x *x_stg 1. On build 2. At boot

3. FIR_TI_Alloc() Alg code V.table mem for: inst obj, x, a, x_stg 4. FIR_TI_InitObj() fill inst.obj & persist .bss .text globals alg code vtable XY ... .cinit copy of V table a[100] x[100] x x_stg[100] + 5. FIR_TI_Activate() 6. FIR_TI_Run() 7. FIR_TI_Deactiv()

8. FIR_TI_Free fill scratch process FIR filter x[100] to x_stg, reclaim x reclaim inst.obj,x_stg, a Re-entrancy & Multiple Instances Hi Priority Process Process Process SWI A SWI B IDLE Low Priority During Duringthis thistime, time,both bothAAand andBB are arerunning runningthe thesame samefunction. function. How Howdo

dowe weavoid avoidhaving havingAs As context contextoverwrite overwriteBs? Bs? 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 Multiple Instances of an Algorithm .bss/stack .bss handleXY1 globals handleXY2 instanceXY1 *IALG_Fxns vtable XY a[100] *a *x x[100]

*x_stg x_stg[100] instanceXY2 *IALG_Fxns x[100] *a x_stg[100] *x *x_stg .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 TMS320 DSP Algorithm Standard TM

Introduction Coding Rules Memory Types Threads vs Algorithms Memory Setup Sequence Object Based Programming Abstract Interface Instance Objects 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? Algorithm Coding Rules Conclusions Algorithm Standard Coding Rules A/D D/A ctrl status Algo Standard DSP Application Core Run-time

Alg Alg Alg 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 Threads vs Algorithms A thread may call multiple algorithm instances Algorithms are not, and may not uses threads Algorithms are data transducers not schedulers Thread A G.168 Compliant algorithms are pure data transducers with state: not threads black box components - accessed by v.table extensible via vendor interface option Thread B G.729 X G.729 Y DTMF DTMF Allows for unique methods and creation parameters Users may directly access these features but lose interchangeability 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 DSP Algorithm Standard TM Introduction Value of the Standard Memory Types Algorithm Package Memory Setup Sequence

Algorithm Documentation Abstract Interface Developer Resources Instance Objects System Overhead Algorithm Coding Rules Conclusions Value of the TMS320TM DSP 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 off-the-shelf DSP content

Faster, easier algorithm integration Quantify the algorithms: memory, latency, speed Be easy to adhere to Incur little or no overhead 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

Algorithm Performance Characterization All algorithms must characterize their: Memory requirements Execution time Interrupt latency Standard basis for comparison and tradeoffs 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 Algorithm Standard: Overview & Rationalization Agenda Overview Interactions with eXpressDSP Technologies Rationalization and Benefits

TMS320 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 eXpressDSPTM - Technology Interactions Logical eXpressDSP TM Different tools to solve different problems 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 Algorithm Standard off-the-shelf software Multi-Channel Static or dynamic

Temporal Memory and DMA management Single or multi-channel DSP/BIOS II meet real-time goals Multi-algorithm Software scheduling Physical Real-time analysis Hardware abstraction Algorithm Standard - Rules & Benefits Consistency/Ease of Integration Hands off certain registers Access all data as far data Little endian format Portability/Flexibility Re-entrant code DSP/BIOS name conventions Code must be re-locatable No direct access peripherals Measurability Worst case memory usage Worst case interrupt latency Worst case execution time Usability/Interoperability Standardized memory management

Standardized DMA management 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. Respect C Run-time Conventions 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 B e n e f i t s Ease of Integration Binding algorithms to application Control flow of data between algorithms

No run-time surprises Algorithms Must be Re-entrant 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 B e n e f i t s Flexibility Optimized program memory usage (e.g. multiple channels will be running same code) Maintains integrity of algorithm instance data Data & Code Relocatability All algorithms data (code) references must be fully relocatable. There must be no hard coded data (program) memory locations. Ability to run algorithm components from any type of memory Optimized use of memory resources Allows any number of instances without data collisions B e n e f

i t s 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 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. 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 B e n e f i t s Interoperability Framework manages resources No resource competition Portability Transfer s/w between systems

Platform independence Symbol Naming Conventions All All external external definitions definitions must must be be either either API API references references or or API API and and vendor vendor prefixed. prefixed. All All modules modules must must follow follow the the naming naming conventions conventions of of the the DSP/ DSP/ BIOS BIOS for for those those external external declarations declarations exposed exposed to

to the the client. client. B e n e f i t s Algorithms must avoid name space collisions Different algorithms may have same name for data types and functions Application cannot resolve multiply-defined symbols 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 Module External References All All undefined undefined references references must must refer refer to to operations operations from

from aa subset subset of of C C runtime runtime support support library library functions, functions, DSP/BIOS DSP/BIOS or or other other eXpressDSP-compliant eXpressDSP-compliant modules. modules. Algorithms B e n e f i t s are as compliant as the modules they invoke Algorithm must not reference non-compliant modules 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 All All algorithms algorithms must must implement implement the the IALG IALG interface. interface. Defines B e n e f i t s 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 Interoperability/Consistency Uniform abstract interface Flexibility Running algorithms in virtually any execution environment Ease of integration Uniform abstract interface Learn once apply many Shorter system integration time Abstract Interface Implementation Each Each of of the the IALG IALG methods methods implemented implemented by by an an algorithm algorithm must must be be independently independently relocatable. relocatable. Need B e

n e f i t s 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 Flexibility Placement of algorithm components anywhere in memory Support for design/run-time (static/dynamic) integration (SPRA577, SPRA580, SPRA716) Algorithm Packaging Each Each compliant compliant algorithm algorithm must must be be packaged packaged in in an an archive

archive which which has has aa name name that that follows follows aa uniform uniform naming naming convention. convention. 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 B e n e f i t s Consistency Uniform naming convention Flexibility Support different development systems Ease of integration Single consistent naming convention Unique archive names (no symbol collision)

Shorter system integration time Performance and Requirements Metrics All All compliant compliant algorithms algorithms must must characterize: characterize: Program/heap/static/stack Program/heap/static/stack memory memory requirements requirements Worst Worst case case interrupt interrupt latency latency Typical Typical period period and and worst worst case case execution execution for for each each method method Planning B e n e

f i t s integration of algorithm A vs. B into system Assess performance metrics and compatibility with system Assess resource requirements and compatibility with system 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.) Summary of Key Benefits Portability Transfer s/w between systems Platform independence Measurability Up-front assessment and comparison tool for planning algorithm A vs. B Flexibility Algorithm components anywhere in memory

Algorithms run in virtually any execution environment Design/run-time integration Different development systems Multi-channel 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 Consistency Uniform naming conventions Enhanced code readability Interoperability Uniform abstract interface No resource competition 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 \XDAIS\spra580b.pdf Using the TMS320 DSP Algorithm Standard in a Dynamic DSP System The TMS320 DSP Algorithm Standard Achieving Zero Overhead With the TMS320 DSP Algorithm Standard IALG Interface

\XDAIS\spra581b.pdf \XDAIS\spra716.pdf \XDAIS\spra732.pdf Real-Time Analysis in an eXpressDSP-Compliant Algorithm 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 Developers Guide \XDAIS\spru424.pdf TMS320 DSP Algorithm Standard \XDAIS\spru427.pdf

Recently Viewed Presentations

  • Chapter 13: Schooling and Development in Middle Childhood

    Chapter 13: Schooling and Development in Middle Childhood

    Semantic and syntactic knowledge. Meaning Making: searching the long term memory for the meaning of a word. Context affects meaning—we gather information from the surrounding words to determine the meaning of the unknown word. We do this by using both...
  • Respect et autorité - WordPress.com

    Respect et autorité - WordPress.com

    Le respect de soi (suite) Relation entre respect de soi et respect d'autrui pour soi : pour me traiter comme une personne, il faut que les autres me traitent comme une personne - notion de réciprocité et de réassurance en...
  • Clinical Diagnostic Laboratory 1

    Clinical Diagnostic Laboratory 1

    Ignoring clinical data, theoretical knowledge and practical experience could lead to false conclusions or even to a false diagnosis. Blood is a dynamic system with no clear cut borderline between physiological and . pathological. Be wise making a diagnosis. The...
  • Presentazione gruppo 5: Didattica della Matematica Soddu Marta

    Presentazione gruppo 5: Didattica della Matematica Soddu Marta

    Attività 2.2: conteggio con il numero 5 Batti 5: I bambini conteranno in sequenza, usando le loro mani, solo 5 e i suoi multipli fino a 100 Attività 2.3: conteggio con il numero 5 5 Subitising: I bambini saranno chiamati...
  • Boys and Girls Learn Differently! Boys & Girls

    Boys and Girls Learn Differently! Boys & Girls

    Most likely you will not have time on the initial day of training. This slide can be used at a later date). * A good brain break at this point is "Tony Chestnut." You will need to link the sound...
  • TABS: TABS: Headings listed at the top of

    TABS: TABS: Headings listed at the top of

    WORK ITEM: Is a group of one or many tasks that help track what work needs to be completed for a CCMS activity.They track the work flow of an organization. Work items will be reviewed in more detail later. TASKS:...
  • Enabling community pharmacy evolution About Us Established in

    Enabling community pharmacy evolution About Us Established in

    About Us. Established in 1898, the CCA is the trade association for large pharmacy operators in England, Scotland and Wales. Our membership includes ASDA, Boots, LloydsPharmacy, Morrisons, Rowlands Pharmacy, Superdrug, Tesco and Well, who between them own and operate around...
  • "Othello" - White Plains Middle School

    "Othello" - White Plains Middle School

    But he is an outsider because he is from another country—and of another race. When Othello secretly marries the young, beautiful and noble Desdemona, her father, Brabantio, wants Othello to be arrested. But Desdemona loves Othello and doesn't care that...