1. Modular Application Software Solutions
eXpressDSP
Modular Application Software Solutions
for TMS320 DSPs

2. The DSP Software Challenge
hardware capability
application complexity
just ship it !!
TIME-TO-MARKET
PRESSURE % HW SW t
increased cost/risk
insufficient re-use
Software has become increasingly important to TI as part of an overall DSP solution for our customers. Here’s why....
DSP hardware capability increasing at a dramatic pace
more MIPS, less power, greater integration, etc
no end in sight; nothing but “green lights” ahead
complexity of applications targeted at today’s DSPs rising at comparable rates
yesterday’s 1000 line assembly programs becoming 100,000 lines of C code
can we develop SW fast enough to harness HW capability; “red light”
software now dominates the overall engineering costs of DSP product development
estimates range as high as 80%; 4 out of 5 developers on a typical project
putting a chip and some memory on a board is “easy”
if you’re late to market, it’s probably because of a SW (not HW) problem
insufficient re-use of pre-fabricated software components
most designers “re-invent” the wheel from one application to the next
no relief from management regarding timely product delivery
market windows actually shrinking, despite increased SW cost/complexity
software has emerged as the critical factor
if you fail, it’s probably because software overwhelmed you
but software is also where you differentiate and innovate; the key to success
So let’s look at how TI has responded to the challenge of DSP software....
software — the critical factor

3. Elevating The Platform
EDN Innovation of the Year
eXpressDSP
integrated development tools
real-time software foundation
standards for interoperability
network of third-party partners
target program
application frameworks
Code Composer Studio™ 
alg
plug-in
TMS320 DSP
Algorithm
Standard
With the fall 99 announcement of our eXpressDSP Real-Time Software Technology, TI has once again raised the bar and set new standards across the industry....
create a discontinuity from SW environment of the past
basic (command-line) tools for building and debugging target DSP programs
eXpressDSP introduces four essential ingredients into today’s DSP SW environment
ingredients not necessarily found in our competitors offerings
(1) integrated development environment, known as Code Composer Studio
world-class HLL program generation tools; industry’s leading debugger
intuitive, easy-to-learn visual environment; open and extensible
(2) real-time software foundation, which is DSP/BIOS
not enough to have world-class tools, if we just “re-invent” the wheel
BIOS comprises essential target software content common to all applications
enables real-time program analysis through real-time host link (RTDX)
(3) standards for application interoperabilty, such as TMS320 DSP Algo. Std.
enables easy integration of independent (third-party) software components
analogous to “building codes” that standardize wiring, plumbing, etc
potential to add unlimited value to the BIOS software foundation
(4) thriving network of third-party partners that build upon this infrastructure
over 400 third-parties; larger than our two biggest competitors combined
add plug-ins and supplementary tools to (1)
extend (2) with platform-specific drivers and/or network communications modules
flesh out (3) with 100s of compliant algs that interoperate
skeletal application frameworks that build upon (1), (2), and (3)
won “EDN Innovation of the Year Award” in 2000
All that you see here is available today, ready to address your needs through modular application software solutions that leverage the efforts of others to the greatest extent possible. But first, let’s consider the alternative....
program
build
program
debug
real-time
analysis
RTDX™
DSP/BIOS™
drivers
comm
host computer
TMS320 DSP

4. Grow Your Own ... too costly to develop too costly to enhance
too costly to maintain
application
alg
alg
application
I/O
scheduler
comm
alg
scheduler
I/O
application
app + alg
alg
scheduler
application
app + algA + algB + ...
app + sched + algAn + algBn + ...
Developing DSP application software entirely from scratch, while seemingly simple at first, can lead you down a slippery slope from which there is no escape....
(1) execute a single algorithm, written in software, on suitable DSP hardware
possibly leverage 3rd-party IP, but with some NRE for customization
(2) encapsulate algorithm in an application program performing other system functions
HW initialization, data I/O, control, etc.
(3) new requirements; need to add a second DSP algorithm to the mix
incompatible assumptions with first alg; more NRE to “bring it in line”
individual algorithms often assume they have “run of the house”
(4) using a more powerful DSP; capable of supporting a multi-channel application
need to add a “home-brew” scheduler to serve as a traffic cop
more NRE in the algs to support multi-channel operation (e.g., re-entrancy)
(5) multi-channel systems utilize sophisticated peripheral devices for multi-channel I/O
need to extend our home-brew scheduler to drive I/O devices as well
I/O devices are complex, subtle, and continually being “improved” in new DSPs
(6) suddenly there are multiple processors in the system, DSPs as well as a master GPP
more work in the scheduler to support DSP-DSP communication/synchronization
master-slave GPP-DSP communication involves integration with GPP/OS
here’s the slippery slope....
application grows ever-larger; “house-of-cards” foundation; ticking time-bomb
software costs escalate out-of-control, espcially after initial development
can’t rapidly accommodate new hardware technologies and/or market needs
Using eXpressDSP, you can get a handle on the hidden cost of home-grown DSP software and, quite literally, do more with less....
alg
application
app + sched + I/O + algAn + algBn + ...
application
alg
alg
app + sched + I/O + comm + algAn + algBn + ...
00101
DSP
DSP
GPP

