Texas Instruments TMS320 DSP инструкция обслуживания

TMS320 DSP Algorithm Standard Rules and Guidelines User's Guide Literature Number: SPRU352G June 2005 – Revised February 2007[...]

2 SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback[...]

Contents Preface ............................................................................................................................... 7 1 Overview ................................................................................................................... 9 1.1 Scope of the Standard ................................................[...]

4 Algorithm Performance Characterization ..................................................................... 37 4.1 Data Memory ....................................................................................................... 38 4.1.1 Heap Memory ............................................................................................. 3[...]

6.2 Algorithm and Framework ........................................................................................ 62 6.3 Requirements for the Use of the DMA Resource ............................................................. 63 6.4 Logical Channel ................................................................................................[...]

List of Figures 1-1 TMS320 DSP Algorithm Standard Elements ........................................................................... 10 1-2 DSP Software Architecture ................................................................................................ 13 2-1 Scratch vs Persistent Memory Allocation ......................................[...]

Preface SPRU352G – June 2005 – Revised February 2007 Read This First This document defines a set of requirements for DSP algorithms that, if followed, allow system integrators to quickly assemble production-quality systems from one or more such algorithms. Thus, this standard is intended to enable a rich commercial off-the-shelf (COTS) marketpl[...]

www.ti.com Related Documentation • Chapter 6 - Use of the DMA Resource , develops guidelines and rules for creating eXpressDSP-compliant algorithms that utilize the DMA resource. • Appendix A - Rules and Guidelines , contains a complete list of all rules and guidelines in this specification. • Appendix B - Core Run-time Support APIs , contain[...]

Chapter 1 SPRU352G – June 2005 – Revised February 2007 Overview This chapter provides an overview of the TMS320 DSP Algorithm Standard. Topic .................................................................................................. Page 1.1 Scope of the Standard ............................................................... 10 1.2 Req[...]

www.ti.com 1.1 Scope of the Standard Rules for TMS320C2x Level 1 Level 2 Level 3 Level 4 T elecom Rules for TMS320C5x Rules for TMS320C6x Imaging Audio Automotive Other Algorithm Component Model General Programming Guidelines S C callable S No hard coded addresses S Reentrant S etc. S Modules S Generic interfaces S Packaging S etc. S Interrupt usag[...]

www.ti.com 1.1.1 Rules and Guidelines 1.2 Requirements of the Standard Requirements of the Standard Level 3 contains the guidelines for specific families of DSPs. Today, there are no agreed-upon guidelines for algorithms with regard to the use of processor resources. These guidelines will provide guidance on the dos and don'ts for the various [...]

www.ti.com 1.3 Goals of the Standard 1.4 Intentional Omissions Goals of the Standard This section contains the goals of this standard. While it may not be possible to perfectly attain these goals, they represent the primary concerns that should be addressed after addressing the required elements described in the previous section. • Easy to adhere[...]

www.ti.com 1.5 System Architecture ALG ALG ALG Framework Status Cmd Status Cmd Core run time support 1.5.1 Frameworks System Architecture To support the ability of a system integrator to rapidly evaluate algorithms from various vendors, a mechanism should be defined that allows a component to be used for evaluation only. This would encourage algori[...]

www.ti.com 1.5.2 Algorithms 1.5.3 Core Run-Time Support System Architecture Careful inspection of the various frameworks in use reveals that, at some level, they all have algorithm components. While there are differences in each of the frameworks, the algorithm components share many common attributes. • Algorithms are C callable • Algorithms ar[...]

Chapter 2 SPRU352G – June 2005 – Revised February 2007 General Programming Guidelines In this chapter, we develop programming guidelines that apply to all algorithms on all DSP architectures, regardless of application area. Topic .................................................................................................. Page 2.1 Use of C[...]

www.ti.com 2.1 Use of C Language 2.2 Threads and Reentrancy 2.2.1 Threads Use of C Language Almost all recently developed software modules follow these common sense guidelines already, so this chapter just formalizes them. In addition to these guidelines, we also develop a general model of data memory that enables applications to efficiently manage[...]

