Texas Instruments TMS320 DSP manual Abstract Interface, DMA Guideline, DMA Rule

Page 65

www.ti.com

Abstract Interface

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). However, since it is important that the data transfer completes before accessing the data to ensure accurate execution of the algorithm, we have provided two ways to synchronize the methods of transfer and data access.

∙The algorithm can call the ACPY2_complete() runtime API to check if all data transfers on a particular logical channel have completed.

∙The algorithm can call the ACPY2_wait() runtime API to wait for all data transfers on a particular logical channel to complete. When using the ACPY2 library with IDMA2 interfaces, the algorithms can call the ACPY2_complete() runtime API to check if all data transfers on a particular logical channel have completed

After an algorithm returns to the caller from a framework-callable function, the client of the algorithm is free to move all its memory to a different location and share its scratch memory following the rules in the IALG interface. It is important that data transfers do not occur across functions that can be called by the client to avoid a situation where the DMA is transferring data and the framework is moving the locations of the buffers at the same time.

DMA Rule 1

All data transfer must be completed before return to caller.

When using the ACPY2 library, the algorithm can use the ACPY2_complete() or ACPY2_wait() APIs to ensure that all data transfers have completed before returning to the caller.

For example, an algorithm can not start a data transfer in algActivate() by calling ACPY2_start() or ACPY2_startAligned() and then check for completion of the data transfer in the algorithm's"process" function by calling ACPY2_complete(), or wait for the completion by calling ACPY2_wait().The algorithm must ensure the data transfer is complete in aalgActivate() by using either the ACPY2_complete() or the ACPY2_wait() API.

Note: Similar to the above-mentioned ACPY2 APIs, the ACPY3 library mentioned in Using DMA with Framework Components for C64x+ (SPRAAG1) can be used by algorithms that implement the IDMA3 interfaces, to request DMA services from the C64x+ EDMA3 controller. However, unlike the ACPY2 library, the use of the ACPY3 library is NOT mandatory with the IDMA3 interfaces.

6.7Abstract Interface

eXpressDSP-compliant algorithms are modules that implement the abstract interface IALG. Algorithms that want to utilize the DMA resource must implement the abstract interface IDMA2 or IDMA3. This means that the module must declare and initialize a structure of type IDMA2_Fxns, the structure must have a global scope, its name must follow the uniform naming conventions, and the structure must be declared in the header file included with the module'slibrary.

The algorithm producer implements the IDMA2 or IDMA3 interface to declare the algorithm'sDMA resource requirement. The algorithm'sclient calls this interface to get the resource requirement, grant resources, and change resources at runtime.

DMA Rule 2

All algorithms using the DMA resource must implement the IDMA2 or IDMA3 interface.

All eXpressDSP-compliant algorithms support both run-time and design-time creation of algorithm objects. To optimize with regards to code space for design-time object creation, it is important that all methods defined by the IDMA2 or IDMA3 interface are independently relocatable.

SPRU352G –June 2005 –Revised February 2007

Use of the DMA Resource

65

Page 64 Page 66
Image 65
Page 64 Page 66
Contents Rules and Guidelines Users GuideSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Document Overview Read This FirstIntended Audience Text Conventions Related DocumentationRule n Guideline 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 Threads and Reentrancy Use of C LanguageThreads RuleReentrancy Preemptive vs. Non-Preemptive MultitaskingExample Data Memory Data MemoryScratch versus Persistent Memory SpacesScratch vs Persistent Memory Allocation Guideline Algorithm versus ApplicationSection Name Purpose Program MemoryROM-ability Use of Peripherals Use of PeripheralsInterfaces and Modules Algorithms Packaging Algorithm Component ModelImplementation Fir.h Interfaces and ModulesExternal Identifiers Module Instance Objects Naming ConventionsModule Initialization and Finalization Run-Time Object Creation and Deletion Design-Time Object CreationExample Module Module ConfigurationMultiple Interface Support Summary Interface InheritanceElement Description RequiredAlgorithms AlgorithmsObject Code PackagingDebug Verses Release Header FilesModuleversvendorvariant.1arch Data Memory Program Memory Interrupt Latency Execution Time Algorithm Performance CharacterizationSize Heap MemoryExternal Static Local and Global Data Memory Stack MemoryData Bss Object files Size Execution Time Interrupt LatencyMips Is Not Enough OperationExecution Timeline for Two Periodic Tasks Execution Time Model59000 198000 Process198000 Submit Documentation Feedback DSP-Specific Guidelines Register Types CPU Register TypesTMS320C6xxx Rules and Guidelines Use of Floating PointEndian Byte Ordering Data ModelsStatus Register Register ConventionsRegister Use Type 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 Example RelocatabilitySSP ST3 Field Name Use Type Status BitsST2 Field Name Use Type Homy General TMS320C24xx GuidelinesTMS320C28x Rules and Guidelines TMS320C28x Rules and GuidelinesXAR0 M0M1MAP Submitting DMA Transfer Requests Use of the DMA Resource Algorithm and Framework OverviewLogical Channel Requirements for the Use of the DMA ResourceData Transfer Synchronization Data Transfer PropertiesDMA Rule Abstract InterfaceDMA Guideline Average Maximum Resource CharacterizationData Transfers bytes Frequency 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 TransfersAddressing Automatic Endianism Conversion Issues Minimizing Logical Channel Reconfiguration OverheadInter-Algorithm Synchronization Non-Preemptive SystemPreemptive 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