TMS320 DSP Algorithm Standard: Overview & Rationalization

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