www.ti.com 2.2.2 Preemptive vs. Non-Preemptive Multitasking 2.2.3 Reentrancy Threads and Reentrancy Non-preemptive multitasking relies on each thread to voluntarily relinquish control to the operating system before letting another thread execute. This is usually done by requiring threads to periodically call an operating system function, say yield([...]

www.ti.com 2.2.4 Example y n + x n * x n * 1 ) 13 32 x n * 2 Threads and Reentrancy The definition of reentrant code often implies that the code does not retain "state" information. That is, if you invoke the code with the same data at different times, by the same or other thread, it will yield the same results. This is not always true, h[...]

www.ti.com 2.3 Data Memory Data Memory void PRE_filter1(int input[], int length, int *z) { int I, tmp; for (I = 0; I < length; I++) { tmp = input[i] - z[0] + (13 * z[1] + 16) / 32; z[1] = z[0]; z[0] = input[i]; input[i] = tmp; } } This technique of replacing references to global data with references to parameters illustrates a general technique [...]

www.ti.com 2.3.1 Memory Spaces 2.3.2 Scratch versus Persistent Data Memory While the amount of on-chip data memory may be adequate for each algorithm in isolation, the increased number of MIPS available on modern DSPs encourages systems to perform multiple algorithms concurrently with a single chip. Thus, some mechanism must be provided to efficien[...]

www.ti.com Scratch Algorithm A Scratch Algorithm B W rite-Once C Scratch Algorithm C Scratch Physical Memory Persistent B Persistent A Persistent A Persistent B W rite-Once C 0000 FFFF 0 1 Algorithm C Scratch Scratch W rite-Once C Data Memory Notice that both a() and b() freely use some of the same scratch registers and no saving and restoring of t[...]

www.ti.com 2.3.3 Algorithm versus Application Persistent Scratch Shared Private Shadow Data Memory Guideline 1 Algorithms should minimize their persistent data memory requirements in favor of scratch memory. In addition to the types of memory described above, there are often several memory spaces provided by a DSP to algorithms. • Dual-access mem[...]

www.ti.com 2.4 Program Memory 2.5 ROM-ability Program Memory Like the data memory requirements described in the previous section, it is important that all eXpressDSP-compliant algorithms are fully relocatable; i.e., there should never be any assumption about the specific placement of an algorithm at a particular address. Alignment on a specified pa[...]

www.ti.com 2.6 Use of Peripherals Use of Peripherals Rule 5 Algorithms must characterize their ROM-ability; i.e., state whether or not they are ROM-able. Obviously, self-modifying Code is not ROM-able. We do not require that no algorithm employ self-modifying Code; we only require documentation of the ROM-ability of an algorithm. It is also worth p[...]

Chapter 3 SPRU352G – June 2005 – Revised February 2007 Algorithm Component Model In this chapter, we develop additional rules and guidelines that apply to all algorithms on all DSP architectures regardless of application area. Topic .................................................................................................. Page 3.1 Inter[...]

www.ti.com 3.1 Interfaces and Modules client.c #include <fir.h> ... FIR_apply(); } fir .h typedef struct FIR_obj *FIR_Handle; extern void FIR_init(); extern void FIR_exit(); extern FIR_HandleFIR_create(); fir_apply .asm FIR_apply: .globalFIR_apply fir_create.c FIR_HandleFIR_create() { Includes Interface Implementation Interfaces and Modules T[...]

www.ti.com 3.1.1 External Identifiers Interfaces and Modules Rule 7 All header files must support multiple inclusions within a single source file. The general technique for insuring this behavior for C header files is illustrated in the Code below. /* * ======== fir.h ======== */ #ifndef FIR_ #define FIR_ 0 #endif /* FIR_ */ A similar technique sho[...]