5. §some programming required
... Or Leverage Others
more time to innovate
less time to integrate
ability to differentiate
application
blueprints
off-the-shelf
algorithms
DSP/BIOS™
real-time kernel
Modular
Application
Software
Solutions
CUSTOMER
eXpressDSP™
infrastructure
With eXpressDSP, not only can you work smarter; by leveraging the efforts of others you can actually avoid work altogether and spend your precious engineering resources on more productive endeavors....
(1) eXpressDSP provides a standard “backplane” for target software
ensure interoperability, ease-of-integration, etc.
leverage a mature set of standards already in use
(2) DSP/BIOS kernel implements core functions used in virtually all applications
task scheduling, device I/O, memory mgmt, communication, etc.
leverage technology in deployment for a decade within 1000s of designs
(3) eXpressDSP value web offers extensive catalog of off-the-shelf algorithms
beyond “make vs buy” decision for most customers
leverage IP of the industry’s largest network of third-party partners
(4) TI provides extensive programming examples that serve as application blueprints
program templates, architectural design patterns, software recipes, copyware
leverage our own expertise in DSP system development
result is M.A.S.S. in which you, TI, and our value web all contribute software content
not necessarily a turnkey-solution; not necessarily a “software chipset”
“some programming required”; expect the customer to enhance/extend
eXpressDSP also provides the industry’s best programming tools and IDE (CCS)
the bottom line
more time for creative engineering work; “express” yourself with eXpressDSP
less time integrating disparate software elements; major cost factor today
ability to add unique, differentiated, competitive value to your product
Having seen the big picture of eXpressDSP, let turn our attention to the real-time software foundation provided by the DSP/BIOS kernel....
VALUE-WEB
FOUNDATION
§some programming required
BACKPLANE

6. TMS320 Software Foundation
target programs
DSP/BIOS Kernel Interface
TMS320 DSP Platform
extensible
scalable
DSP/BIOS Kernel Modules
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
When you think of targeting an application program to a TMS320 DSP, that platform is more than just silicon; it also incorporates a set of scalable, extensible software modules that comprise the DSP/BIOS kernel....
module functions invoked from target application through programmatic interface (API)
don’t “re-invent the wheel”; build “skyscrapers” on the foundation we already provide
some important things to know about the DSP/BIOS kernel
application-agnostic; essential functions common to virtually all DSP applications
manages key resources of target platform (CPU, memory, peripherals)
not a generic kernel for MCUs; features designed for unique needs of DSP
supports all 5000, 6000, 2000 devices, including new 55x and 64x architectures
packaged as relocatable, re-entrant SW library (scalability)
only the modules you need are present in the target; minimal memory footprint
many modules written in assembler; reduces MIPS consumption
rule of thumb is < 1K (2K) words on 5000 (6000); less than .1 MIP in many apps
not “new bits”; some modules have been in deployment for over 10 years
part of the CCS product bundle; tightly integrated with other development tools
real-time analysis tools; software-equivalent to a HW logic analyzer
run-time (deployment) license included in the price of every TMS320 DSP
the “floor” which we and our third-parties presume is present (extensibilily)
1000s of new designs each year; used by 80% of our customers; “critical mass”
We mentioned Code Composer Studio; let’s take a closer look at how target programs utilizing DSP/BIOS are developed within this integrated environment....
C5000
C6000
C2000

7. Programming With DSP/BIOS
C- and ASM-callable functions
HOST DEVELOPMENT COMPUTER
Code Composer Studio 
BUILD
program
sources
kernel APIs
interactive configuration tool
kernel modules
CONFIGURATION
kernel-aware debug support
on-the-fly program analysis
executable
image
target application program
VISUALIZATION  
Code Composer Studio integrates all of the hosted tools needed to develop and deploy a target application program that utilizes the DSP/BIOS kernel as part of its execution (or run-time) environment ....
DSP/BIOS is essentially a library of functions callable from C (or assembly-language)
prepare your source files in CCS; include BIOS API headers; embed function calls
dozens of callable target functions, organized into semi-independent modules
programs are built (compiled/assembled) in the usual fashion
interactive tool enables configuration of BIOS modules, tailored to your application
select only the modules you need
set module-specific parameters that control run-time behavior
pre-create kernel data objects (in static systems only) to save memory
output a library of kernel code/data that is linked into program in usual manner
resulting executable file contains BIOS code/data within its image
load, execute, and test programs using JTAG-based emulation and CCS debugger
additional features for displaying status of kernel modules at breakpoints
(task-aware debugging will be supported in future CCS release)
perform “on-the-fly” (real-time) analysis of target program, without halting execution
DSP/BIOS contains functions for capturing information about running program
captured information uploaded to host using RTDX protocol over physical JTAG
>100 kbps RTDX bandwidth (single voice channel); roadmap to 10s of Mbytes/s
CCS contains visual tools for displaying program info; SW “logical analyzer”
unique feature of CCS/BIOS; important for finding “nasty glitches”
“if you can’t see the problem, you can’t fix it”
If you want to know more DSP/BIOS, we’ll shortly be giving you pointers to in-depth technical information about the product; but first, let’s address the “bread-and-butter” of your application — DSP algorithms....
DEBUG
DSP/BIOS Kernel Interface
RTDX
real-time
capture
multiple
threads
hardware
abstraction
JTAG
EMULATION
TARGET TMS320 DSP HARDWARE

