Computer Hardware Algorithm Standard User's Guide
Table Of Contents
- Table of Contents
- Preface
- 1 Overview
- 2 General Programming Guidelines
- 3 Algorithm Component Model
- 3.1 Interfaces and Modules
- 3.1.1 External Identifiers
- 3.1.2 Naming Conventions
- 3.1.3 Module Initialization and Finalization
- 3.1.4 Module Instance Objects
- 3.1.5 Design-Time Object Creation
- 3.1.6 Run-Time Object Creation and Deletion
- 3.1.7 Module Configuration
- 3.1.8 Example Module
- 3.1.9 Multiple Interface Support
- 3.1.10 Interface Inheritance
- 3.1.11 Summary
- 3.2 Algorithms
- 3.3 Packaging
- 3.1 Interfaces and Modules
- 4 Algorithm Performance Characterization
- 5 DSP-Specific Guidelines
- 6 Use of the DMA Resource
- 6.1 Overview
- 6.2 Algorithm and Framework
- 6.3 Requirements for the Use of the DMA Resource
- 6.4 Logical Channel
- 6.5 Data Transfer Properties
- 6.6 Data Transfer Synchronization
- 6.7 Abstract Interface
- 6.8 Resource Characterization
- 6.9 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.14 C55x Specific DMA Rules and Guidelines
- 6.15 Inter-Algorithm Synchronization
- A Rules and Guidelines
- B Core Run-Time APIs
- C Bibliography
- D Glossary
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 (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.
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; i.e., once fetched, interrupts
are blocked until the branch completes. Since these delay slots may contain other branch instructions,
care must be taken to avoid long chains of non-interruptible instructions. In particular, tightly coded loops
often result in unacceptably long non-interruptible sequences.
Note that the C compiler has options to limit the duration of loops. Even if this option is used, you must be
careful to limit the length of loops whose length is not a simple constant.
This section describes the rules and guidelines that are specific to the TMS320C5400 family of DSPs.
The C54x has just one data model, so there are no special data memory requirements for this processor.
Some variants of the TMS320C54xx support an extended program address space. Since code can be
compiled for either standard or extended (near or far) addresses, it is possible to have incompatible
mixtures of code.
We need to ensure that calls made from an algorithm to external support functions will be compatible, and
that calls made from the application to an algorithm will be compatible. We also need to ensure that calls
to independently relocatable object modules within an algorithm will be compatible.
Rule 28
On processors that support large program model compilation, all function accesses to independently
relocatable object modules must be far references. For example, intersection function references within
algorithm and external function references to other eXpressDSP-compliant modules must be far on the
C54x; i.e., the calling function must push both the XPC and the current PC.
Rule 29
On processors that support large program model compilation, all independently relocatable object
module functions must be declared as far functions; for example, on the C54x, callers must push both
the XPC and the current PC and the algorithm functions must perform a far return.
This requires that the top-level interface to the algorithm functions be declared as "far." Note that function
calls within the algorithm may be near calls. Still, calls within the algorithm to independently relocatable
object modules must be far calls, since any relocatable object module may be loaded in a 'far' page of
memory.
What about existing applications that do not support far calls to algorithms? Note that it is possible for an
existing application to do a near call into a far algorithm; create a small "near stub" that the application
calls using a near call, the stub then does the appropriate far call and a near return to the application.
SPRU352G – June 2005 – Revised February 2007 DSP-Specific Guidelines 49
Submit Documentation Feedback