TMS320 DSP Algorithm Standard Rules and Guidelines User's Guide Literature Number: SPRU352G June 2005 – Revised February 2007
SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback
Contents Preface ............................................................................................................................... 7 1 Overview 1.1 ................................................................................................................... 9 Scope of the Standard ............................................................................................ 10 1.1.1 Requirements of the Standard 11 1.3 Goals of the Standard 12 1.5 12 13 13 14 14 .................
4.1 4.2 4.3 4.4 5 5.2 5.3 5.4 5.5 5.6 5.7 Use of the DMA Resource 6.1 4 ............................................................................................ 45 CPU Register Types .............................................................................................. 46 Use of Floating Point.............................................................................................. 47 TMS320C6xxx Rules and Guidelines...............................................................
6.2 Algorithm and Framework ........................................................................................ 62 6.3 Requirements for the Use of the DMA Resource ............................................................. 63 6.4 Logical Channel 6.5 Data Transfer Properties ......................................................................................... 64 6.6 Data Transfer Synchronization .................................................................................. 64 6.
List of Figures 1-1 1-2 2-1 2-2 3-1 3-2 3-3 3-4 4-1 5-1 6-1 6-2 6 TMS320 DSP Algorithm Standard Elements ........................................................................... DSP Software Architecture................................................................................................ Scratch vs Persistent Memory Allocation ............................................................................... Data Memory Types .....................................................................
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) marketplace for DSP algorithm technology and to significantly reduce the time-to-market for new DSP-based products.
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, contains a complete description of the APIs that an eXpressDSP-compliant algorithm may reference.
Chapter 1 SPRU352G – June 2005 – Revised February 2007 Overview This chapter provides an overview of the TMS320 DSP Algorithm Standard. Topic 1.1 1.2 1.3 1.4 1.5 .................................................................................................. Scope of the Standard ............................................................... Requirements of the Standard ................................................... Goals of the Standard ..........................................................
www.ti.com Scope of the Standard Digital Signal Processors (DSPs) are often programmed like "traditional" embedded microprocessors. That is, they are programmed in a mix of C and assembly language, they directly access hardware peripherals, and, for performance reasons, almost always have little or no standard operating system support. Thus, like traditional microprocessors, there is very little use of commercial off-the-shelf (COTS) software components for DSPs.
www.ti.com 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 architectures. There is always the possibility that deviations from these guidelines will occur, but then the algorithm vendor can explicitly draw attention to the deviation in the relevant documentation or module headers.
www.ti.com Goals of the Standard 1.3 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.
www.ti.com 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 algorithm vendors to provide free evaluations of their technology. It is important to provide mechanisms, such as encryption of the code, that protect the vendor's IP; otherwise, vendors will not make their components readily available.
www.ti.com System Architecture 1.5.2 Algorithms 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.
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 2.1 2.2 2.3 2.4 2.5 2.6 .................................................................................................. Use of C Language .................................................................... Threads and Reentrancy .............................................
www.ti.com 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 an algorithm's memory requirements. 2.1 Use of C Language All algorithms will follow the run-time conventions imposed by the C programming language.
www.ti.com Threads and Reentrancy 2.2.2 Preemptive vs. Non-Preemptive Multitasking 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(), to allow another thread to take control of the CPU or by simply requiring all threads to complete within a specified short period.
www.ti.com 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, however. How can a function maintain state and still be reentrant? Consider the rand() function.
www.ti.com 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 that can be used to make virtually any Code reentrant.
www.ti.com 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 efficiently share this precious resource among algorithm components from one or more third parties. 2.3.
www.ti.com Data Memory Notice that both a() and b() freely use some of the same scratch registers and no saving and restoring of these registers is necessary. This is possible because both functions, a() and b(), agree on the set of scratch registers and that values in these registers are indeterminate at the beginning of each function. By analogy, we partition all memory into two groups: scratch and persistent.
www.ti.com 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 memory (DARAM) is on-chip memory that allows two simultaneous accesses in a single instruction cycle. • Single-access memory (SARAM) is on-chip memory that allows only a single access per instruction cycle.
www.ti.com Program Memory 2.4 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 page size is permitted, however. Rule 4 All algorithm code must be fully relocatable. That is, there can be no hard coded program memory locations.
www.ti.com 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 pointing out that if self-modifying Code is used, it must be done "atomically," i.e., with all interrupts disabled; otherwise this Code would fail to be reentrant. 2.
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 3.1 3.2 3.3 .................................................................................................. Page Interfaces and Modules.............................................................. 26 Algorithms ..........................................................
www.ti.com Interfaces and Modules These rules and guidelines enable many of the benefits normally associated with object-oriented and component-based programming but with little or no overhead. More importantly, these guidelines are necessary to enable two different algorithms to be integrated into a single application without modifying the source Code of the algorithms.
www.ti.com 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 should be employed for assembly language headers. ; ; ======== fir.h54 ======== ; .if ($isdefed("FIR_") = 0) FIR_ .set 1 0 .endif 3.1.
www.ti.com Interfaces and Modules 3.1.2 Naming Conventions 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 to the user must conform to the eXpressDSP naming conventions. Rule 10 All modules must follow the eXpressDSP-compliant naming conventions for those external declarations disclosed to the client.
www.ti.com Interfaces and Modules Figure 3-2. Module Object Creation FIR firObject FIR_Config FIR; FIR_init(); FIR_exit(); FIR_create(); Creates firObject Figure 3-3 illustrates an object appropriate for a finite impulse response filter implemented by a module named FIR. Figure 3-3. Example Module Object Read-only coefficient array FIR firObject Creates FIR_create(); Int length; Int coeff[]; Int delay[]; Filter input history buffer 3.1.
www.ti.com 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 guideline above is intended to cover modules such as those that make up the core run-time support as well as the eXpressDSP-compliant algorithms. 3.1.
www.ti.
www.ti.com 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 functions that are implemented by more than one module in a system.
www.ti.com Algorithms 3.2 Element Description Required struct XYZ_Obj Module's object definition; normally not defined in the module's header.
www.ti.com 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 output section, the linker can be used to eliminate those methods that are unnecessary in systems that do not require run-time object creation.
www.ti.
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: __.1 where is the name of the variant of the module (containing characters from the set[a-z0-9]). Debug variants should have variant names that begin with the characters "debug.
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 4.1 4.2 4.3 4.4 .................................................................................................. Data Memory ............................................................................
www.ti.com 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. There is one important addition, however. It is possible for an algorithm to inadvertently disrupt the scheduling of threads in a system by disabling interrupts for extended periods.
www.ti.com 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 constants; they may be functions of algorithm instance creation parameters. 4.1.
www.ti.com 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's object files is represented by a column.
www.ti.com Interrupt Latency Code 4.3 Code Sections Size a.obj(.text) 768 Align 0 b.obj(.text) 125 32 Interrupt Latency 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 timely a fashion as possible. In particular, algorithms should minimize the time that interrupts are disabled. Ideally, algorithms would never disable interrupts.
www.ti.com Execution Time Figure 4-1. Execution Timeline for Two Periodic Tasks A B 3 ms 3 ms 3 ms 3 ms Idle 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.0000001 ms every 3 ms. Notice that task B will miss its first deadline because task A consumes 2 ms of the available 3 ms of task B's period.
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, placement of specified buffers in dual-access or single access on-chip memory, etc.
www.ti.
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 5.1 5.2 5.3 5.4 5.5 5.6 5.7 .................................................................................................. CPU Register Types .................................................................. Use of Floating Point .................................................................
www.ti.com 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 single system because of incompatible assumptions about the use of specific features of the DSP (e.g., use of overflow mode, use of dedicated registers, etc.).
www.ti.com 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 either never modifying global registers or by disabling interrupts around those sections that modify and restore global registers. 5.
www.ti.com 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 must not require placement in on-chip memory. 5.3.4 Register Conventions This section describes the rules and guidelines that apply to the use of the TMS320C6xxx on-chip registers.
www.ti.com 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 (global) Note that the GIE and PGIE are read-only registers. Algorithms that need to create non-interruptible sections must use the DSP/BIOS operations HWI_disable() and HWI_restore(). They must never directly manipulate the GIE or PGIE bits. 5.3.
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 and all algorithms as far functions (mixed model). When extended program memory allows overlays, the usable program space on each page is reduced.
www.ti.com TMS320C54xx Rules and Guidelines 5.4.3 Register Conventions 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 algorithm; e.g., BSCR, IFR, IMR, and peripheral control and status registers.
www.ti.com 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 control the processor mode and is of type Init.
www.ti.com 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. 5.5.3 Program Models Only the large memory model is supported for the program memory. So there are no special program memory requirements for this processor. Just to reemphasize the point, all the program code must be completely relocatable and must not necessarily require placement in on-chip memory.
www.ti.com 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 the B-bus must be documented as per the Rule 37 as follows: Data section names that are accessed by the B-bus .data .
www.ti.com TMS320C55x Rules and Guidelines 5.5.6 Status Bits The C55xx contains four status registers: ST0, ST1, ST2 and ST3.
www.ti.
www.ti.com TMS320C24xx Guidelines 5.6 TMS320C24xx Guidelines This section describes the rules and guidelines that are specific to the TMS320C24xx family of digital signal processors (DSPs). Note that 24xx here refers to the following DSPs: C240, C241, C242, C243, and C240x. 5.6.
www.ti.com 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 and shift operand Scratch(local) 5.6.5 Status Registers The C24xx contains two status registers: ST0 and ST1. Each status register is further divided into several distinct fields.
www.ti.com TMS320C28x Rules and Guidelines 5.7.2 Program Models 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 necessarily require placement in on-chip memory. 5.7.3 Register Conventions This section describes the rules and guidelines that apply to the use of the TMS320C28x on-chip registers.
www.ti.
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 utilize the DMA resources. Topic .................................................................................................. 6.1 6.2 6.3 6.4 6.5 6.6 6.
www.ti.com 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 operations. This is particularly important for algorithms that process and move large blocks of data; for example, imaging and video algorithms.
www.ti.com 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). 6.3 Requirements for the Use of the DMA Resource Below is a list of requirements for DMA usage in eXpressDSP-compliant algorithms. These requirements will help to clarify the intent of the stated rules and guidelines in this chapter. 1.
www.ti.com Data Transfer Properties Some systems might map each logical channel to a physical channel, while in other systems, several logical channels map to the same physical channel. This mapping is dependent on the particular system and the number of available physical DMA channels. The important point to be made is that these variables are transparent from the algorithm's point of view when working with logical channels. 6.
www.ti.com 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 DMA transfer rate).
www.ti.com 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 below summarizes the section names and their purpose. Section Name Purpose .text:dmaGetChannels Implementation of the IDMA2 or IDMA3 dmaGetChannels method .
www.ti.com 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 maximum number of bytes is 1024. 6.9 Runtime APIs The IDMA2 interface is used to request and grant an algorithm some DMA resources, and also change these resources in real-time.
www.ti.com Submitting DMA Transfer Requests 6.11 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 and invariably use aligned addresses and 32 or 16-bit element sizes as their fundamental type of data transfer.
www.ti.com C6xxx Specific DMA Rules and Guidelines 6.13 C6xxx Specific DMA Rules and Guidelines 6.13.1 Cache Coherency Issues for Algorithm Producers In certain C6000 targets, data that are in both external memory and the L2 cache can cause coherence problems with background DMA transfers in several ways. The figures below depict some memory access scenarios that potentially lead to problems.
www.ti.com 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 cache entries must be invalidated to ensure that they are not cached. For buffers that are modified using CPU accesses, the corresponding cache entries must first be written back to external memory and then invalidated to ensure cache coherency.
www.ti.com Inter-Algorithm Synchronization 6.14.2 Minimizing Logical Channel Reconfiguration Overhead Some common C55x DMA devices impose additional restrictions that affect when a channel needs to be reconfigured. A logical channel needs to be reconfigured when the source or destination addresses refer to different memory ports (SARAM, DARAM, EMIF) compared with the most recently configured channel settings.
www.ti.com Inter-Algorithm Synchronization ÍÍÍ ÍÍÍ ÍÍÍ Algorithm A active CPU context (timeline) 1 ÍÍ ÍÍ ÍÍ ÍÍ 2 3 Algorithm B active 4 5 DMA context (timeline) DMA/CPU idle CPU context switch CPU/DMA active Events 1. Algorithm A requests a data transfer by calling ACPY2_start(). The framework executes this request immediately since the DMA channel is free. 2. Algorithm A calls ACPY2_wait() to wait for the data transfer to complete.
www.ti.com Inter-Algorithm Synchronization • algorithm. Events 1. Algorithm A requests a data transfer by calling ACPY2_start(). The framework executes this request immediately since the DMA channel is free. 2. The framework preempts Algorithm A to run algorithm B. Algorithm A's data transfer is aborted to free the DMA channel to Algorithm B. 3. Algorithm B requests a data transfer by calling ACPY2_start(). The framework executes this request immediately since the DMA channel is free. 4.
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, of course, requires at least one physical channel for each priority level, which might not always be the case.
Appendix A SPRU352G – June 2005 – Revised February 2007 Rules and Guidelines This appendix gathers together all rules and guidelines into one compact reference. Topic A.1 A.2 A.3 A.4 A.5 .................................................................................................. General Rules ........................................................................... Performance Characterization Rules ........................................... DMA Rules ...........................................
www.ti.com 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 enumerate all of the rules and guidelines that must be obeyed by the algorithms and the third section gathers all performance characterization rules. A.
www.ti.com 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 placement in on-chip program memory; i.e., they must properly operate with program memory operated in cache mode. (See Section 5.3.
www.ti.com 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 characterize the average and maximum size of the data transfers per logical channel for each operation.
www.ti.com 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 functions and all algorithms as far functions (mixed model). (See Section 5.4.
www.ti.
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 B.1 B.2 .................................................................................................. Page TI C-Language Run-Time Support Library .................................... 82 DSP/BIOS Run-time Support Library ...........................................
www.ti.com 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. B.1 TI C-Language Run-Time Support Library In the future, this list of allowable APIs will grow to include a rich set of DSP math function calls; e.g., functions for computing a DCT, FFT, dot product, etc.
Appendix C SPRU352G – June 2005 – Revised February 2007 Bibliography This appendix lists sources for additional information. C.1 Books 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. Intermetrics, Mwave Developer's Toolkit, DSP Toolkit User's Guide, 1993. Liu, C.L.; Layland, J.W.
www.ti.
Appendix D SPRU352G – June 2005 – Revised February 2007 Glossary D.1 Glossary of Terms 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 interface is "abstract" because, in general, many modules in a system implement the same abstract interface; i.e., the interface defines abstract operations supported by many modules.
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 in big-endian order, while Intel 80x86, DEC VAX, and DEC Alpha systems store them in little-endian order. Internet standard byte ordering is also big-endian.
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 overwritten without loss; i.e., prior contents need not be saved and restored after each use. Scratch Register — A register that can be overwritten without loss; i.e.
IMPORTANT NOTICE Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications, enhancements, improvements, and other changes to its products and services at any time and to discontinue any product or service without notice. Customers should obtain the latest relevant information before placing orders and should verify that such information is current and complete.