8. 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
The TMS320 DSP Algorithm Standard — like DSP/BIOS, another essential ingredient of eXpressDSP — enables our third-party partners to deliver sophisticated signal processing algorithms to the broader marketplace....
rather than “home-grown”, we want to drive a “supermarket” mentality
lots of inventory; lots of suppliers; easy-to-buy; easy-to-use
key metrics (as of 01/01), giving evidence of “critical mass”
~300 algorithms already stamped “eXpressDSP Complaint”
even more algorithms in backlog, awaiting compliance-testing
over 700 compliant algorithms by the end of this year
some important things to know about the Alg Std and our third-party value web
“catalog algorithms”; not unlike “catalog DSPs”
addressing a variety of apps; < non-telecom is a fastest-growing area >
multiple suppliers gives the customer more choice, security, value, etc.
all compliant algs follow rules/guidelines formally prescribed by TI in stds doc
this facilitates “apples-to-apples” comparison; also speeds integration; no surprises
alg std contains generic rules, plus rules specific to 5000, 6000, 2000 ISAs
alg std comprehends spectrum of target systems; static/dynamic, 1/n channels, etc.
streamlined mass-market E-commerce through //dspvillage.com
we strongly encourage you to visit this web site <and will do so again later!!>
Before we demonstrate for you the kind of algorithm-interoperability made possible by the TMS320 DSP Algorithm Standard, let’s understand a little more about the standard itself....
http//dspvillage.ti.com

9. DSP Algorithm Standard
ease-of-integration
ALGORITHM
CONSUMERS
static  alg1  chan1
dynamic  algn  chann
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
Resource Management Framework(s)
To best appreciate the power of the TMS320 DSP Algorithm Standard, we must consider the perspective of algorithm producers as well as algorithm consumers....
the perspective of algorithm producers
they want to see the same work used in many, many application environments
many are “smaller” companies; can’t afford to engage in per-customer NRE
the perspective of algorithm consumers
they want to easily integrate a third-party algorithm into their application
there is quite a spectrum of possibilities; static/dynamic, single/multiple channels
the producer and consumer are separated in time and space; minimal interaction
the alg std dictates rules/guidelines for producers that simplify re-use by consumers
relatively few producers; many, many consumers
additional “work” imposed on producers offset by more consumers, less support
some rationalization for these rules; many are SW “common sense”; <not complete set>
1) consistency, no conflicts with other software
2) consistency, no conflicts, works with standard C code
3) consistency, no conflicts, works with standard C code
4) single/multi-channel, flexible use of program memory
5) a common framework for requesting memory; on-chip, off-chip, scratch, etc.
6) generally disallowed in algs; keeps the alg independent of the platform
7) can impact real-time performance of the system as a whole
8) facilitates apples-to-apples comparison
the alg std also dictates a common programmatic interface implemented by all algs
the consumer (system integrator) implements a “resource framework” as needed
examples covering static to dynamic, with variations as well
Here too, we can provide you with additional technical information on the Algorithm Standard once <!!!> you have found compliant algorihtms that meet your needs....
Common Programmatic Interface
write once, deploy widely
ALGORITHM
PRODUCERS

10. 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
innovate and differentiate — join the 1000s of active DSP customers already using
eXpressDSP
To summarize, here are some key points we’d like you to remember as you consider using TMS320 DSPs in your next application....
< what more can I say; just read the slide!!! >
So let’s get started with eXpressDSP....
FOUNDATION
VALUE-WEB
CUSTOMER
BACKPLANE

