Texas Instruments TMS320 DSP manual Overview, Algorithm and Framework

Page 62

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. The DMA is designed for this exact purpose and algorithms need to gain access to this resource for performance reasons.

The purpose of this chapter is to outline a model to facilitate the use of the DMA resources for eXpressDSP-compliant algorithms. The support for DMA has been originally introduced to the TMS320 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.

Algorithms that have already been developed using the deprecated IDMA and ACPY APIs remain eXpressDSP-compliant; however, development of new algorithms should follow the new IDMA2/ACPY2 specification for accessing DMA resources on the C64x and C5000 devices and the IDMA3 specification for accessing resources from the C64x+ EDMA3 controller.

This chapter references runtime APIs (IDMA2/IDMA3 and ACPY2) that grant algorithms framework-controlled access to DMA resources. A detailed description of these APIs can be found in the TMS320 DSP Algorithm Standard API Reference (SPRU360).

6.1Overview

This chapter specifies rules and guidelines to facilitate the use of the DMA resources for algorithms. For an algorithm to utilize the DMA resources, the rules outlined in this chapter must be followed in order to be considered eXpressDSP-compliant. These guidelines are strongly suggested recommendations.

6.2Algorithm and Framework

The algorithm standard looks upon algorithms as pure "data transducers." They are, among other things, not allowed to perform any operations that can affect scheduling or memory management. All these operations must be controlled by the framework to ensure easy integration of algorithms, possibly from different vendors. In general, the framework must be in command of managing the system resources, including the DMA resource.

Algorithms cannot access the DMA registers directly, nor can they be written to work with a particular physical DMA channel only. The framework must have the freedom to assign any available channel, and possibly share DMA channels, when granting an algorithm a DMA resource.

While Rule 6 prevents eXpressDSP-compliant algorithms from directly accessing or controlling the hardware peripherals, they can access DMA hardware via "logical" DMA channels they request and receive from the client application using the standard IDMA interfaces. Algorithms submit DMA transfer requests to a logical channel using the ACPY2 API functions provided by the client application when using IDMA2 i nterfaces and custom DMA access protocol when using IDMA3 interfaces.

IDMA2. All algorithms that use the C64x and C5000 DMA resources must implement the IDMA2 interface. This interface allows the algorithm to request and receive "logical" DMA resources. It is similar to the IALG interface, which is used to request and grant memory needed by an algorithm.

IDMA3. All algorithms that use the C64x+ EDMA resources must implement the IDMA3 interface. This interface allows the algorithm to request and receive “logical”DMA resources. It is similar to the IDMA2 interface in terms of its definition and role, but exposes some physical EDMA3 resources: Parameter RAM Sets (PaRAMs), Transfer Completion Codes (TCCs), and QDMA Channel ids.

ACPY2. These functions are implemented as part of the client application and called by the algorithm (and possibly the client application). A client application must implement the ACPY2 interface (or integrate a provided ACPY2 interface) in order to use algorithms that use the DMA resource. The ACPY2 interface describes the comprehensive list of DMA operations an algorithm can perform

62

Use of the DMA Resource

SPRU352G –June 2005 –Revised February 2007

Image 62
Contents Users Guide Rules and GuidelinesSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Document Overview Read This FirstIntended Audience Rule n Related DocumentationText Conventions Guideline nOverview Scope of the Standard Rules for TMS320C5x Rules for TMS320C6xRules and Guidelines Requirements of the StandardGoals of the Standard Intentional OmissionsSystem Architecture FrameworksAlgorithms Core Run-Time SupportGeneral Programming Guidelines Threads Use of C LanguageThreads and Reentrancy RulePreemptive vs. Non-Preemptive Multitasking ReentrancyExample Data Memory Data MemoryMemory Spaces Scratch versus PersistentScratch vs Persistent Memory Allocation Algorithm versus Application GuidelineSection Name Purpose Program MemoryROM-ability Use of Peripherals Use of PeripheralsAlgorithm Component Model Interfaces and Modules Algorithms PackagingInterfaces and Modules Implementation Fir.hExternal Identifiers Module Instance Objects Naming ConventionsModule Initialization and Finalization Design-Time Object Creation Run-Time Object Creation and DeletionModule Configuration Example ModuleMultiple Interface Support Element Interface InheritanceSummary Description RequiredAlgorithms AlgorithmsPackaging Object CodeHeader Files Debug Verses ReleaseModuleversvendorvariant.1arch Algorithm Performance Characterization Data Memory Program Memory Interrupt Latency Execution TimeSize Heap MemoryExternal Stack Memory Static Local and Global Data MemoryData Bss Object files Size Mips Is Not Enough Interrupt LatencyExecution Time OperationExecution Time Model Execution Timeline for Two Periodic Tasks59000 198000 Process198000 Submit Documentation Feedback DSP-Specific Guidelines CPU Register Types Register TypesEndian Byte Ordering Use of Floating PointTMS320C6xxx Rules and Guidelines Data ModelsRegister Use Type Register ConventionsStatus Register CSR Field Use TypeProgram Models Interrupt LatencyTMS320C54xx Rules and Guidelines TMS320C54xx Rules and Guidelines ST1 Field Name Use Type Status RegistersST0 Field Name Use Type Pmst Field Name Use Type TMS320C55x Rules and GuidelinesStack Architecture Relocatability ExampleSSP ST3 Field Name Use Type Status BitsST2 Field Name Use Type Homy TMS320C24xx Guidelines GeneralTMS320C28x Rules and Guidelines TMS320C28x Rules and GuidelinesXAR0 M0M1MAP Use of the DMA Resource Submitting DMA Transfer RequestsOverview Algorithm and FrameworkRequirements for the Use of the DMA Resource Logical ChannelData Transfer Properties Data Transfer SynchronizationDMA Rule Abstract InterfaceDMA Guideline Average Maximum Resource CharacterizationData Transfers bytes Frequency Runtime APIs Strong Ordering of DMA Transfer RequestsSubmitting DMA Transfer Requests Device Independent DMA Optimization GuidelineCache Coherency Issues for Algorithm Producers 13 C6xxx Specific DMA Rules and GuidelinesSupporting Packed/Burst Mode DMA Transfers 14 C55x Specific DMA Rules and GuidelinesInter-Algorithm Synchronization Minimizing Logical Channel Reconfiguration OverheadAddressing Automatic Endianism Conversion Issues Non-Preemptive SystemPreemptive System Algorithm B Algorithm a Inter-Algorithm Synchronization Appendix a General Rules Performance Characterization Rules DMA RulesGeneral Guidelines DMA Guidelines Submit Documentation Feedback DSP/BIOS Run-time Support Library Core Run-Time APIsDSP/BIOS Run-time Support Library TI C-Language Run-Time Support LibraryBibliography BooksSubmit Documentation Feedback Glossary Glossary of TermsGlossary of Terms Glossary of Terms Important Notice