eXpressDSPModular Application Software Solutions

for TMS320 DSPs

The DSP Software Challenge

application complexity

software — the critical factor

hardware capability

just ship it !!

TIME-TO-MARKETPRESSURE

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 alg

alg alg

alg

alg

target programapplication frameworksCode Composer Studio™

programbuild

programdebug

real-timeanalysis

plug-in plug-in TMS320 DSPAlgorithmStandard

EDN Innovation of the Year

00101

alg

DSP DSP GPP

Grow Your Own ...

app + sched + I/O + comm + algAn + algBn + ...

app + sched + I/O + algAn + algBn + ...

app + sched + algAn + algBn + ...

app + algA + algB + ...

app + alg

alg

too costly to develop

too costly to enhance

too costly to maintain

application

alg

alg alg

application

algalg

scheduler

application

algalg

scheduler

I/O

application

algalg

application

I/O

scheduler

comm

application

BACKPLANE

FOUNDATION

VALUE-WEB

... Or Leverage Others

CUSTOMER

applicationblueprints

applicationblueprints

off-the-shelfalgorithms

off-the-shelfalgorithms

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

ModularApplicationSoftwareSolutions§

TMS320 DSP Platform

extensiblescalable

DSP/BIOS Kernel Modules

TMS320 Software Foundation

C5000C5000 C6000C6000

target programs

DSP/BIOS Kernel Interface

C2000C2000

library of essential application services

manages threads, memory, I/O, timers, ...

support for C5000, C6000, C2000 families

consumes minimal MIPS & memory

integrated real-time analysis tools

royalty-free with every TMS320 DSP

robust, field-tested, industry-proven

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 programexecutableimage

DEBUG

JTAGEMULATION

RTDX

kernel modules

CONFIGURATION

VISUALIZATION

C- and ASM-callable functions

interactive configuration tool

kernel-aware debug support

on-the-fly program analysis

real-timecapture

BUILD

programsources kernel APIs

multiplethreads

hardwareabstraction

Mass-Market Algorithms

600

300

900

catalog of standard, compliant algorithms

voice, telephony, video, imaging, audio, ...

multiple suppliers — over 50 third-parties

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

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)

Points To Remember

don’t 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

Let’s Get Started

get first-hand experience with DSP/BIOS

enroll in our hands-on, one-day training course

prototype your application using our DSP Starter Kit

visit http: //dspvillage.ti.com

app notes, bulletins, FAQs, discussion groups, ...

register at TI&ME for personalized content

explore the world of compliant DSP algorithms query our on-line database of third-party products

download the Algorithm Standard Developer’s Kit

eXpressDSPTM Software Technology

Seminar

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

eXpressDSPTM: The DSP Software Solution Set

Code Composer StudioTM IDE Powerful,integrated developmenttools

DSP/BIOSReal-time software foundation

TI DSPThird-Party NetworkSoftwareand support

TMS320™ DSP Algorithm StandardStandards for application interoperability and reuse

- IDE -

Elements of eXpressDSPTM

Host Tools Target Content

TMS320TM DSP

• Program Build• Program Debug• Data Visualization• Host APIs

Your Application

• Plug-in Tools• Analysis• ADC Config

Host Computer

DSP/BIOSRTDX Real-Time Analysis

TMS320TM DSPAlgorithm Standard

JTAG

Problems with Non-Standardized Algorithms

Today it’s difficult to integrate real-time algorithms from more than single source because of a lack of standards.

• Integration times are extended

• Debugging is tricky (what’s that black box doing ?)

• It’s difficult or impossible to compare similar algorithms

• It’s difficult or impossible to rapidly prototype a system

Alg

AlgAlg

Alg

Application

TMS320 DSP

Alg

ALGORITHMPRODUCERS

write once, deploy widely

ApplicationAlgorithm

ease of integration

SYSTEMINTEGRATORS

TMS320TM DSP AlgorithmStandard

Specification

Rules & Guidelines Programming rules Algorithm packaging Algorithm performance DSP platform

C5000 C6000

TEXASINSTRUMENTS

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 algorithm’s: memory, latency, speed

For a DSP Algorithm Standard to be successful, it must:

Requirements of a Successful Standard

TI’s

eXpressDSP

Algorithm

Interface

Specification

meets all these requirements

XDAIS

TMS320TM 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

StackLocal variables; managed by algorithm

Man

aged

by

App

licat

ion

“Fra

mew

ork” Heap

Contains algorithm objects and variable-length buffers Read/Write data May be allocated and freed at run-time (dynamic systems)

Scratch memoryUndefined pre & post condition of data in buffer

Persistent memory Pre-condition(t): data in buffer = post-condition(t - 1)

Static DataData allocated at link time; shared by all instances

Algorithm A Persistent A

Scratch BAlgorithm B

Scratch BPhysicalMemory

Persistent B Scratch A Persistent 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

ScratchAlgorithm A

ScratchAlgorithm B

Persistent CScratchAlgorithm C

ScratchPhysicalMemory

Persistent B

Persistent A

Persistent A Persistent B Persistent C

Usually a: Limited Resourceeg: Internal RAM

Often an: Extensive Resourceeg: External RAM

Scratch RAM 1 Scratch 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

A B C D E

F

A-E have enough space to all run in parallel. F needs all the scratch, soA-E are all Deactivated tomake 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 interrupts HWI_disable HWI_enable