11. Let’s Get Started visit http: //dspvillage.ti.com
app notes, bulletins, FAQs, discussion groups, ...
register at TI&ME for personalized content
get first-hand experience with DSP/BIOS
enroll in our hands-on, one-day training course
prototype your application using our DSP Starter Kit
Here’s a number of actions you can take to learn more about eXpressDSP....
visit our on-line DSP village; lots of technical content; be sure to register
take a BIOS workshop; touch the product; pick the instructor’s brain
or play with BIOS on your own; prototype your app; weigh it / time it yourself
if appropriate, see whether a compliant algorithm already exists for your app
if so < and only then!> you can download more info about the alg std
< always give customer a choice; and make sure ‘no’ isn’t one of them!!! >
< use this slide as a ‘presummative close’ >
< assign “action items” for later followup >
< be careful with letting the customer “go it alone”, without some prior study / support >
I know you still may want to investigate this further, but let me ask you this right now: “Do you see any reason why you would not be leveraging eXpressDSP in your next TMS320 design?”
explore the world of compliant DSP algorithms
query our on-line database of third-party products
download the Algorithm Standard Developer’s Kit

12. eXpressDSPTM Software Technology Seminar

13. TMS320TM DSP Algorithm Standard (XDAIS)
Introduction
Memory Types
Memory Setup Sequence
Abstract Interface
Instance Objects
Algorithm Coding Rules
Conclusions
eXpressDSP
Algorithms in Applications
Non-standard Algorithms
Connecting Vendors & Users
Benefits of the Standard
Requirements of a Standard
What is the benefit of the standard?
What makes a good standard?

14. eXpressDSPTM: The DSP Software Solution Set
Code Composer StudioTM IDE Powerful, integrated development tools
DSP/BIOS Real-time software foundation
TMS320™ DSP Algorithm Standard Standards for application interoperability and reuse
TI DSP Third-Party Network Software and support

15. Elements of eXpressDSPTM
Host Tools
Target Content
Your Application
Program Build
Program Debug
Data Visualization
Host APIs
Plug-in Tools
Analysis
ADC Config
TMS320TM DSP Algorithm Standard
- IDE -
DSP/BIOS
RTDX
Real-Time Analysis
Host Computer
JTAG
TMS320TM DSP

16. 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
Application
Alg
Alg
Alg
Alg
Alg
TMS320 DSP

17. TI Enhances Vendor / User Process
ALGORITHM
PRODUCERS
TMS320TM DSP
Algorithm
Standard Specification
Rules & Guidelines
Programming rules
Algorithm packaging
Algorithm performance
DSP platform
C5000
C6000
TEXAS INSTRUMENTS
SYSTEM INTEGRATORS
Algorithm
Application
write once, deploy widely
ease of integration

18. Benefits of the TI DSP Algorithm Standard
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
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

19. Requirements of a Successful Standard
For a DSP Algorithm Standard to be successful, it must:
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
TI’s
eXpressDSP
Algorithm Interface Specification
meets all these requirements
XDAIS

20. TMS320TM DSP Algorithm Standard
Introduction
Memory Types
Memory Setup Sequence
Abstract Interface
Instance Objects
Algorithm Coding Rules
Conclusions
Algorithm Memory Types
Scratch vs. Persistent
Controlling Memory Sharing
Static Shared Memory
What kinds of memory can algorithms specify?
How do I minimize memory usage?
What system options do I have?

21. Types of Memory Needed by Algorithms
Stack
Local variables; managed by algorithm
Managed by Application “Framework”
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

22. Space Inefficient Memory Allocation
Algorithm A
Scratch A
Persistent A
Algorithm B
Scratch B
Persistent B
Physical
Scratch B
Persistent B
Scratch A
Persistent A
Memory
May be OK for speed optimized systems, but may pose problems for systems where minimum memory usage is desired...

23. Scratch Allows for Minimized Memory Size
Algorithm A
Scratch
Persistent A
Algorithm B
Scratch
Persistent B
Algorithm C
Scratch
Persistent C
Physical
Scratch
Persistent A
Persistent B
Persistent C
Memory
Usually a: Limited Resource eg: Internal RAM
Often an: Extensive Resource eg: External RAM

24. Examples of Scratch RAM Management...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, so A-E are all Deactivated to make room for F
Scratch management is entirely at the discretion of the application.
The algorithm is not perturbed by the implementation choices selected.

25. 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_enable
TSK_disable TSK_enable
Task Semaphores (lock, unlock) SEM_pend SEM_post
Raise priority SWI_raisepri SWI_restorepri TSK_setpri TSK_setpri

26. 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
Static Read-only Data …
Static global data
Instance
Instance n
Instance heap data

27. TMS320TM DSP Algorithm Standard
Introduction
Memory Types
Memory Setup Sequence
Abstract Interface
Instance Objects
Algorithm Coding Rules
Conclusions
Memory Setup Model
Memory Setup Sequence
IALG Options
IALG Interface
What are the steps to setting up the memories needed?
What optional controls are available?
How do we optimize for static and dynamic systems?

