TMS 320 DSP Algorithm Standard Overview Rationalization Agenda

TMS 320 DSP Algorithm Standard: Overview & Rationalization

Agenda u. Overview u. Interactions with e. Xpress. DSP Technologies u. Rationalization and Benefits

TMS 320 DSP Algorithm Standard ease-of-integration Rules & Guidelines ALGORITHM CONSUMERS static alg 1 chan 1 dynamic algn chann Resource Management Framework(s) & uniform naming conventions & register usage requirements & data addressing modes & re-entrant, relocatable code Common Programmatic Interface & memory allocation policies & access to HW peripherals ALGORITHM PRODUCERS write once, deploy widely & minimizing interrupt latency & performance characterization

e. Xpress. DSPTM - Technology Interactions e. Xpress. DSPTM Logical Code Composer Studio get the code to work Different tools to solve Single channel, single algorithm different problems u. Single GUI for develop & debug u. Graphical Data Analysis u. Expandable by 3 P plug-ins DSP Algorithm Standard off-the-shelf software Multi-Channel Temporal u. Static or dynamic u. Memory and DMA management DSP/BIOS II u. Single or multi-channel meet real-time goals Multi-algorithm u. Software scheduling Physical u. Real-time analysis u. Hardware abstraction

Algorithm Standard - Rules & Benefits Consistency/Ease of Integration u. Hands off certain registers u. Access all data as far data u. Little endian format Portability/Flexibility u. DSP/BIOS name conventions u. Re-entrant code u. Code must be re-locatable u. No direct access peripherals Measurability u. Worst case memory usage u. Worst case interrupt latency Usability/Interoperability u. Worst case execution time u. Standardized memory management u. Standardized DMA management

Objective Explain the rationale behind the rules of the e. Xpress. DSP Algorithm Standard and their benefits to customers of compliant algorithms.

Definition TMS 320 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 TI’s implementation of the C programming language Need to avoid having algorithm interefere 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 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 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. u B e n e f i t s Algorithms must avoid name space collisions n Different algorithms may have same name for data types and functions n 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 undefined references must refer to operations from a subset of C runtime support library functions, DSP/BIOS or other e. Xpress. DSP-compliant modules. u Algorithms n 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 algorithms must implement the IALG interface. u Defines B e n e f i t s communication protocol between client and algorithm n Enables client to create, manage and terminate algorithm instances n Run in virtually any system (preemptive and non-preemptive, static and dynamic) n 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 of the IALG methods implemented by an algorithm must be independently relocatable. u Need B e n e f i t s for design/run-time creation of algorithm instances n Ability to relocate algorithm interface methods in memory n Ability to discard unused functions to reduce code size n Optimized use of program memory Flexibility Placement of algorithm components anywhere in memory Support for design/run-time (static/dynamic) integration (SPRA 577, SPRA 580, SPRA 716)

Algorithm Packaging Each compliant algorithm must be packaged in an archive which has a name that follows a uniform naming convention. u Integrate different algorithms without symbol collision n Unique archive names between different/versions of algorithms u Uniformat for delivering algorithms n All algorithm modules built into a single archive u Use of algorithms in different development platforms (UNIX, Win) n 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 compliant algorithms must characterize: • Program/heap/static/stack memory requirements • Worst case interrupt latency • Typical period and worst case execution for each method u Planning n n integration of algorithm A vs. B into system Assess performance metrics and compatibility with system Assess resource requirements and compatibility with system B Measurability e Up-front assessment and n comparison tool e f i t s 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 n Platform independence n Measurability n 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) n Single consistent naming convention n Shorter system integration time n Determine algorithm compatibility with system n No run-time surprises n Consistency Uniform naming conventions n Enhanced code readability n Interoperability Uniform abstract interface n No resource competition n