www.ti.com 3.1.2 Naming Conventions 3.1.3 Module Initialization and Finalization 3.1.4 Module Instance Objects Interfaces and Modules To simplify the way eXpressDSP-compliant client Code is written, it is valuable to maintain a single consistent naming convention. In addition to being properly prefixed (Rule 8), all external declarations disclosed [...]

www.ti.com FIR_Config FIR; FIR_init(); FIR_exit(); FIR_create(); FIR firObject Creates firObject FIR FIR_create(); Creates firObject Int length; Int coeff[]; Int delay[]; Read-only coef ficient array Filter input history buf fer 3.1.5 Design-Time Object Creation 3.1.6 Run-Time Object Creation and Deletion Interfaces and Modules Figure 3-2. Module O[...]

www.ti.com 3.1.7 Module Configuration 3.1.8 Example Module Interfaces and Modules Guideline 4 All modules that support object creation should support run-time object creation. Note that the eXpressDSP-compliant algorithms are a special type of module. When we define algorithms below, we will see how algorithms support run-time object creation. The [...]

www.ti.com 3.1.9 Multiple Interface Support Interfaces and Modules typedef struct FIR_Obj { /* FIR_Obj definition */ int hist[16]; /* previous input value */ int frameLen; /* input frame length */ int *coeff; } FIR_Obj; FIR_Handle FIR_create(FIR_Obj *fir, const FIR_Params *params) { if (fir != NULL) { if (params == NULL) { /* use defaults if params[...]

www.ti.com 3.1.10 Interface Inheritance 3.1.11 Summary Interfaces and Modules module's header file defines a concrete interface; the functions defined in the header uniquely identify a specific (or concrete) implementation within a system. A special type of interface header is used to define abstract interfaces; abstract interfaces define func[...]

www.ti.com 3.2 Algorithms IALG IALG_Fxns FIR_Config FIR; FIR_init(); FIR_exit(); FIR_Fxcs FIR_IALG; FIR Implements Algorithms Element Description Required Module's object definition; normally not struct XYZ_Obj yes defined in the module's header. Handle to an instance object; synonym for XYZ_Handle yes struct XYZ_Obj * Structure type of a[...]

www.ti.com 3.3 Packaging 3.3.1 Object Code Packaging Rule 13 Each of the IALG methods implemented by an algorithm must be independently relocatable. In practice, this simply means that each method should either be implemented in a separate file or placed in a separate COFF output section. By placing each of these methods in a separate file or outpu[...]

www.ti.com 3.3.2 Header Files 3.3.3 Debug Verses Release Packaging <module> is the name of the module (containing characters from the set [a-z0-9]), <vers> is an optional version number of the form v<num> where num consists of characters from the set [0-9], <vendor> is the name of the vendor (containing characters from the s[...]

www.ti.com Packaging If multiple versions of the same component are provided by a single vendor, the different versions must be in different libraries (as described above) and these libraries must be named as follows: <module><vers>_<vendor>_<variant>.1<arch> where <variant> is the name of the variant of the modu[...]

Chapter 4 SPRU352G – June 2005 – Revised February 2007 Algorithm Performance Characterization In this chapter, we examine the performance information that should be provided by algorithm components to enable system integrators to assemble combinations of algorithms into reliable products. Topic ..................................................[...]

www.ti.com 4.1 Data Memory 4.1.1 Heap Memory Data Memory The only resources consumed by eXpressDSP-compliant algorithms are MIPS and memory. All I/O, peripheral control, device management, and scheduling is managed by the application — not the algorithm. Thus, we need to characterize code and data memory requirements and worst-case execution time[...]

www.ti.com 4.1.2 Stack Memory 4.1.3 Static Local and Global Data Memory Data Memory In the example above, the algorithm requires 960 16-bit words of single-access on-chip memory, 720 16-bit words of external persistent memory, and there are no special alignment requirements for this memory. Note that the entries in this table are not required to be[...]

www.ti.com 4.2 Program Memory Program Memory Algorithms must characterize their static data memory requirements by filling out a table such as that illustrated below. Each row represents the requirements for an individual object file that is part of the algorithm's implementation. Each named COFF section (that contains data) in the algorithm&a[...]

www.ti.com 4.3 Interrupt Latency 4.4 Execution Time 4.4.1 MIPS Is Not Enough Interrupt Latency Code Code Sections Size Align a.obj(.text) 768 0 b.obj(.text) 125 32 In most DSP systems, algorithms are started by the arrival of data and the arrival of data is signaled by an interrupt. It is very important, therefore, that interrupts occur in as timel[...]

www.ti.com 3 ms 3 ms 3 ms 3 ms A B Idle 4.4.2 Execution Time Model Execution Time Figure 4-1. Execution Timeline for Two Periodic Tasks In this case, both task A and B meet their deadlines and we have more than 18% (1 ms every 6 ms) of the CPU idle. Suppose we now increase the amount of processing that task B must perform very slightly, say to 1.00[...]

www.ti.com Execution Time Execution time should be expressed in instruction cycles whereas the period expressed in microseconds. Worst-case execution time must be accompanied with a precise description of the run-time assumptions required to reproduce this upper bound. For example, placement of code and data in internal or external memory, placemen[...]

www.ti.com Algorithm Performance Characterization 44 SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback[...]

Chapter 5 SPRU352G – June 2005 – Revised February 2007 DSP-Specific Guidelines This chapter provides guidelines for creating eXpressDSP-compliant algorithms for various DSP families. Topic .................................................................................................. Page 5.1 CPU Register Types ..............................[...]

www.ti.com 5.1 CPU Register Types Read−only Scratch Preserve Init Global Local Read−write CPU Register Types DSP algorithms are often written in assembly language and, as a result, they will take full advantage of the instruction set. Unfortunately for the system integrator, this often means that multiple algorithms cannot be integrated into a [...]

www.ti.com 5.2 Use of Floating Point 5.3 TMS320C6xxx Rules and Guidelines 5.3.1 Endian Byte Ordering 5.3.2 Data Models 5.3.3 Program Model Use of Floating Point It is important to note that the use of global registers by algorithms is permitted. However, like self-modifying code, their use must be invisible to clients. This can be accomplished by e[...]

www.ti.com 5.3.4 Register Conventions 5.3.5 Status Register TMS320C6xxx Rules and Guidelines In addition, no algorithm may ever directly manipulate the cache control registers. It is important to realize that eXpressDSP-compliant algorithms may be placed in on-chip program memory by the system developer. The rule above simply states that algorithms[...]

www.ti.com 5.3.6 Interrupt Latency 5.4 TMS320C54xx Rules and Guidelines 5.4.1 Data Models 5.4.2 Program Models TMS320C54xx Rules and Guidelines CSR Field Use Type EN Current CPU endian mode. Read-only (global) PWRD Power-Down modes Not accessible (global) PCC Program Cache Control Not accessible (global) DCC Data Cache Control. Not accessible (glob[...]

www.ti.com TMS320C54xx Rules and Guidelines There are, of course, cases where it would be desirable that the core run-time support is accessible with near calls. Guideline 13 On processors that support large program model compilations, a version of the algorithm should be supplied that accessed all core run-time support functions as near functions [...]

www.ti.com 5.4.3 Register Conventions 5.4.4 Status Registers TMS320C54xx Rules and Guidelines This section describes the rules and guidelines that apply to the use of the TMS320C54xx on-chip registers. As described above, there are several different register types. Note that any register that is not described here must not be accessed by an algorit[...]

www.ti.com 5.4.5 Interrupt Latency 5.5 TMS320C55x Rules and Guidelines 5.5.1 Stack Architecture 5.5.2 Data Models TMS320C55x Rules and Guidelines ST1 Field Name Use Type INTM Interrupt mask Preserve(global) OVM Overflow mode bit Preserve (local) SXM Fractional mode bit Scratch (local) XF External Flag Scratch (global) The PMST register is used to c[...]

www.ti.com 5.5.3 Program Models 5.5.4 Relocatability TMS320C55x Rules and Guidelines Rule 32 All C55x algorithms must access all static and global data as far data; also, the algorithms should be instantiable in a large memory model. Only the large memory model is supported for the program memory. So there are no special program memory requirements[...]

www.ti.com 5.5.5 Register Conventions TMS320C55x Rules and Guidelines If the algorithm does not use B-bus, then the first column must be zero. If there is more than one block that is accessed by the B-bus, then all the block numbers must be specified in the second column as shown in the above example. Example 2: Any static-data that is accessed by [...]

www.ti.com 5.5.6 Status Bits TMS320C55x Rules and Guidelines The C55xx contains four status registers: ST0, ST1, ST2 and ST3. ST0 Field Name Use Type ACOV2 Overflow flag for AC2 Scratch (local) ACOV3 Overflow flag for AC3 Scratch (local) TC1, TC2 Test control flag Scratch (local) C Carry bit Scratch (local) ACOV0 Overflow flag for AC0 Scratch (loca[...]

www.ti.com TMS320C55x Rules and Guidelines ST3 Field Name Use Type HOMY Host only access mode Read-only (global) HOMX Host only access mode Read-only (global) HOMR Shared access mode Read-only (global) HOMP Host only access mode - peripherals Read-only (global) CBERR CPU bus error Read-only (global) MPNMC Microprocessor / Microcomputer mode Read-on[...]

www.ti.com 5.6 TMS320C24xx Guidelines 5.6.1 General TMS320 DSP Standard Algorithms vs. DCS Modules The C24xx family of DSPs are classified as DSP controllers, and consequently are mainly focused on the “Digital Control Space.” From an algorithm standpoint, the control space is characterized by systems built up from many smaller and reusable sof[...]

www.ti.com 5.6.5 Status Registers 5.6.6 Interrupt Latency 5.7 TMS320C28x Rules and Guidelines 5.7.1 Data Models TMS320C28x Rules and Guidelines Register Use Type AR6 - AR7 C compiler Register variables Yes Accumulator Expression analysis/ return values from a C function Preserve(local) P Resulting Product from a Multiply Scratch(local) T Multiply a[...]

www.ti.com 5.7.2 Program Models 5.7.3 Register Conventions 5.7.4 Status Registers TMS320C28x Rules and Guidelines Only large memory model is supported for the program memory. So no special program memory requirements are needed for this processor. Just to reemphasize the point, all the program code must be completely relocatable and must not necess[...]

www.ti.com 5.7.5 Interrupt Latency TMS320C28x Rules and Guidelines ST1 Field Name Use Type ARP Auxiliary register pointer Scratch (local) XF XF pin status Read Only (global) M0M1MAP M0 and M1 mapping mode bit Read Only (global) OBJMODE Object compatibility mode Read Only (global) AMODE Address mode bit Read Only (global) IDLESTAT IDLE status bit Re[...]

Chapter 6 SPRU352G – June 2005 – Revised February 2007 Use of the DMA Resource The direct memory access (DMA) controller performs asynchronously scheduled data transfers in the background while the CPU continues to execute instructions. In this chapter, we develop additional rules and guidelines for creating eXpressDSP-compliant algorithms that[...]

www.ti.com 6.1 Overview 6.2 Algorithm and Framework Overview Rule 6 states that "Algorithms must never directly access any peripheral device. This includes but is not limited to on-chip DMAs, timers, I/O devices, and cache control registers." The fact is that some algorithms require some means of moving data in the background of CPU opera[...]

www.ti.com 6.3 Requirements for the Use of the DMA Resource 6.4 Logical Channel Requirements for the Use of the DMA Resource through the logical DMA channels it acquires through the IDMA2 protocol. A detailed description of these APIs can be found in the TMS320 DSP Algorithm Standard API Reference (SPRU360). Below is a list of requirements for DMA [...]

www.ti.com 6.5 Data Transfer Properties Elem0 Elem1 Elem2 Elem3 Gaps between elements Element index Frame Element size Frame 0 Frame 1 Frame N-1 Number of frames = N Frame index 6.6 Data Transfer Synchronization Data Transfer Properties Some systems might map each logical channel to a physical channel, while in other systems, several logical channe[...]

www.ti.com 6.7 Abstract Interface Abstract Interface DMA Guideline 1 The data transfer should complete before the CPU operations executing in parallel. However, we can never guarantee that the data transfers are complete before data are accessed by the CPU, even if the algorithm is designed in such a way (e.g., future increase in CPU speed and not [...]

www.ti.com 6.8 Resource Characterization Resource Characterization DMA Rule 3 Each of the IDMA2 or IDMA3 methods implemented by an algorithm must be independently relocateable. The pragma directive must be used to place each method in appropriate subsections to enable independent relocatability of the methods by the system integrator. The table bel[...]

www.ti.com 6.9 Runtime APIs 6.10 Strong Ordering of DMA Transfer Requests Runtime APIs For example, in the table above, the "process" operation is using two logical channels. On logical channel 0, it performs on average 5 data transfers and a maximum of 7 data transfers. The average number of bytes for each transfer is 768, and the maximu[...]

www.ti.com 6.11 Submitting DMA Transfer Requests 6.12 Device Independent DMA Optimization Guideline Submitting DMA Transfer Requests The specification of the ACPY2 interface strives to perform a delicate trade-off between allowing high performance and requiring error checking at run time. Optimized algorithms require high speed transfer mechanisms [...]

www.ti.com 6.13 C6xxx Specific DMA Rules and Guidelines 6.13.1 Cache Coherency Issues for Algorithm Producers Y X = 0ld Y = new X L2 cache External memory DMA X Y X = 0ld Y = new X L2 cache External memory Y DMA C6xxx Specific DMA Rules and Guidelines In certain C6000 targets, data that are in both external memory and the L2 cache can cause coheren[...]

www.ti.com V X = 0ld Y = new VX L2 cache External memory Y DMA Cache line 6.14 C55x Specific DMA Rules and Guidelines 6.14.1 Supporting Packed/Burst Mode DMA Transfers C55x Specific DMA Rules and Guidelines DMA Rule 7 is a rule for the client application writer. For external memory buffers that are acquired using DMA transfers, the corresponding ca[...]

www.ti.com 6.14.2 Minimizing Logical Channel Reconfiguration Overhead 6.14.3 Addressing Automatic Endianism Conversion Issues 6.15 Inter-Algorithm Synchronization 6.15.1 Non-Preemptive System Inter-Algorithm Synchronization Some common C55x DMA devices impose additional restrictions that affect when a channel needs to be reconfigured. A logical cha[...]

www.ti.com DMA/CPU idle CPU context switch CPU/DMA active Algorithm A active Algorithm B active CPU context (timeline) DMA context (timeline) 1 2 3 4 5 6.15.3 Preemptive System DMA/CPU idle CPU context switch CPU/DMA activ Algorithm A active Algorithm B active active Algorithm A CPU context (timeline) DMA context (timeline) 1 2 3 4 5 6 7 Inter-Algo[...]

www.ti.com DMA/CPU idle CPU context switch CPU/DMA active Algorithm A active Algorithm B active active Algorithm A CPU context (timeline) DMA context (timeline) 1 2 3 4 5 6 Inter-Algorithm Synchronization algorithm. Events 1. Algorithm A requests a data transfer by calling ACPY2_start() . The framework executes this request immediately since the DM[...]

www.ti.com Inter-Algorithm Synchronization It is important to notice that preemptive systems might have groups of algorithms that execute with the same priority. A well-designed DMA manager would assign the same physical channels to algorithms at the same priority level to avoid the scenarios described in Section 6.15.4 and Section 6.15.5 . This, o[...]

Appendix A SPRU352G – June 2005 – Revised February 2007 Rules and Guidelines This appendix gathers together all rules and guidelines into one compact reference. Topic .................................................................................................. Page A.1 General Rules .........................................................[...]

www.ti.com A.1 General Rules General Rules Recall that rules must be followed in order for software to be eXpressDSP-compliant. Guidelines, on the other hand, are strongly suggested guidelines that should be obeyed but may be violated by eXpressDSP-compliant software. The rules are partitioned into three distinct sections. The first two sections en[...]

www.ti.com A.2 Performance Characterization Rules A.3 DMA Rules Performance Characterization Rules Rule 25 — All C6x algorithms must be supplied in little-endian format. (See Section 5.3.1 ) Rule 26 — All C6x algorithms must access all static and global data as far data. (See Section 5.3.2 ) Rule 27 — C6x algorithms must never assume placemen[...]

www.ti.com A.4 General Guidelines General Guidelines DMA Rule 3 — Each of the IDMA2 methods implemented by an algorithm must be independently relocateable. (See Section 6.7 ) DMA Rule 4 — All algorithms must state the maximum number of concurrent DMA transfers for each logical channel. (See Section 6.8 ) DMA Rule 5 — All agorithms must charac[...]

www.ti.com A.5 DMA Guidelines DMA Guidelines Guideline 12 — All C6x algorithms should be supplied in both little- and big-endian formats. (See Section 5.3.1 ) Guideline 13 — On processors that support large program model compilations, a version of the algorithm should be supplied that accesses all core run-time support functions as near functio[...]

www.ti.com Rules and Guidelines 80 SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback[...]

Appendix B SPRU352G – June 2005 – Revised February 2007 Core Run-Time APIs This appendix enumerates all acceptable core run-time APIs that may be referenced by an eXpressDSP-compliant algorithm. Topic .................................................................................................. Page B.1 TI C-Language Run-Time Support Librar[...]

www.ti.com B.1 TI C-Language Run-Time Support Library B.2 DSP/BIOS Run-time Support Library TI C-Language Run-Time Support Library Recall that only a subset of the DSP/BIOS and the TI C run-time support library functions are allowed to be referenced from an eXpressDSP-compliant algorithm. In the future, this list of allowable APIs will grow to incl[...]

C.1 Books C.2 URLS Appendix C SPRU352G – June 2005 – Revised February 2007 Bibliography This appendix lists sources for additional information. Dialogic, Media Stream Processing Unit; Developer's Guide , 05-1221-001-01 September 1998. ISO/IEC JTC1/SC22 N 2388 dated January 1997, Request for SC22 Working Groups to Review DIS 2382-07 . Inter[...]

www.ti.com Bibliography 84 SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback[...]

D.1 Glossary of Terms Appendix D SPRU352G – June 2005 – Revised February 2007 Glossary Abstract Interface — An interface defined by a C header whose functions are specified by a structure of function pointers. By convention these interface headers begin with the letter 'i' and the interface name begins with 'I'. Such an in[...]

www.ti.com Glossary of Terms Endian — Refers to which bytes are most significant in multi-byte data types. In big-endian architectures, the leftmost bytes (those with a lower address) are most significant. In little-endian architectures, the rightmost bytes are most significant. HP, IBM, Motorola 68000, and SPARC systems store multi-byte values i[...]

www.ti.com Glossary of Terms Scheduling — The process of deciding what thread should execute next on a particular CPU. It is usually also taken as involving the context switch to that thread. Scheduling Latency — The maximum time that a "ready" thread can be delayed by a lower priority thread. Scratch Memory — Memory that can be ove[...]

IMPORTANT NOTICE Texas Instruments Incorporated an d its subsidiaries (TI) reserve the right to make corrections, modifications, enhancements, improveme nts, and other changes to its products a nd services at any time and to discontinue any product or s ervice without notice. Cu stomers should obt ain the latest relevant inf ormation before placing[...]