28. Memory Setup Model Algorithm Size Knows memory requirements
Requests appropriate resources from Application
Size
Alignment
Type
Scr/Persist
Application “Framework”
Manages memory requirements
Determines what memories are available to which algorithms - and when
Address
Size
Alignment
Type
Scr/Persist
Physical Memory Types:
External (slow, plentiful, lower cost)
Internal (fast, limited, higher cost)
SARAM, DARAM
Address
Size
Alignment
...

29. Algorithm Memory Interrogation Sequence
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

30. IALG Object Creation Sequence Diagram
Call algNumAlloc() to get # of memory reqs
Call algAlloc() to get memory requests
malloc()
Call algInitObj() to initialize instance object
Initialize instance object
Call algActivate() to prep instance for use
Initialize scratch memory
Application “Framework”
Algorithm Module
Call algorithm processing methods
Process data, return result
Algorithm Instance
Algorithm Instance
Call algDeactivate() to prep for mem re-use
Save state to persistent memory
Call algFree() to retrieve buffer pointers
Return all buffers and sizes
free()

31. IALG Sequencing & Options
Static Systems:
Setup memory at build-time
At run-time: “Process” only
algNumAlloc()
algAlloc()
algInitObj()
algActivate()
algMoved()
PROCESS
algFree()
algDeactivate()
Dynamic Systems:
Run Once: Activate, Process, De-activate
Run Many: Activate, Process, Process, … , De-activate
Run Always: Activate, Process, Process, …
Change Resources: “algMoved()”
Optional Functions
Required Functions

32. TMS320TM DSP Algorithm Standard
Introduction
Memory Types
Memory Setup Sequence
Abstract Interface
Instance Objects
Algorithm Coding Rules
Conclusions
IALG Abstract Interface
Module Interface
Interface Options
Naming Rules
How do I access IALG functions?
How do I access algorithm functions?
Is there a naming style I can rely upon?

33. IALG Interface 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 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.

34. Algorithm “Module” Interface
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 …
IALG_Fxns
IG729_Fxns
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
- 34

35. Interface Options 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”

36. Naming Rules
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 x 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 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

37. TMS320TM DSP Algorithm Standard
Introduction
Memory Types
Memory Setup Sequence
Abstract Interface
Instance Objects
Algorithm Coding Rules
Conclusions
The Instance Object
App to Alg Control Flow
Re-entrancy
Multiple Instances
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?

38. Application to Algorithm Control Interface
.bss / stack
handleXY
.sysmem
instanceXY
*IALG_Fxns *a *x
len
...
.bss
globals
vtable “XY”
X_Y_num
X_Y_alloc
X_Y_init …
X_Y_run
.text
num …
alloc
run
.cinit
copy of
V table
Instance Object:
table of pointers to data structures
1: ptr. to v.table
2-N: alg data arrays and variables
module interface
algorithm code

39. Application to Algorithm Chronology
.bss / stack
handleXY
.sysmem
instanceXY
*IALG_Fxns *a *x
*x_stg
.bss
globals
vtable XY
a[100]
.text
alg
code
...
.cinit
copy of
V table
x[100] x_stg[100]
x +
1. On build Alg code
2. At boot V.table
3. FIR_TI_Alloc() mem for: inst obj,
x, a, x_stg
4. FIR_TI_InitObj() fill inst.obj & persist
5. FIR_TI_Activate() fill scratch
6. FIR_TI_Run() process FIR filter
7. FIR_TI_Deactiv() x[100] to x_stg, reclaim x
8. FIR_TI_Free reclaim inst.obj,x_stg, a

40. Re-entrancy & Multiple Instances
Hi Priority
Process
Process
Process
SWI A
SWI B
During this time, both A and B are running the same function. How do we avoid having A’s context overwrite B’s?
IDLE
Low Priority
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”

41. Multiple Instances of an Algorithm
.bss/stack
handleXY1
handleXY2
instanceXY1
*IALG_Fxns *a *x
*x_stg
instanceXY2
.bss
globals
vtable XY
a[100]
.text
alg
code
.cinit
copy of
V table
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
x[100] x_stg[100]
x[100] x_stg[100]

42. TMS320TM DSP Algorithm Standard
Introduction
Memory Types
Memory Setup Sequence
Abstract Interface
Instance Objects
Algorithm Coding Rules
Conclusions
Coding Rules
Threads vs Algorithms
Object Based Programming
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?

43. Algorithm Standard Coding Rules
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” manages all hardware resources
Benefits:
No hardware contention
Portability to other DSPs
DSP
A/D
Alg
D/A
Alg
Algo Standard
ctrl
Alg
status
Application
Core Run-time

44. Threads vs Algorithms Compliant algorithms are
A thread may call multiple algorithm instances
Algorithms are not, and may not uses threads
Algorithms are “data transducers” not schedulers
Thread “B”
Thread “A”
G.729 X
G.729 Y
G.168
DTMF
DTMF
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

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

