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

ALGORITHMPRODUCERS

ease-of-integrationALGORITHMCONSUMERS

static alg1 chan1 dynamic algn chann

Resource Management Framework(s)

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

eXpressDSPTM

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

Benefits

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 simultaneouslyMulti-channel systems (e.g. servers)

Real-time systems with real-time OSTasks are independent of each other reentrancy must be ensuredmemory or global variables shared by multiple instances must be

protected

Algorithms Must be Re-entrant

Benefits

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

Benefits

PortabilityTransfer algorithms between

systems

FlexibilityPlacement 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 availableSpecific resources will vary from system to systemMultiple algorithms will compete for resourcesPeripherals 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.

Benefits

InteroperabilityFramework manages resources

No resource competition

PortabilityTransfer 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

Benefits

ConsistencyEnhanced code readability

Compliant algorithms intended for

use with DSP/BIOS

Ease of integrationNo 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.

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

Benefits

ConsistencyEnhanced code readability

Compliant algorithms intended for

use with DSP/BIOS

Ease of integrationDSP/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. All algorithms must implement the IALG interface.

Benefits

Interoperability/ConsistencyUniform abstract interface

Ease of integrationUniform abstract interface

Learn once apply many

Shorter system integration timeFlexibility

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.Each of the IALG methods implemented by an algorithm must be independently relocatable.

Benefits

FlexibilityPlacement 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.Each compliant algorithm must be packaged in an archive which has a name that follows a uniform naming convention.

Algorithm Packaging

Benefits

ConsistencyUniform naming convention

Ease of integrationSingle 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

FlexibilitySupport different development

systems

Performance and Requirements Metrics

Benefits

MeasurabilityUp-front assessment and

comparison tool

Ease of integrationDetermine 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