1 expressdsp software technology seminar. 2 1.introduction 2.tms320 family of digital signal...

1eXpressDSP™ Software Technology Seminar

2

1. Introduction

2. TMS320™ Family of Digital Signal Processors

3. Software Development with Code Composer Studio™ IDE

4. Real-Time Software Analysis with DSP/BIOS

5. Real-Time Software Scheduling with DSP/BIOS

6. The TMS320™ DSP Algorithm Standard

7. Conclusion

Contents

3TMS320™ DSP Algorithm Standard (XDAIS)

eXpressDSP™ Software

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 ofThe Standard?

What makes a good standard?

4eXpressDSP™: The DSP Software Solution Set

Code Composer Studio™ IDE Powerful,integrated developmenttools

DSP/BIOSReal-time software foundation

TI DSPThird-Party NetworkSoftwareand support

TMS320™ DSP Algorithm StandardStandards for application interoperability and reuse

5

- IDE -

Elements of eXpressDSP™

Host Tools Target Content

TMS320™ DSP

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

Your Application

• Plug-in Tools• Analysis• ADC Config

Host Computer DSP/BIOSRTDX Real-Time Analysis

TMS320™ DSPAlgorithm Standard

JTAG

6Problems with Non-Standardized Algorithms

Today it’s difficult to integrate real-time algorithms from more than a 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

7

ALGORITHMPRODUCERS

Write once, deploy widely

ApplicationAlgorithm

Ease of integration

SYSTEMINTEGRATORS

TMS320™ DSP AlgorithmStandard

Specification

Rules & Guidelines Programming rules Algorithm packaging Algorithm performance DSP platform

C5000™ C6000™

TEXASINSTRUMENTS

TI Enhances Vendor / User Process

8

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

9

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

eXpressDSP™ AlgorithmInterface Specificationmeets all these requirements

XDAIS

10TMS320™ DSP Algorithm Standard

Algorithm Memory Types

Scratch vs Persistent

Controlling Memory Sharing

Static Shared Memory

Introduction

Memory types


Abstract interface

Instance objects


Conclusions

What kinds of memory can algorithms specify?

How do I minimize memory usage?

What system options do I have?

11Types of Memory Needed by Algorithms

Stack Local variables; managed by algorithm

Man

aged

by

Appl

icat

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

12

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

13Scratch 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 Resourcee.g.: Internal RAM

Often an: Extensive Resourcee.g.: External RAM

14

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

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

16

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


Introduction

Memory types


Abstract interface

Instance objects


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

18

AlgorithmKnows memory requirementsRequests appropriate resources from Application

Application “Framework”Manages memory requirementsDetermines what memories are available to which algorithms - and whenPhysical Memory Types:External (slow, plentiful, lower cost)Internal (fast, limited, higher cost) SARAM, DARAM

SizeAlignment

TypeScr/Persist

AddressSize

AlignmentType

Scr/PersistAddress

SizeAlignment

...

Memory Setup Model

19

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: These are 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 (e.g.: history buffers, etc.)

App may now call alg processing functions to run its 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: Deallocate any desired scratch memories for use by other components

Algorithm Memory Interrogation Sequence

20

Alg

orith

m In

stan

ce

App

licat

ion

“Fr

amew

ork”

Alg

orith

m M

odul

e

Call algNumAlloc() to get # of memory reqs

Call algAlloc() to get memory requests

Alg

orith

m In

stan

ceCall 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

21

algNumAlloc()

algAlloc() algInitObj()

algDeactivate()algFree()

algActivate()

algMoved() PROCESS

Dynamic Systems: Run once: Activate, Process, Deactivate Run many: Activate, Process, Process, … , Deactivate 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


IALG Abstract Interface

Module Interface

Interface Options

Naming Rules

Introduction

Memory types


Abstract interface

Instance objects


Conclusions

How do I access IALG functions?

How do I access algorithm functions?

Is there a naming style I can rely upon?

23

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.

24

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

- - 2424

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 module’s functions Abstract interfaces define module functions as a structure of pointers

Algorithm “Module” Interface

25

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

e.g.: “Shortcuts”

Interface Options

26

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 C62x™ targetMOD_VEN.a62e C62x™ target - big endianMOD_VEN.a54f C54x™ target - far call/rtn versionMOD_VEN.a54n C54x™ 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

Naming Rules


The Instance Object

App to Alg Control Flow

Reentrancy

Multiple Instances

Introduction

Memory types


Abstract interface

Instance objects


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?

28

.textnum …alloc …

run …

.cinitcopy of V table

Algorithm code

.bss globals

vtable “XY”X_Y_numX_Y_allocX_Y_init…X_Y_run…

Module interface

.bss / stack handleXY

.sysmem instanceXY *IALG_Fxns

*a*xlen...

Instance Object:table of pointers to data structures1: ptr. to v.table2-N: alg data arrays and variables

Application-to-Algorithm Control Interface

29Application-to-Algorithm Chronology

.textalgcode....cinitcopy of V table

3. FIR_TI_Alloc() mem for: inst obj,x, a, x_stg

1. On build Alg code

.bss

x[100]

5. FIR_TI_Activate() fill scratch

x

+

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

2. At boot V.table

globals

vtable XY

.bss / stack

.sysmem

4. FIR_TI_InitObj() fill inst.obj & persist

a[100]

x_stg[100]

instanceXY*IALG_Fxns*a*x*x_stg

handleXY

30

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

During this time, both A and B are running the same function.

How do we avoid having A’s context overwrite B’s?

Reentrancy & Multiple Instances

31Multiple 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 common Scratch can be common or separate as desired

.bss globals

vtable XY

a[100]

x[100]

x_stg[100]

x[100]

x_stg[100]


Coding Rules

Threads vs Algorithms

Object-Based Programming

Introduction

Memory types


Abstract interface

Instance objects


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?

33

Application

Alg

Alg

Alg

Core Run-Time

A/D

D/A

ctrl

status

DSP

Alg

o St

anda

rd

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

34Threads 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 instances Algorithms 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”

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


Value of The Standard

Algorithm “Package”

Algorithm Documentation

Developer Resources

System Overhead

Introduction

Memory types


Abstract interface

Instance objects


Conclusions

37

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 TMS320™ DSP Algorithm Standard

38

Compliant algorithms must include: Libraries of the code provided Header files listing the implemented abstract interfaces Documentation defining the algorithm

LIB H DOC

TMS320™ DSP Algorithm Standard

Compliant Algorithm “Package”

39

All algorithms must characterize their:

Memory requirements

Execution time Interrupt latency

Standard basis for comparison and tradeoffs

Algorithm Performance Characterization

40Algorithm Developer Resources

Documents Manuals Application notes

Developer’s Kit Run-time support libraries and all interface headers Example algorithms and applications source code Development tools

Web resource www.ti.com/expressdsp

41TMS320™ DSP Algorithm Standard Overhead

Object and indirection:Limited to a few extra instructions

Code space overhead:Code space can be recovered in static systems

Data space overhead:One word per instance object minimum One function table per algorithm module

42Invent the Future ...