Texas Instruments TMS320 DSP manual Requirements for the Use of the DMA Resource, Logical Channel

Page 63

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.3Requirements 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.All physical DMA resources must be owned and managed by the framework.

2.Algorithms must access the DMA resource through a handle representing a logical DMA channel abstraction. These handles are granted to the algorithm by the framework using a standard IDMA interface.

3.A mechanism must be provided so that algorithms can ensure completion of data transfer(s).

4.The DMA scheme must work within a preemptive environment.

5.It must be possible for an algorithm to request multiframe data transfers (two-dimensional data transfers).

6.The framework must be able to obtain the worst-case DMA resource requirements at algorithm initialization time.

7.The DMA scheme must be flexible enough to fit within static and dynamic systems, and systems with a mix of static and dynamic features.

8.All DMA operations must complete prior to return to caller. The algorithm must synchronize all DMA operations before return to the caller from a framework-callable operation.

9.It must be possible for several algorithms to share a physical DMA channel.

6.4Logical Channel

DSP algorithms, depending on the type of algorithm and the execution flow of the algorithm, might schedule the use of the DMA resource in different ways. For example:

∙ An algorithm might need to do a DMA transfer based on results after decoding an encoded bit stream. The results from these calculations determine the source, destination, and configuration of a DMA data transfer. All this information must be passed to the DMA device to start the data transfer. This type of data transfer is data dependent, and its configuration must therefore be determined on-the-fly.

∙ An algorithm might schedule a fixed number of DMA data transfers into its program flow and the configuration of these transfers might be the same. It is only necessary to provide the source and destination information to execute these data transfers, since the configuration is fixed. This type of data transfer is not data-dependent; its configuration can be predetermined.

∙ Some algorithms might have a mixture of the above scenarios. These algorithms have some predetermined data transfers and some data dependent data transfers.

When using the IDMA interfaces, a DMA handle is granted to the algorithm by the framework during initialization. This handle can be further utilized by the ACPY2 APIs used by IDMA2 or custom protocols used by IDMA3, to configure, request and synchronize the data transfers

The term "logical channel" is associated with each DMA handle that the framework provides to the algorithm and represents an abstraction for a dedicated" private DMA channel. The algorithm owns the logical channel it receives. The algorithm uses the channel handles to configure the channel DMA transfer settings, submit asychronous DMA transfer requests, and query and synchronize with the completion status of scheduled transfers. The logical channel retains its state and applies the most recent configuration settings when scheduling a transfer. The channel configuration determines, for example, the size of the elements and the number of frames in multiframe transfers. A data transfer description is complete when the source and destination information and the frame length are added to the logical channel'sconfiguration.

The logical channel concept can be used intelligently by the algorithm designer to optimize the algorithm's performance. For example, algorithms with data transfers using the same configuration may request one logical channel for all these transfers. This logical channel does not need to be configured for each transfer. Furthermore, the algorithm may request another logical channel for the data-dependent transfers. This logical channel must be configured for each transfer.

SPRU352G –June 2005 –Revised February 2007

Use of the DMA Resource

63

Page 62 Page 64
Image 63
Page 62 Page 64
Contents Rules and Guidelines Users GuideSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Read This First Intended AudienceDocument Overview Guideline n Related DocumentationText Conventions Rule nOverview Rules for TMS320C5x Rules for TMS320C6x Scope of the StandardRequirements of the Standard Rules and GuidelinesIntentional Omissions Goals of the StandardFrameworks System ArchitectureCore Run-Time Support AlgorithmsGeneral Programming Guidelines Rule Use of C LanguageThreads and Reentrancy ThreadsReentrancy Preemptive vs. Non-Preemptive MultitaskingExample Data Memory Data MemoryScratch versus Persistent Memory SpacesScratch vs Persistent Memory Allocation Guideline Algorithm versus ApplicationProgram Memory ROM-abilitySection Name Purpose Use of Peripherals Use of PeripheralsInterfaces and Modules Algorithms Packaging Algorithm Component ModelImplementation Fir.h Interfaces and ModulesExternal Identifiers Naming Conventions Module Initialization and FinalizationModule Instance Objects Run-Time Object Creation and Deletion Design-Time Object CreationExample Module Module ConfigurationMultiple Interface Support Description Required Interface InheritanceSummary ElementAlgorithms AlgorithmsObject Code PackagingDebug Verses Release Header FilesModuleversvendorvariant.1arch Data Memory Program Memory Interrupt Latency Execution Time Algorithm Performance CharacterizationHeap Memory ExternalSize Static Local and Global Data Memory Stack MemoryData Bss Object files Size Operation Interrupt LatencyExecution Time Mips Is Not EnoughExecution Timeline for Two Periodic Tasks Execution Time ModelProcess 19800059000 198000 Submit Documentation Feedback DSP-Specific Guidelines Register Types CPU Register TypesData Models Use of Floating PointTMS320C6xxx Rules and Guidelines Endian Byte OrderingCSR Field Use Type Register ConventionsStatus Register Register Use TypeInterrupt Latency TMS320C54xx Rules and GuidelinesProgram Models TMS320C54xx Rules and Guidelines Status Registers ST0 Field Name Use TypeST1 Field Name Use Type TMS320C55x Rules and Guidelines Stack ArchitecturePmst Field Name Use Type Example RelocatabilitySSP Status Bits ST2 Field Name Use TypeST3 Field Name Use Type Homy General TMS320C24xx GuidelinesTMS320C28x Rules and Guidelines TMS320C28x Rules and GuidelinesXAR0 M0M1MAP Submitting DMA Transfer Requests Use of the DMA ResourceAlgorithm and Framework OverviewLogical Channel Requirements for the Use of the DMA ResourceData Transfer Synchronization Data Transfer PropertiesAbstract Interface DMA GuidelineDMA Rule Resource Characterization Data Transfers bytes FrequencyAverage Maximum Strong Ordering of DMA Transfer Requests Runtime APIsDevice Independent DMA Optimization Guideline Submitting DMA Transfer Requests13 C6xxx Specific DMA Rules and Guidelines Cache Coherency Issues for Algorithm Producers14 C55x Specific DMA Rules and Guidelines Supporting Packed/Burst Mode DMA TransfersNon-Preemptive System Minimizing Logical Channel Reconfiguration OverheadAddressing Automatic Endianism Conversion Issues Inter-Algorithm SynchronizationPreemptive System Algorithm B Algorithm a Inter-Algorithm Synchronization Appendix a General Rules DMA Rules Performance Characterization RulesGeneral Guidelines DMA Guidelines Submit Documentation Feedback Core Run-Time APIs DSP/BIOS Run-time Support LibraryTI C-Language Run-Time Support Library DSP/BIOS Run-time Support LibraryBooks BibliographySubmit Documentation Feedback Glossary of Terms GlossaryGlossary of Terms Glossary of Terms Important Notice
Top Page Image Contents