Texas Instruments TMS320 DSP - Manual (Page 67)

www.ti.com
6.9 Runtime APIs
6.10 Strong Ordering of DMA Transfer Requests
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.
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's client 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.
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