Texas Instruments TMS320 DSP manual Runtime APIs, Strong Ordering of DMA Transfer Requests

www.ti.com

Runtime APIs

For example, in the table above, the "process" operation is using two logical channels. On logical channel 0, it performs on average 5 data transfers and a maximum of 7 data transfers. The average number of bytes for each transfer is 768, and the maximum number of bytes is 1024.

6.9Runtime APIs

The IDMA2 interface is used to request and grant an algorithm some DMA resources, and also change these resources in real-time. We also need to define runtime APIs that are actually called from within the algorithm to configure the logical channel, start a data transfer and synchronize the data transfer(s).

The following APCY2 APIs are allowed to be called from within an algorithm that has implemented the IDMA2.

Configuration:

ACPY2_configure (), ACPY2_setSrcFrameIndex,ACPY2_setDstFrameIndex, ACPY2_setNumFrames

Synchronization: ACPY2_complete(), ACPY2_wait()

Scheduling: ACPY2_start (), ACPY2_startAligned()

It is important to notice that the algorithm'sclient is free to implement these APIs as appropriate, granted that they satisfy their semantics in the TMS320 DSP Algorithm Standard API Reference (SPRU360).

The IDMA3 interface which is required to be implemented by algorithms that use the C64x+ EDMA3 controller, can be optionally associated with a custom IDMA3 protocol. When a non-null protocol object is provided, the DMA resource manager uses IDMA3_Protocol functions to perform additional memory allocation for the logical DMA channel’s environment field or to call protocol-specific, handle initialization and de-initialization functions. This feature allows frameworks to support custom DMA service function libraries with custom initialization and finalization functions.

The ACPY3 library is an example of such a custom DMA library that is similar to the ACPY2 library in its role and definition. However, it provides a much lower level of abstraction compared to the ACPY2 interface; it is designed to target EDMA3.0/QDMA, while ACPY2 provides a generic DMA abstraction layer. Details of the ACPY3 library can be found in Using DMA with Framework Components for C64x+ (SPRAAG1). Use of the ACPY3 library is not mandatory when using the IDMA3 interfaces; algorithms are free to use their own DMA functions to program the physical DMA resources acquired through the IDMA3 protocol.

6.10 Strong Ordering of DMA Transfer Requests

An important enhancement that was introduced through the ACPY2 APIs over the deprecated ACPY APIs is the strict FIFO ordering property of DMA transfers submitted by an algorithm on a logical DMA channel. Often algorithms need to issue back-to-back DMA transfers from and into the same data region and they can take advantage of the FIFO property. For example, an algorithm can schedule a transfer to copy out the result stored in a buffer used by an in-place computation phase, and immediately schedule a transfer to bring in the next set of input data into the same buffer for the next round of processing. Without the strong ordering property, an ACPY2_wait() synchronization call would be needed prior to submitting the second transfer request. This additional synchronization is needed to prevent the incoming (next round's) input data from corrupting the current output that is potentially still being copied out. The strong ordering guarantee ensures that the second transfer will not start until after the first transfer finishes. This leads to two levels of optimizations.

The extra ACPY2_wait() call/synchronization overhead is eliminated, but even more importantly, the algorithm can now continue to perform other tasks (e.g., process some other buffer, etc.) until it absolutely needs to synchronize with the completion of the second transfer.

Another related ACPY2 enhancement is the introduction of the concept of a serializer (QueueID) property for logical channels. A common QueueID extends the strong FIFO ordering property to all transfers submitted on any of the logical channels assigned the same QueueId by the same algorithm. QueueIDs are assigned by the algorithm and published through its IDMA2 interface.

IDMA3 does not support the queue IDs defined in IDMA2. This means there is no requirement to enforce inter-channel FIFO ordering of submitted DMA transfers. When FIFO ordering is needed, you must use linked transfers.

SPRU352G –June 2005 –Revised February 2007 Use of the DMA Resource 67

Submit Documentation Feedback