46. TMS320TM DSP Algorithm Standard
Introduction
Memory Types
Memory Setup Sequence
Abstract Interface
Instance Objects
Algorithm Coding Rules
Conclusions
Value of the Standard
Algorithm “Package”
Algorithm Documentation
Developer Resources
System Overhead

47. Value of the TMS320TM DSP Algorithm Standard
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

48. Compliant Algorithm “Package”
Compliant Algorithms must include:
Libraries of the code provided
Header files listing the implemented abstract interfaces
Documentation defining the algorithm
TMS320TM DSP Algorithm Standard
LIB H
DOC

49. Algorithm Performance Characterization
All algorithms must characterize their:
Memory requirements
Execution time
Interrupt latency
Standard basis for comparison and tradeoffs

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

52. Standard: Overview & Rationalization
TMS320 DSP Algorithm
Standard: Overview & Rationalization
Hello and welcome to the overview and rationalization of the TMS320 DSP algorithm standard, the fourth and final section of this online training. My name is Maher Katorgi. I’m a Software Technical Staff supporting Texas Instruments’ eXpressDSP software technology. We're here today to describe the new TMS320 DSP Algorithm Standard and how it will help take algorithm components to the next level.

53. Interactions with eXpressDSP Technologies
Agenda
Overview
Interactions with eXpressDSP Technologies
Rationalization and Benefits
The agenda for this section consists of three parts. First, we will present an overview of the TMS320 DSP algorithm standard. Next, we will highlight the relationship between the algorithm standard and other tools of the expressDSP technology. Finally, we will explain the rationale behind the rules that make up the algorithm standard and highlight their benefits to consumers of algorithms complying to these rules.

54. TMS320 DSP Algorithm Standard
ease-of-integration
ALGORITHM
CONSUMERS
static  alg1  chan1
dynamic  algn  chann
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
Resource Management Framework(s)
TI's TMS320 DSP Algorithm Standard is specifically designed to achieve these goals. The standard is made up of over 30 programming rules and several additional guidelines, some of which we'll take a look at in a minute. The rules cover general programming issues that cover all algorithms, specific rules for each of the TI platforms, specific resource management APIs for handling memory and DMA, and finally algorithm characterization rules.
Common Programmatic Interface
write once, deploy widely
ALGORITHM
PRODUCERS

55. 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
eXpressDSPTM
Different tools to solve
different problems
DSP Algorithm Standard
off-the-shelf software
Multi-Channel
Static or dynamic
Memory and DMA management
Single or multi-channel
DSP/BIOS II
meet real-time goals
Multi-algorithm
Software scheduling
Real-time analysis
Hardware abstraction
The third dimension is the physical dimension. These are the actual resources like banks of memory and DMA channels, incredibly valuable resources on any DSP system. The DSP Algorithm Standard is specifically tailored to help solve these resource management issues. In particular it helps with both static and dynamic systems, single or multi-channel environments, plus different memory types and DMAs.
Added together, these three dimensions give the user an incredibly powerful development and debug environment not offered by any other solution.

56. Algorithm Standard - Rules & Benefits
Consistency/Ease of Integration
Hands off certain registers
Access all data as far data
Little endian format
DSP/BIOS name conventions
Portability/Flexibility
Re-entrant code
Code must be re-locatable
No direct access peripherals
Usability/Interoperability
Standardized memory management
Standardized DMA management
Measurability
Worst case memory usage
Worst case interrupt latency
Worst case execution time
Finally, there is measurability. This enables the specifications for algorithms to be previewed and verified. Examples of these are memory requirements, worst case interrupt latency, and worst case execution time. It is these standardized metrics that make it so much easier to compare one algorithm to another.

57. Objective
Explain the rationale behind the rules of the eXpressDSP Algorithm Standard and their benefits to customers of compliant algorithms.
The goal of this session is to the explain to you the rationale behind the rules that make up the eXpressDSP algorithm standard and to highlight their benefits to consumers of algorithms complying to them.

58. TMS320 DSP Algorithm Standard
Definition
TMS320 DSP Algorithm Standard
A set of rules designed to ensure components interoperate with algorithms from different vendors in virtually any application.
First, I would like to start with a definition of what the eXpressDSP standard really is. Simply put, it is a set of rules and guidelines that allow algorithms from different vendors in virtually any application to play nice together.

59. 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 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 B e n f i t s
Ease of Integration
Binding algorithms to application
Control flow of data between algorithms
No run-time surprises
With that I’ll move to the rules.
By far, C language is the common interface language in most DSP systems. Software sub-systems making up the solution are bound together using C. By ensuring that the algorithms are callable by C and follow the C runtime conventions, a system integrator can now easily bind algorithms together, control the flow of data between algorithms, and interact with other processors in the system without any concern that algorithms will interfere with application state. This does not entail that algorithms must be written in C, but that they must be callable from the C language and maintain the C language runtime conventions.