• Disable scheduler SWI_disable SWI_enableTSK_disable TSK_enable

• Task Semaphores (lock, unlock) SEM_pend SEM_post• Raise priority SWI_raisepri SWI_restorepri

TSK_setpri TSK_setpri

Instance0

Static Read-only Data

Instancen

… 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

TMS320TM 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 controlsare available?

How do we optimize forstatic 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 Memory Types:

External (slow, plentiful, lower cost)

Internal (fast, limited, higher cost)

SARAM, DARAM

SizeSize

AlignmentAlignment

TypeType

Scr/PersistScr/Persist

AddressAddress

SizeSize

AlignmentAlignment

TypeType

Scr/PersistScr/Persist

AddressAddress

SizeSize

AlignmentAlignment

......

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: Here’s 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 it’s 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

Alg

orit

hm I

nsta

nce

Ap

plic

atio

n “

Fra

mew

ork”

Alg

orit

hm M

odul

e

Call algNumAlloc() to get # of memory reqs

Call algAlloc() to get memory requests

Alg

orit

hm I

nsta

nce

Call algActivate() to prep instance for use

Call algDeactivate() to prep for mem re-use

Initialize scratch memory

Call algorithm processing methods Process data, return result

Save state to persistent memory

Call algInitObj() to initialize instance object Initialize instance object

Call algFree() to retrieve buffer pointers Return 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

TMS320TM 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);Int algAlloc(const IALG_Params *,…);Int algControl(IALG_Handle, …);Int algDeactivate(IALG_Handle);Int algFree(IALG_Handle, …);Int algInit(IALG_Handle, …);Void algMoved(IALG_Handle, …);Int algNumAlloc();

Void decode(IG729_Handle, IG729_Frm …);Void encode(IG729_Handle, Int16 *in,…);Void …

IG729_Fxns

- - 3434

Algorithm interfaces are abstract interfaces derived from IALGIALG functions provide the methods to create/manage “instance objects”Additional module-specific functions are appended to accessthe algorithms themselves

Abstract interfaces define a “v-table” for accessing the module’s functionsAbstract interfaces define module functions as a structure of pointers

Algorithm “Module” Interface

Application

Standard Module Vendor

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.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 inferredInstallation is simplified; generic installation programs can be created

Supports vendor differentiation: Vendor specific operations can be addedSimplifies code audits: Understand one algorithm you know them all

Naming Rules

TMS320TM 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

…

.cinitcopy of V table

.bss

globals

vtable “XY”

X_Y_num

X_Y_alloc

X_Y_init

…

X_Y_run

…

module interface algorithm 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

...

.cinitcopy of V table

.bss / stack

handleXY

.sysmem

instanceXY

*IALG_Fxns

*a

*x

*x_stg

1. On build Alg code2. At boot V.table3. FIR_TI_Alloc() mem for: inst obj,

x, a, x_stg4. FIR_TI_InitObj() fill inst.obj & persist

5. FIR_TI_Activate() fill scratch6. FIR_TI_Run() process FIR filter7. FIR_TI_Deactiv() x[100] to x_stg, reclaim x8. FIR_TI_Free reclaim inst.obj,x_stg, a

x

+

.bss

globals

vtable XY

a[100]

x[100]

x_stg[100]

SWI A

IDLE

Hi Priority

Low Priority

Process Process

SWI B

Process

Concurrent running of multiple instance of the same algorithm must be supported. Allow repeated entries in a preemptive environmentReentrancy 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 A’s

context overwrite B’s?

During this time, both A and B are running the same function. How do we avoid having A’s

context overwrite B’s?

Re-entrancy & Multiple Instances

Multiple Instances of an Algorithm.textalgcode.cinitcopy 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 commonScratch can be common or separate

as desired

.bss

globals

vtable XY

a[100]

x[100]

x_stg[100]

x[100]

x_stg[100]

TMS320TM 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

Alg

Alg

Core Run-time

A/D

D/A

ctrl

status

DSP

Alg

o S

tan

dar

d

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” managesall 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 instancesAlgorithms are not, and may not uses threads

Algorithms are “data transducers” not schedulers

G.168

Thread “A”

G.729X

DTMF

G.729Y

DTMF

Thread “B”

Object Based Programming Environment

• Module

– Smallest logical unit of software

– Each module has, defined in the module’s 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

TMS320TM 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 algorithm’s: 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 TMS320TM DSP Algorithm Standard

Compliant Algorithms must include:

Libraries of the code provided

Header files listing the implemented abstract interfaces

Documentation defining the algorithm

LIB H DOC

TMS320TM DSP Algorithm Standard

Compliant Algorithm “Package”

All algorithms must characterize their:Memory requirementsExecution timeInterrupt 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

www.dspvillage.ti.com

TMS320 DSP AlgorithmStandard:

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

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 and reentrancy must be ensured.Memory 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 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

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

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

• Using the TMS320 DSP Algorithm Standard in a Dynamic DSP System \XDAIS\spra580b.pdf

• The TMS320 DSP Algorithm Standard \XDAIS\spra581b.pdf

• Achieving Zero Overhead With the TMS320 DSP Algorithm Standard IALG Interface

\XDAIS\spra716.pdf

• Real-Time Analysis in an eXpressDSP-Compliant Algorithm \XDAIS\spra732.pdf

• 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 Developer’s Guide \XDAIS\spru424.pdf

• TMS320 DSP Algorithm Standard \XDAIS\spru427.pdf