Presentation is loading. Please wait.

Presentation is loading. Please wait.

Modular Application Software Solutions

Similar presentations

Presentation on theme: "Modular Application Software Solutions"— Presentation transcript:

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

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

Download ppt "Modular Application Software Solutions"

Similar presentations

Ads by Google