Summary of the content on the page No. 1
TMS320 DSP Algorithm Standard
Rules and Guidelines
User's Guide
Literature Number: SPRU352G
June 2005–Revised February 2007
Summary of the content on the page No. 2
2 SPRU352G–June 2005–Revised February 2007 Submit Documentation Feedback
Summary of the content on the page No. 3
Contents Preface ............................................................................................................................... 7 1 Overview ................................................................................................................... 9 1.1 Scope of the Standard............................................................................................ 10 1.1.1 Rules and Guidelines ............................................................................
Summary of the content on the page No. 4
4 Algorithm Performance Characterization ..................................................................... 37 4.1 Data Memory....................................................................................................... 38 4.1.1 Heap Memory............................................................................................. 38 4.1.2 Stack Memory ............................................................................................ 39 4.1.3 Static Local and Global Data
Summary of the content on the page No. 5
6.2 Algorithm and Framework........................................................................................ 62 6.3 Requirements for the Use of the DMA Resource ............................................................. 63 6.4 Logical Channel ................................................................................................... 63 6.5 Data Transfer Properties ......................................................................................... 64 6.6 Data Transfer Sync
Summary of the content on the page No. 6
List of Figures 1-1 TMS320 DSP Algorithm Standard Elements ........................................................................... 10 1-2 DSP Software Architecture................................................................................................ 13 2-1 Scratch vs Persistent Memory Allocation ............................................................................... 21 2-2 Data Memory Types ....................................................................................
Summary of the content on the page No. 7
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. The TMS320 DSP Algorithm Standard is part of TI's
Summary of the content on the page No. 8
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. Related Documentation The TMS320 DSP Algorithm Standard is documente
Summary of the content on the page No. 9
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 Requirements of the Standard ................................................... 11 1.3 Goals of the Standard....................................................
Summary of the content on the page No. 10
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. However, unlike general-purpose
Summary of the content on the page No. 11
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 h
Summary of the content on the page No. 12
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. • Easy to adhere to the standard • Possible to verify conformance to standard • Enable system integrators to easily migrate between TI DSPs • Enable host tools to simplify a system integrator's
Summary of the content on the page No. 13
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. Each algorithm component i
Summary of the content on the page No. 14
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. • 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 In approximately half of the frameworks
Summary of the content on the page No. 15
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 Language.................................................................... 16 2.2 Threads and Reentrancy...................................................
Summary of the content on the page No. 16
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. This ensures that the system integrator is free to use C to "bi
Summary of the content on the page No. 17
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. In a non-preemptive multi-threadi
Summary of the content on the page No. 18
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. Perhaps a better example is a function with state that protects that state by disabling scheduling around its crit
Summary of the content on the page No. 19
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. One simply defines a "state object" as one that contains all of the state necessary for the algorithm; a pointer t
Summary of the content on the page No. 20
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.1 Memory Spaces In an ideal DSP, there would be an unlimited amount of on-chip memory and algorithms would