60. 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 and reentrancy must be ensured.
Memory or global variables shared by multiple instances must be protected B e n f i t s
Flexibility
Optimized program memory usage (e.g. multiple channels will be running same code)
Maintains integrity of algorithm instance data
Reentrancy.
Any real time embedded system must address the reentrancy issues. All but the simplest systems will most likely require reentrant code. Reentrancy is crucial to any section of code that may be invoked more than once (Multi-channel systems for example). Moreover in a real time OS, each task is independent and therefore reentrancy becomes a real concern. Any function shared between tasks can be a source of problem, since the scheduler can context switch on a timer tick during the execution of this critical routine, and then schedule another task that invokes the same function. Each instance of execution must have its own set of local variables to avoid corrupting the other instance. In multi-channel systems, functions must be reentrant if more than one channel is to use it.
What are the consumer benefits:
They can create multiple algorithm instances running same code simultaneously. One set of code in program memory and multiple instances using it. All of that happening in real-time while maintaining integrity of each instance data intact.

61. 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 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
All DSP programmers are aware of the limited on-chip memory resource available to them. In order to increase the functionality, many DSPs also provide larger amounts of external memory, but not without a penalty. This external memory is significantly limited by the increased access time. Since on-chip memory is significantly faster than off-chip memory, algorithms tend to place frequently accessed data in on-chip memory for optimization. It now becomes the system integrators duty to determine the optimal location for each algorithm component. This rule must be implemented in order to simplify this task.
Similarly, many algorithms have initialization code that is run once during the lifespan of an application. The cost of execution for this “run-once” code is usually not a factor and therefore may be placed in external memory.
Consumer benefits? Portability for one. Algorithms can be transferred between systems with different memory configuration, from a 6201 to a 6211 architecture for example. Flexibility is another benefit allowing optimum use of memory resources and ability to run in different operating environment such as with or without cache on the 6211 architecture for example.

62. 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 f i t s
Interoperability
Framework manages resources
No resource competition
Portability
Transfer s/w between systems
Platform independence
The sole purpose of an algorithm is to process information. This is a fundamental assumption of the eXpressDSP standard. The algorithm is not aware of peripherals on the system it is running on. The client of that algorithm (framework) is responsible for fetching the data from the system and explicitly passing it to the algorithm. One might argue that algorithms should be able to directly acquire data from a peripheral device, but with all the variations in chip designs and board layouts, there is no way to guarantee that the algorithm will run in a system with a chip that has the designated peripheral. Let’s say the designated peripheral does exist, what if two algorithm use DMA? Worse, the both algorithms require DMA be configured differently. The algorithms would not be able to work together.
Benefits to consumers? This rule will ensure interoperability of compliant algorithms by not having algorithm compete for peripheral resources. It also drive portability in that algorithm are independent of the platform they run on and hence can be moved between systems.

63. 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.
Algorithms must avoid name space collisions
Different algorithms may have same name for data types and functions
Application cannot resolve multiply-defined symbols B e n f i t s
Ease of integration
No name space collision
Single consistent naming convention
Shorter system integration time
Consistency
Enhanced code readability
Compliant algorithms intended for use with DSP/BIOS
One of the most frequently encountered problems in integrating multiple algorithms is having external identifiers being declared more than once. System integrators will waste valuable time waiting for a vendor to rename identifiers within the algorithm to resolve this problem. In order to avoid this namespace collision, algorithm providers must prefix all external identifiers in a module with the API or API and vendor. This naming convention will ensure that integrators are one step closer to a seamless integration. Furthermore, one of the primary benefits of following a single consistent naming convention is the ability to clarify the purpose, logic, and information flow within code. System integrators can leverage the use of naming convention to simplify the integration of multiple algorithms within a system by greatly enhancing the readability of code. One may ask why was the DSP/BIOS standard chosen? The DSP/BIOS naming convention was chosen not only because compliant algorithms were intended to be incorporated into systems that use DSP/BIOS, but because it provided the benefits stated above. Clearly the benefits to consumer are consistency and ease of integration.

64. Module External References
All undefined references must refer to operations from a subset of C runtime support library functions, DSP/BIOS or other eXpressDSP-compliant modules.
Algorithms are as compliant as the modules they invoke
Algorithm must not reference non-compliant modules B e n f i t s
Ease of integration
DSP/BIOS and C RTS part of CCS
Single consistent naming convention
Shorter system integration time
Consistency
Enhanced code readability
Compliant algorithms intended for use with DSP/BIOS
An algorithm is only as compliant as the functions/modules that it invokes. In order for an algorithm to maintain the integrity of compliance, it must not reference any non-compliant functions/modules. For example, if an algorithm references a function that has been determined to be non-reentrant, the algorithm would also inherit that non-reentrant attribute. The eXpressDSP standard specs document a list of TI C-Language Run-time Support Library functions and DSP/BIOS Runtime Support Library modules that can be safely referenced by a compliant algorithm.
Again in this case, the benefits to consumers are consistency and ease of integration.

