Related Manuals for Texas Instruments TMS320 DSP
Summary of Contents for Texas Instruments TMS320 DSP
- Page 1 TMS320 DSP Algorithm Standard Rules and Guidelines User's Guide Literature Number: SPRU352G June 2005 – Revised February 2007...
- Page 2 SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback...
-
Page 3: Table Of Contents
Preface Overview Scope of the Standard 1.1.1 Rules and Guidelines Requirements of the Standard Goals of the Standard Intentional Omissions System Architecture 1.5.1 Frameworks 1.5.2 Algorithms 1.5.3 Core Run-Time Support General Programming Guidelines Use of C Language Threads and Reentrancy 2.2.1 Threads 2.2.2... - Page 4 Algorithm Performance Characterization Data Memory 4.1.1 Heap Memory 4.1.2 Stack Memory 4.1.3 Static Local and Global Data Memory Program Memory Interrupt Latency Execution Time 4.4.1 MIPS Is Not Enough 4.4.2 Execution Time Model DSP-Specific Guidelines CPU Register Types Use of Floating Point TMS320C6xxx Rules and Guidelines 5.3.1 Endian Byte Ordering...
- Page 5 Algorithm and Framework Requirements for the Use of the DMA Resource Logical Channel Data Transfer Properties Data Transfer Synchronization Abstract Interface Resource Characterization Runtime APIs 6.10 Strong Ordering of DMA Transfer Requests 6.11 Submitting DMA Transfer Requests 6.12 Device Independent DMA Optimization Guideline 6.13 C6xxx Specific DMA Rules and Guidelines 6.13.1 Cache Coherency Issues for Algorithm Producers...
- Page 6 TMS320 DSP Algorithm Standard Elements DSP Software Architecture Scratch vs Persistent Memory Allocation Data Memory Types Module Interface and Implementation Module Object Creation Example Module Object Example Implementation of IALG Interface Execution Timeline for Two Periodic Tasks Register Types Transfer Properties for a 1-D Frame...
-
Page 7: Preface
Throughout this document, the rules and guidelines of the TMS320 DSP Algorithm Standard (referred to as XDAIS) are highlighted. Rules must be followed to be compliant with the TMS320 DSP Algorithm Standard Guidelines. Guidelines should be obeyed but may be violated by eXpressDSP-compliant software. - Page 8 The TMS320 DSP Algorithm Standard is documented in the following manuals: TMS320 DSP Algorithm Standard Rules and Guidelines (this document). Describes all the rules and guidelines that make up the TMS320 DSP Algorithm Standard (may be referred to as XDAIS throughout this document).
-
Page 9: Overview
This chapter provides an overview of the TMS320 DSP Algorithm Standard. Topic Scope of the Standard Requirements of the Standard Goals of the Standard Intentional Omissions System Architecture SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback SPRU352G – June 2005 – Revised February 2007... -
Page 10: Scope Of The Standard
COTS marketplace for DSP algorithm technology and to significantly reduce the time-to-market for new DSP-based products. Scope of the Standard The TMS320 DSP Algorithm Standard defines three levels of guidelines. Figure 1-1. TMS320 DSP Algorithm Standard Elements General Programming Guidelines... -
Page 11: Rules And Guidelines
1.1.1 Rules and Guidelines The TMS320 DSP Algorithm Standard specifies both rules and guidelines. Rules must be followed in order for software to be eXpressDSP-compliant. Guidelines, on the other hand, are strongly suggested recommendations that should be obeyed, but are not required, in order for software to be eXpressDSP-compliant. -
Page 12: Goals Of The Standard
On the other hand, Jim Gray has been quoted as saying, "There is no performance problem that cannot be solved by eliminating a level of indirection." It is essential that the TMS320 DSP Algorithm Standard remain true to the spirit of the DSP developer: any overhead incurred by adherence to the standard must be minimized. -
Page 13: System Architecture
(i.e., the framework). Thus, it is not possible to easily reuse an algorithm in more than one system. The TMS320 DSP Algorithm Standard is intended to clearly define this line in such a way that performance is not sacrificed and algorithm reusability is significantly enhanced. -
Page 14: Algorithms
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. Algorithms are C callable Algorithms are reentrant Algorithms are independent of any particular I/O peripheral Algorithms are characterized by their memory and MIPS requirements... -
Page 15: General Programming Guidelines
In this chapter, we develop programming guidelines that apply to all algorithms on all DSP architectures, regardless of application area. Topic Use of C Language Threads and Reentrancy Data Memory Program Memory ROM-ability Use of Peripherals SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback SPRU352G –... -
Page 16: Use Of C Language
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. Use of C Language All algorithms will follow the run-time conventions imposed by the C programming language. -
Page 17: Preemptive Vs. Non-Preemptive Multitasking
Thus, the TMS320 DSP Algorithm Standard does not define a framework-neutral "yield" operation for algorithms. -
Page 18: Example
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. -
Page 19: Data Memory
www.ti.com 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. -
Page 20: Memory Spaces
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. -
Page 21: Scratch Vs Persistent Memory Allocation
www.ti.com 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. -
Page 22: Algorithm Versus Application
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. -
Page 23: Program Memory
www.ti.com 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. -
Page 24: 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 pointing out that if self-modifying Code is used, it must be done "atomically,"... -
Page 25: 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 Interfaces and Modules Algorithms Packaging SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback SPRU352G – June 2005 – Revised February 2007 Algorithm Component Model Chapter 3 Page... -
Page 26: Interfaces And Modules
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. -
Page 27: External Identifiers
www.ti.com 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_ #endif /* FIR_ */ A similar technique should be employed for assembly language headers. -
Page 28: Naming Conventions
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. -
Page 29: Design-Time Object Creation
www.ti.com FIR_Config FIR; FIR_init(); FIR_exit(); FIR_create(); Figure 3-3 illustrates an object appropriate for a finite impulse response filter implemented by a module named FIR. FIR_create(); 3.1.5 Design-Time Object Creation Many embedded systems are very static in nature; memory, MIPS, and I/O peripherals are statically partitioned among a fixed set of functions that operate continuously until power is removed. -
Page 30: Module Configuration
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. -
Page 31: Multiple Interface Support
www.ti.com 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 is NULL */ params = &FIR_PARAMS;... -
Page 32: Interface Inheritance
IALG_Fxns structure. This ensures that any G.729 enCoder implementation can be treated as a "generic" eXpressDSP-compliant algorithm. All interfaces (including those not currently part of the TMS320 DSP Algorithm Standard) that extend IALG should employ the same technique. The abstract IFIR interface example defined in the TMS320 DSP Algorithm Standard API Reference illustrates this technique. -
Page 33: Algorithms
The IALG interface is described in detail in Chapter 1 of the TMS320 DSP Algorithm Standard API Reference (SPRU360). Not every mathematical function should be cast as an eXpressDSP-compliant algorithm. In particular, many "traditional"... -
Page 34: Packaging
In this section, we cover the details necessary for a developer to bundle a module into a form that can be delivered into any TMS320 DSP Algorithm Standard development system. It is important to recall that a module's implementation may consist of many object files and at least one C header file. By following these conventions, algorithm developers can be sure that their components can be seamlessly integrated into any TMS320 DSP Algorithm Standard development environment. -
Page 35: Header Files
In order to easily manage the common case of debug and release versions of the same algorithm within a TMS320 DSP Algorithm Standard development environment, it is important to adopt a naming convention that makes it easy to ensure that a eXpressDSP-compliant application is built from a uniform set of components. - Page 36 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 module (containing characters from the set[a-z0-9]). Debug variants should have variant names that begin with the characters "debug."...
-
Page 37: 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 Data Memory Program Memory Interrupt Latency Execution Time SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback SPRU352G –... -
Page 38: Data 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. -
Page 39: Stack Memory
www.ti.com 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. -
Page 40: Program Memory
With the exception of initialized data, it is possible to virtually eliminate all static data in an algorithm using the eXpressDSP-compliant IALG interface. The implementation of interfaces is described in Section 3.2 and a detailed description of the IALG interface is provided in the TMS320 DSP Algorithm Standard API Reference. -
Page 41: Interrupt Latency
www.ti.com Code Sections a.obj(.text) b.obj(.text) 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. -
Page 42: Execution Time Model
Execution Time Figure 4-1. Execution Timeline for Two Periodic Tasks 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. - Page 43 www.ti.com 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.
- Page 44 www.ti.com Algorithm Performance Characterization SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback...
-
Page 45: Dsp-Specific Guidelines
This chapter provides guidelines for creating eXpressDSP-compliant algorithms for various DSP families. Topic CPU Register Types Use of Floating Point TMS320C6xxx Rules and Guidelines TMS320C54xx Rules and Guidelines TMS320C55x Rules and Guidelines TMS320C24xx Guidelines TMS320C28x Rules and Guidelines SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback SPRU352G –... -
Page 46: Cpu Register Types
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.). -
Page 47: Use Of Floating Point
www.ti.com 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. -
Page 48: Register Conventions
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. -
Page 49: Interrupt Latency
www.ti.com CSR Field PWRD 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.6 Interrupt Latency Although there are no additional rules for C6x algorithms that deal with interrupt latency, it is important to note that all instructions in the delay slots of branches are non-interruptible;... - Page 50 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).
-
Page 51: Register Conventions
www.ti.com 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. -
Page 52: Interrupt Latency
TMS320C55x Rules and Guidelines ST1 Field Name INTM The PMST register is used to control the processor mode and is of type Init. PMST Field Name AVIS CLKOFF DROM IPTR MP/MC OVLY SMUL 5.4.5 Interrupt Latency Although there are no additional rules for C54x algorithms that deal with interrupt latency, it is important to note that all RPT and RPTZ loops are non-interruptible;... -
Page 53: Program Models
www.ti.com 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. -
Page 54: 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. -
Page 55: Status Bits
www.ti.com 5.5.6 Status Bits The C55xx contains four status registers: ST0, ST1, ST2 and ST3. ST0 Field Name ACOV2 ACOV3 TC1, TC2 ACOV0 ACOV1 DP bits (15 to 7) The following table gives the attributes for the ST1 register fields. ST1 Field Name BRAF CPL=1... - Page 56 TMS320C55x Rules and Guidelines ST3 Field Name HOMY HOMX HOMR HOMP CBERR MPNMC SATA=0 AVIS CLKOFF SMUL=0 DSP-Specific Guidelines Host only access mode Host only access mode Shared access mode Host only access mode - peripherals CPU bus error Microprocessor / Microcomputer mode Saturation control bit for A-unit Address visibility bit CLKOUT disable bit...
-
Page 57: Tms320C24Xx Guidelines
DCS Components) must also fully adhere to the rules and guidelines as described within this document and the TMS320 DSP Algorithm Standard API Reference. 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.”... -
Page 58: Status Registers
TMS320C28x Rules and Guidelines Register AR6 - AR7 Accumulator 5.6.5 Status Registers The C24xx contains two status registers: ST0 and ST1. Each status register is further divided into several distinct fields. Although each field is often thought of as a separate register, it is not possible to access these fields individually. -
Page 59: Program Models
www.ti.com 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. -
Page 60: Interrupt Latency
TMS320C28x Rules and Guidelines ST1 Field Name M0M1MAP OBJMODE AMODE IDLESTAT EALLOW LOOP VMAP PAGE0 DBGM INTM 5.7.5 Interrupt Latency The TMS320C28x CPU has only one non-interruptible loop instruction, namely RPT. Once started, the RPT instruction blocks interrupts until the entire number of repeats are completed. Thus, the length of these loops can have significant effect on the worst case interrupt latency of an algorithm DSP-Specific Guidelines Auxiliary register pointer... -
Page 61: 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 Overview Algorithm and Framework Requirements for the Use of the DMA Resource... -
Page 62: Overview
DSP Algorithm Standard through the addition of rules and two standard interfaces: IDMA and ACPY. Starting with the TMS320 DSP Algorithm Standard Rules and Guidelines, revision SPRU352E, and the TMS320 DSP Algorithm Standard API Reference, revision SPRU360C, we introduce additional DMA Rules and Guidelines and new enhanced interfaces, IDMA2 along with ACPY2 for C64x and C5000 devices and IDMA3 for C64x+ devices, which deprecate the original IDMA and ACPY interfaces. -
Page 63: Requirements For The Use Of The Dma Resource
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). 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. -
Page 64: Data Transfer Properties
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. -
Page 65: Abstract Interface
www.ti.com 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). -
Page 66: 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 below summarizes the section names and their purpose. -
Page 67: Runtime Apis
It is important to notice that the algorithm's client is free to implement these APIs as appropriate, granted that they satisfy their semantics in the TMS320 DSP Algorithm Standard API Reference (SPRU360). The IDMA3 interface which is required to be implemented by algorithms that use the C64x+ EDMA3 controller, can be optionally associated with a custom IDMA3 protocol. -
Page 68: Submitting Dma Transfer Requests
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. -
Page 69: C6Xxx Specific Dma Rules And Guidelines
www.ti.com 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. -
Page 70: C55X Specific Dma Rules And Guidelines
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. -
Page 71: Minimizing Logical Channel Reconfiguration Overhead
www.ti.com 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. -
Page 72: Preemptive System
Inter-Algorithm Synchronization CPU context (timeline) DMA context (timeline) Í Í Í Í DMA/CPU idle Í Í CPU context switch Í Í CPU/DMA active Events 1. Algorithm A requests a data transfer by calling immediately since the DMA channel is free. 2. - Page 73 www.ti.com algorithm. Events 1. Algorithm A requests a data transfer by calling 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.
- Page 74 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 course, requires at least one physical channel for each priority level, which might not always be the case.
-
Page 75: Rules And Guidelines
This appendix gathers together all rules and guidelines into one compact reference. Topic General Rules Performance Characterization Rules DMA Rules General Guidelines DMA Guidelines SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback SPRU352G – June 2005 – Revised February 2007 Rules and Guidelines Appendix A Page... -
Page 76: 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 enumerate all of the rules and guidelines that must be obeyed by the algorithms and the third section gathers all performance characterization rules. -
Page 77: Performance Characterization Rules
www.ti.com Rule 25 — All C6x algorithms must be supplied in little-endian format. (See Rule 26 — All C6x algorithms must access all static and global data as far data. (See 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. -
Page 78: General Guidelines
General Guidelines DMA Rule 3 — Each of the IDMA2 methods implemented by an algorithm must be independently relocateable. (See Section DMA Rule 4 — All algorithms must state the maximum number of concurrent DMA transfers for each logical channel. (See DMA Rule 5 —... -
Page 79: Dma Guidelines
www.ti.com 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). - Page 80 www.ti.com Rules and Guidelines SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback...
-
Page 81: Core Run-Time Apis
This appendix enumerates all acceptable core run-time APIs that may be referenced by an eXpressDSP-compliant algorithm. Topic TI C-Language Run-Time Support Library DSP/BIOS Run-time Support Library SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback Appendix B SPRU352G – June 2005 – Revised February 2007 Core Run-Time APIs Page Core Run-Time APIs... -
Page 82: Ti C-Language 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. 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. -
Page 83: C Bibliography
Massey, Tim and Iyer, Ramesh. DSP Solutions for Telephony and Data/Facimile Modems, SPRA073, 1997. Texas Instruments, TMS320C54x Optimizing C Compiler User's Guide, SPRU103C, 1998. Texas Instruments, TMS320C6x Optimizing C Compiler User's Guide, SPRU187C, 1998. Texas Instruments, TMS320C62xx CPU and Instruction Set, SPRU189B, 1997. - Page 84 www.ti.com Bibliography SPRU352G – June 2005 – Revised February 2007 Submit Documentation Feedback...
-
Page 85: D Glossary
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;... - Page 86 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.
- Page 87 www.ti.com 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.
- Page 88 TI product or service and is an unfair and deceptive business practice. TI is not responsible or liable for any such statements. Following are URLs where you can obtain information on other Texas Instruments products and application solutions:...