65. Abstract Interface Implementation
All algorithms must implement the IALG interface.
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 B e n f i t s
Ease of integration
Uniform abstract interface
Learn once apply many
Shorter system integration time
Interoperability/Consistency
Uniform abstract interface
Flexibility
Running algorithms in virtually any execution environment
The abstract algorithm interface (IALG) defines a framework for the creation of algorithm instance objects. It must be implemented by all algorithms in order for them to define their memory resource requirements, therefore enabling the efficient use of on-chip data memories by the client application. The client and algorithm now have a defined communication protocol used in creating, managing and terminating an algorithm instance object at run-time. All of the features of the IALG interface allow clients to uniformly manipulate all algorithms within any system.
What are the benefits to consumers?
Uniform communication interface supports interoperability. Ease of integration is another benefit in that integrators would learn the communication protocol once and apply it to all compliant algorithms being integrated leading to shorter integration time. The IALG interface is also flexible in that it allows the client to use the algorithm in virtually any system (i.e., preemptive and non-preemptive, static and dynamic).

66. Abstract Interface Implementation
Each of the IALG methods implemented by an algorithm must be independently relocatable.
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 B e n f i t s
Flexibility
Placement of algorithm components anywhere in memory
Support for design/run-time (static/dynamic) integration
(SPRA577, SPRA580, SPRA716)
In order to support both design-time creation and run-time creation of algorithm objects, all methods defined by the IALG interface must be independently relocatable. By simply placing each method in a separate file or in a separate compiler output file format (COFF) output section, the linker can be used to optimize placement of algorithm components in memory or eliminate unnecessary methods not required in run-time object creation. Both leading to optimum use of memory.
Benefits? Flexibility, ability to optimize memory usage and support of design/run- time systems. Applications notes demonstrating such flexibility including one demonstrating integrating algorithms with zero overhead (SPRA716); well that’s not exactly true. Only one word of memory is required; are available on TI web site.

67. Algorithm Packaging
Each compliant algorithm must be packaged in an archive which has a name that follows a uniform naming convention.
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 B e n f i t s
Consistency
Uniform naming convention
Ease of integration
Single consistent naming convention
Unique archive names (no symbol collision)
Shorter system integration time
Flexibility
Support different development systems
System integrators know the harsh reality of linking an application and realizing that symbols may be multiply defined. Well, the same frustration may occur in copying algorithms with the same name from multiple vendors into a single directory. Maybe the vendor has provided multiple versions of the same algorithm with the same filename. It becomes a hassle for system integrators to rename all these files. This rule have addressed this issue so that each vendor organizes the filenames rather than have all the system integrators try to keep track of all the algorithms. Since most modules may consist of many object files, algorithms must be delivered in a form that can be uniformly integrated into a system. The standard has determined the method of delivery to be an archive. To ensure that no two algorithms have the same archive name, all algorithms must follow the naming convention. To further ensure the usage of the algorithm on both UNIX and Windows development systems, all archives must not be case sensitive.
Consumer Benefits in this case are uniform naming convention for consistency, support for different development systems (Unix, windows) for flexibility and ease of integration no symbol collision surprises.

68. 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
Planning integration of algorithm A vs. B into system
Assess performance metrics and compatibility with system
Assess resource requirements and compatibility with system
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.) B e n f i t s
System integrators would have no problem creating systems if DSPs have unlimited resources. Unfortunately DSPs have a limited amount of program/data memory available. Therefore algorithm providers must characterize these memory requirements for their algorithms. Otherwise the burden of determining how much memory is allocated for each algorithm is placed on the system integrator. While this task is not impossible, it is quite costly and inefficient. Characterizing memory requirements will allow system integrators to determine the feasibility of a particular algorithm in their system. Interrupt latency, the maximum time interrupts are disabled, must also be documented. It is important that the designer know this time so that the system can compensate for it. Also typical period and worst case execution time must be documented. This improves the integrators ability to integrate, plan and schedule the algorithm without breaking real-time of the system and risking data loss. Clearly the benefit to the consumer is measurability. All these metrics give the integrator a measure for comparing algorithm A vs. B. they also simplifies integration by allowing optimum resource management.

69. Summary of Key Benefits
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
Portability
Transfer s/w between systems
Platform independence
Measurability
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
Consistency
Uniform naming conventions
Enhanced code readability
Interoperability
Uniform abstract interface
No resource competition
In summary these are the key benefits in one slide that customers can have when they integrate compliant algorithms into their system solutions.
This concludes this presentation session.

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

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