Direct Memory Access Controller (DMAC)

Introduction

This chapter provides an overview of the Realtek DMAC, which transmits data from the source to the destination through the AXI bus.

General Description

The following figure shows the following functional groupings of the main interfaces to the RTK_DMAC block:

• DMA hardware request interface

• Up to sixteen channels, the specific number is subject to the IP configuration form.

• FIFO per channel for source and destination

• Arbiter

• AXI master interface

• APB slave interface

Block diagram of DMAC

One channel of the RTK_DMAC is required for each source/destination pair. In the most basic configurations, the RTK_DMAC has one AXI master interface (two AXI transfers) and one channel. The master interfaces reads the data from a source peripheral (A) and writes it to a destination peripheral (B). Two AXI transfers are required for each DMA data transfer; this is also known as a dual-access transfer.

Basic Definitions

The following terms are concise definitions of the DMA concepts used throughout this data book:

• Source peripheral – Device from which the RTK_DMAC reads data; the RTK_DMAC then stores the data in the channel FIFO. The source peripheral teams up with a destination peripheral to form a channel. The source peripheral is generally AXI slave.

• Destination peripheral – Device to which the RTK_DMAC writes the stored data from the FIFO (previously read from the source peripheral). The destination peripheral is AXI slave.

• Memory – Source or destination that is always ready for a DMA transfer and does not require a handshaking interface to interact with the RTK_DMAC.

• Channel – Read/write data path between a source peripheral on one configured AXI layer and a destination peripheral on the same or different AXI layer that occurs through the channel FIFO. If the source peripheral is not a memory, then a source handshaking interface is assigned to the channel. If the destination peripheral is not a memory, then a destination handshaking interface is assigned to the channel. Source and destination handshaking interfaces can be assigned dynamically by programming the channel registers.

• Master interface – RTK_DMAC is a master on the AXI bus, reading data from the source and writing it to the destination over the AXI bus.

• Slave interface – The APB interface over which the RTK_DMAC is programmed.

• Handshaking interface – A set of handshake signals that conforms to a protocol between the RTK_DMAC and source/destination peripheral are used to control transferring a single or burst transaction between them. This interface is used to request, acknowledge, and control a RTK_DMAC transaction. A channel can receive a request through these handshaking interface: hardware or peripheral interrupt.

  • Hardware handshaking interface – Uses hardware signals to control transferring a single or burst transaction between the RTK_DMAC and the source or destination peripheral. For more information about this interface, refer to “Hardware Handshaking – Peripheral Is Not Flow Controller” and “Hardware Handshaking – Peripheral Is Flow Controller” (not supported).

  • Peripheral interrupt handshaking interface – Simple use of the hardware handshaking interface. In this mode, the interrupt line from the peripheral is tied to the dma_req input of the hardware handshaking interface; other interface signals are ignored.

• Flow controller – Device (either the RTK_DMAC, or source/destination peripheral) that determines the length of a DMA block transfer and terminates it.

  • If you know the length of a block before enabling the channel, then you should program the RTK_DMAC as the flow controller.

  • If the length of a block is not known prior to enabling the channel, the source or destination peripheral needs to terminate a block transfer. In this mode, the peripheral is the flow controller.

• Flow control mode (CFGx.FCMODE) – Special mode that only applies when the destination peripheral is the flow controller. It controls the data pre-fetching from the source peripheral.

• Block – Block of RTK_DMAC data, the amount of which is the block length and is determined by the flow controller. For transfers between the RTK_DMAC and memory, a block is broken directly into a sequence of bursts (including burst length = 1).

• Transaction – Basic unit of a RTK_DMAC transfer, as determined by the hardware. A transaction is relevant only for transfers between the RTK_DMAC and a source/destination peripheral if the peripheral is a non-memory There are two types of transactions:

  • Single transaction – Length of a single transaction is always 1 and is converted to a single AXI transfer.

  • Burst transaction – Length of a burst transaction is programmed into the RTK_DMAC. The burst transaction is converted into a sequence of bursts and AXI single transfers. RTK_DMAC executes each burst transfer by performing incremental bursts that are no longer than the maximum burst size set; the only type of AXI burst in this kind of transaction is incremental. The burst transaction length is under program control and normally bears some relationship to the FIFO sizes in the RTK_DMAC and in the source and destination peripherals.

• DMA transfer – Software controls the number of blocks in a RTK_DMAC transfer. Once the DMA transfer has completed, the hardware within the RTK_DMAC disables the channel and can generate an interrupt to signal the DMA transfer completion. You can then reprogram the channel for a new DMA transfer.

  • Single-block DMA transfer – Consists of a single block.

  • Multi-block DMA transfer – DMA transfer may consist of multiple RTK_DMAC blocks.

Multi-block DMA transfers are supported through block chaining (linked list pointers), auto-reloading channel registers, and contiguous blocks. The source and destination can independently select which method to use.

• Linked lists (block chaining) – Linked list pointer (LLP) points to the location in system memory where the next linked list item (LLI) exists. The LLI is a set of registers that describes the next block (block descriptor) and an LLP register. The RTK_DMAC fetches the LLI at the beginning of every block when block chaining is enabled. For more information about linked lists and block chaining, refer to “Block Chaining Using Linked Lists”.

LLI accesses are always 32-bit accesses (axsize = 2) aligned to 32-bit boundaries and cannot be changed or programmed to anything other than 32-bit.

• Auto-reloading – RTK_DMAC automatically reloads the channel registers at the end of each block to the value when the channel was first enabled. For more information about this function, refer to “Auto-Reloading of Channel Registers”

• Contiguous blocks – Address between successive blocks is selected to be a continuation from the end of the previous block. For more information, refer to “Contiguous Address between Blocks”.

• Scatter – Relevant to destination transfers within a block. The destination address is incremented or decremented by a programmed amount when a scatter boundary is reached. The number of AXI transfers between successive scatter boundaries is under software control.

• Gather – Relevant to source transfers within a block. The source address is incremented or decremented by a programmed amount when a gather boundary is reached. The number of AXI transfers between successive gather boundaries is under software control.

For more information about scatter and gather, refer to Scatter/Gather .

Note

RTL8721DxRTL8720ERTL8726ERTL8713ERTL8730E

Not support Scatter & Gather.

• FIFO mode – Special mode to improve  bandwidth. When enabled, the channel waits until the FIFO is less than half full to fetch the data from the source peripheral, and waits until the FIFO is greater than or equal to half full in order to send data to the destination peripheral. Because of this, the channel can transfer the data using bursts, which eliminates the need to arbitrate for the AXI master interface in each single AXI transfer. When this mode is not enabled, the channel waits only until the FIFO can transmit or accept a single AXI transfer before it requests the master bus interface.

Features

The DMAC component includes the following features.

General

• AXI-4 compliant

• APB4 slave interface is used to program registers.

• AXI master interface

  • Configurable data bus width (32bits) for AXI master interface

  • Configurable endianness for master interfaces

• Channels

  • Up to eight channels

  • Unidirectional channels – data transfers in one direction only

  • Programmable channel priority

• Transfers: support for memory-to-memory, memory-to-peripheral, peripheral-to-memory, and peripheral-to-peripheral DMA transfers

• Secure mode support: channels can be configured to secure mode to enhance the security

• Power save: support DMAC low power mode (internal clock gating)

• FIFO per channel for source and destination. The FIFO depth for channel 0/1 is 128 bytes, while 32 bytes for other channels.

• Transaction

  • Size:

  RTL8721DxRTL8720ERTL8726ERTL8713ERTL8730E

  The max. transfer size for one block is 65535.

  • Mode: support single block mode and multi-block mode.

  • Type: Support memory-to-memory, memory-to-peripheral, peripheral-to-memory, and peripheral-to-peripheral.

• All synchronous design (only 1 clock)

Address Generation

• Programmable source and destination addresses (on AXI bus)

• Address increment, or no change

• Multi-block transfers achieved through:

  • Linked Lists (block chaining)

  • Auto-reloading of channel registers

  • Contiguous address between blocks

• Independent source and destination selection of multi-block transfer type

• Scatter/Gather

Channel Buffering

• Single FIFO per channel for source and destination

• FIFO depth

• D flip-flop-based FIFO

Channel Control

• Programmable source and destination for each channel

• Programmable transfer type for each channel (memory-to-memory, memory-to-peripheral, peripheral-to-memory, and peripheral-to-peripheral)

• Programmable burst transaction size for each channel

• Programmable enable and disable of DMA channel

• Support for disabling channel without data loss

• Support for suspension of DMA operation

• Support for ERROR responses

• Programmable maximum burst transfer size per channel

• Configurable maximum transaction size to allow gate optimization

• Configurable maximum block size to allow gate optimization

• Option to disable the write-back of the Channel Control register at the end of every block transfer

Transfer Initiation

• Handshaking interfaces for source and destination peripherals (up to 128)

  RTL8721DxRTL8720ERTL8726ERTL8713ERTL8730E

  The number of handshake is 30.

  • Hardware handshaking interface

  • Peripheral interrupt handshaking interface (not support now)

  • 以下内容待确定

    • UART0 Tx/Rx

    • UART1 Tx/Rx

    • UART2 Tx/Rx

    • SPI0 Tx/Rx

    • SPI1 Tx/Rx

    • SPIC Tx/Rx

    • SPORT0F0 Tx/Rx

    • SPORT0F1 Tx/Rx

    • SPORT1F0 Tx/Rx

    • SPORT1F1 Tx/Rx

    • LEDC Tx

    • I2C0 Tx/Rx

    • I2C1 Tx/Rx

• Handshaking interface supports single or burst DMA transactions

• Polarity control for hardware handshaking interface

• Enabling and disabling of individual DMA handshaking interfaces

Flow Control

• Programmable flow control at block transfer level

• Software control of source data pre-fetch when destination is flow controller

Interrupts

• Combined and separate interrupt requests

• Interrupt generation on:

  • DMA transfer (multi-block) completion

  • Block transfer completion (contains block and block transfer completion)

  • Error condition (contain secure error and protocol error)

• Support of interrupt enabling and masking

Secure Mode

• Secure control bit in configure register

• Secure access for master interface and slave interface when secure bit set.

Functional Description

This section describes the functional details of the DMAC component.

Block Flow Controller and Transfer Type

The device that controls the length of a block is known as the flow controller. Either the DMAC, the source peripheral, or the destination peripheral must be assigned as the flow controller.

• If the block size is known prior to when the channel is enabled, then the DMAC should be programmed as the flow controller. The block size should be programmed into the CTLx.BLOCK_TS field.

• If the block size is unknown when the DMAC channel is enabled, either the source or destination peripheral must be the flow controller.

The CTLx.TT_FC field indicates the transfer type and flow controller for that channel. The following table lists valid transfer types and flow controller combinations.

Transfer type	Flow controller
Memory to Memory	DMAC
Memory to Peripheral	DMAC
Memory to Peripheral	Peripheral
Peripheral to Memory	DMAC
Peripheral to Memory	Peripheral
Peripheral to Peripheral	DMAC
Peripheral to Peripheral	Source Peripheral
Peripheral to Peripheral	Destination Peripheral

As an example, the DMAC can be programmed as the flow controller when a DMA block must be transferred from a receive peripheral to memory. Software then programs the CTLx.BLOCK_TS register with the same value and programs the DMAC as the flow controller.

Handshaking Interface

Handshaking interfaces are used at the transaction level to control the flow of single or burst transactions. The operation of the handshaking interface is different and depends on whether the peripheral or the DMAC is the flow controller.

The peripheral uses the handshaking interface to indicate to the DMAC that it is ready to transfer or accept data over the bus.

A non-memory peripheral can request a DMA transfer through the DMAC using hardware handshaking interfaces.

Note

Throughout the remainder of this document, references to both source and destination hardware handshaking interfaces assume an active-high interface (refer to CFGx.SRC(DST)_HS_POL bits in the Channel Configuration register). When active-low handshaking interfaces are used, then the active level and edge are reversed from that of an active-high interface.

The type of handshaking interface depends on whether the peripheral is a flow controller or not.

Note

Source and destination peripherals can independently select the handshaking interface type. For more information, refer to the CFGx.HS_SEL_SRC and CFGx.HS_SEL_DST parameters in the CFGx register.

Memory Peripherals

For memory, there is no handshaking interface with the DMAC, and therefore the memory peripheral can never be a flow controller. Once the channel is enabled, the transfer proceeds immediately without waiting for a transaction request.

Basic Interface Definitions

The following definitions are used in a data transaction.

• Source single transaction size in bytes

src_single_size_bytes = CTLx.SRC_TR_WIDTH/8

• Source burst transaction size in bytes

src_burst_size_bytes = CTLx.SRC_MSIZE * src_single_size_bytes

• Destination single transaction size in bytes

dst_single_size_bytes = CTLx.DST_TR_WIDTH/8

• Destination burst transaction size in bytes

dst_burst_size_bytes = CTLx.DST_MSIZE * dst_single_size_bytes

• Block size in bytes

  • DMAC is flow controller–With the DMAC as the flow controller, the processor programs the DMAC with the number of data items (block size) of source transfer width (CTLx.SRC_TR_WIDTH) to be transferred by the DMAC in a block transfer; this is programmed into the CTLx.BLOCK_TS field. Therefore, the total number of bytes to be transferred in a block is:

  blk_size_bytes_dma = CTLx.BLOCK_TS * src_single_size_bytes
  

  • Source peripheral is block flow controller

  blk_size_bytes_src = (Number of source burst transactions * src_burst_size_bytes) + (Number of source single transactions * src_single_size_bytes)
  

  • Destination peripheral is block flow controller

  blk_size_bytes_dst = (Number of destination burst transactions * dst_burst_size_bytes) + (Number of destination single transactions * dst_single_size_bytes)
  

Setting up Transfers

Transfers are set up by programming fields of the CTLx and CFGx registers for that channel. A single block is made up of numerous transactions – single and burst – which are in turn composed of OCP transfers. A peripheral requests a transaction through the handshaking interface to the DMAC. The operation of the handshaking interface is different and depends on what is acting as the flow controller.

The following table lists the parameters that are investigated in a transaction.

Parameter	Description
DMAC_CHx_FIFO_DEPTH	Channel x FIFO depth
CTLx.TT_FC	Transfer type and flow control
CTLx.BLOCK_TS	Block transfer size
CTLx.SRC_TR_WIDTH	Source transfer width
CTLx.DST_TR_WIDTH	Destination transfer width
CTLx.SRC_MSIZE	Source burst transaction length
CTLx.DEST_MSIZE	Destination burst transaction length
CFGx.FIFO_MODE	FIFO mode select
CFGx.FCMODE	Flow-control mode

Generating Requests for the Master Bus Interface

Each channel has a source state machine and destination state machine running in parallel. These state machines generate the request inputs to the arbiter, which arbitrates for the master bus interface (one arbiter per master bus interface).

When the source/destination state machine is granted control of the master bus interface, and when the master bus interface is granted control of the external bus, then transfers between the peripheral and the DMAC (on behalf of the granted state machine) can take place.

Transfers from the source peripheral or to the destination peripheral cannot proceed until the channel FIFO is ready. For burst transaction requests and for transfers involving memory peripherals, the criterion for “FIFO readiness” is controlled by the FIFO_MODE field of the CFGx register.

The definition of FIFO readiness is the same for:

• Single transactions

• Burst transactions, where CFGx.FIFO_MODE = 0

• Transfers involving memory peripherals, where CFGx.FIFO_MODE = 0

The channel FIFO is deemed ready when the space/data available is sufficient to complete a single transfer of the specified transfer width. FIFO readiness for source transfers occurs when the channel FIFO contains enough room to accept at least a single transfer of CTLx.SRC_TR_WIDTH width. FIFO readiness for destination transfers occurs when the channel FIFO contains data to form at least a single transfer of CTLx.DST_TR_WIDTH width.

Note

An exception to FIFO readiness for destination transfers occurs in “FIFO flush mode.” In this mode, FIFO readiness for destination transfers occurs when the channel FIFO contains data to form at least a single transfer of CTLx.SRC_TR_WIDTH width (and not CTLx.DST_TR_WIDTH width, as is the normal case).

When CFGx.FIFO_MODE = 1, then the criteria for FIFO readiness for burst transaction requests and transfers involving memory peripherals are as follows:

• A FIFO is ready for a source burst transfer when the FIFO has enough space for a source burst.

• A FIFO is ready for a destination burst transfer when the FIFO is greater than or equal to a destination burst full.

Exceptions to this “readiness” occur. During these exceptions, a value of CTLx.FIFO_MODE = 0 is assumed. The following are the exceptions:

• Near the end of a burst transaction or block transfer – The channel source state machine does not wait for the channel FIFO to be less than half empty if the number of source data items left to complete the source burst transaction or source block transfer is less than DMAC_CHx_FIFO_DEPTH/2. Similarly, the channel destination state machine does not wait for the channel FIFO to be greater than or equal to half full, if the number of destination data items left to complete the destination burst transaction or destination block transfer is less than DMAC_CHx_FIFO_DEPTH/2.

• In FIFO flush mode

• When a channel is suspended – The destination state machine does not wait for the FIFO to become half empty to flush the FIFO, regardless of the value of the FIFO_MODE field.

When the source/destination peripheral is not memory, the source/destination state machine waits for a single/burst transaction request. Upon receipt of a transaction request and only if the channel FIFO is “ready” for source/destination transfers, a request for the master bus interface is made by the source/destination state machine.

Note

There is one exception to this, which occurs when the destination peripheral is the flow controller and CFGx.FCMODE = 1 (data pre-fetching is disabled). Then the source state machine does not generate a request for the master bus interface (even if the FIFO is “ready” for source transfers and has received a source transaction request) until the destination requests new data.

When the source/destination peripheral is memory, the source/destination state machine must wait until the channel FIFO is “ready.” A request is then made for the master bus interface. There is no handshaking mechanism employed between a memory peripheral and the DMAC.

Scatter/Gather

Scatter

Scatter is relevant to a destination transfer. The destination address is incremented by a programmed amount – the scatter increment – when a scatter boundary is reached.

The following figure shows an example destination scatter transfer. The destination address is incremented by the value stored in the destination scatter increment (DSRx_L.DSI) field, multiplied by the number of bytes in a single AXI transfer to the destination (decoded value of CTLx_L.DST_TR_WIDTH)/8 – when a scatter boundary is reached. The number of destination transfers between successive scatter boundaries is programmed into the Destination Scatter Count (DSC) field of the DSRx register.

Scatter is enabled by writing a 1 to the CTLx_L.DST_SCATTER_EN field. The CTLx_L.DINC field determines if the address is incremented or remains fixed. If the CTLx_L.DINC field indicates a fixed-address control throughout a DMA transfer, then the CTLx_L.DST_SCATTER_EN field is ignored, and the scatter feature is automatically disabled.

Example of Destination Scatter Transfer

As an example of gather increment, consider the following:

SRC_TR_WIDTH = 3'b 010 (32 bit)
SGRx_L.SGC = 0x04 (source gather count)
CTLx_L.SRC_GATHER_EN = 1 (source gather enabled)
SARx = A0 (starting source address)

Example of Destination Scatter Transfer shows a source gather when SGRx_L.SGI = 0x01.

Gather

Gather is relevant to a source transfer. The source address is incremented or decremented by a programmed amount when a gather boundary is reached.

Example of Destination Scatter Transfer shows an example destination gather transfer. The number of source transfers between successive gather boundaries is programmed into the Source Gather Count (SGRx_L.SGC) field. The source address is incremented or decremented by the value stored in the source gather increment (SGRx_L.SGI) field, multiplied by the number of bytes in a single AXI transfer from the source – (decoded value of CTLx_L.SRC_TR_WIDTH)/8 – when a gather boundary is reached.

Gather is enabled by writing a 1 to the CTLx_L.SRC_GATHER_EN field. The CTLx_L.SINC field determines if the address is incremented, decremented, or remains fixed when a gather boundary is reached. If the CTLx_L.SINC field indicates a fixed-address control throughout a DMA transfer, then the CTLx_L.SRC_GATHER_EN field is ignored, and the gather feature is automatically disabled.

Note

For multi-block transfers, the counters that keep track of the number of transfers left to reach a gather/scatter boundary are re-initialized to the source gather count (SGRx_L.SGC) and destination scatter count (DSC), respectively, at the start of each block transfer.

Source Gather when SGRx_L.SGI = 0x1

In general, if the starting address is A0 and CTLx.SINC = 2’b00 (increment source address control), then the transfer will be:

• A0, A0 + TWB, A0 + 2*TWB …….(A0 + (SGR.SGC-1)*TWB)

• <-scatter_increment-> (A0 + (SGR.SGC*TWB) + (SGR.SGI*TWB))

Where TWB is the transfer width in bytes, decoded value of CTLx.SRC_TR_WIDTH/8 = src_single_size_bytes.

Secure Mode

DMAC supports secure mode, which can prevent non-secure access to secure range. When CPU configures the DMAC transfer without secure mode register access, the secure access bit will not be set. For AXI DMAC, master interface will output AxProt[1] =0 for secure access to source or destination address.

Generally, secure slave will response error data (for source) or reject the write (for destination) when non-secure access to it.

The work flow for secure DMAC transfer should be as follows:

1. Set the secure access bit to 0 in configure register for some channel with secure mode write.

2. Enable the DMAC transfer.

3. Wait for DMAC transfer over or interrupt, then DMAC will clear channel enable bit automatically.

4. Secure access bit should be cleared when the channel doesn’t need secure access anymore.

Refer to the registers for more details.

Registers

This section describes the programmable registers of the DMAC. All registers are aligned to a 64-bit boundary and are 64 bits wide. In general, the upper 32 bits of a register are reserved. A write to reserved bits within the register is ignored if there is no special explanation.

Note

• There are references to both software and hardware parameters throughout this chapter.

• The software parameters are the field names in each register description table and are prefixed by the register name; for example, the Block Transfer Size field in the Control register for Channel x is designated as “CTLx.BLOCK_TS.”

• The hardware parameters are prefixed with DMAC_* and are configured once using Realtek coreTools.

• Shipped with the RTK_DMAC component is an address definition (memory map) C header file. This can be used when the RTK_DMAC is programmed in a C environment

RTL8721DxRTL8720ERTL8726ERTL8713ERTL8730E

Programming the DMAC

The DMAC can be programmed through software registers or the DMAC low-level software driver.

DMA Transfer Types

A DMA transfer may consist of single or multi-block transfers. On successive blocks of a multi-block transfer, the SARx/DARx register in the DMAC is reprogrammed using either of the following methods:

• Block chaining using linked lists

• Auto-reloading

• Contiguous address between blocks

On successive blocks of a multi-block transfer, the CTLx register in the DMAC is reprogrammed using either of the following methods:

• Block chaining using linked lists

• Auto-reloading

When block chaining, using Linked Lists is the multi-block method of choice. On successive blocks, the LLPx register in the DMAC is reprogrammed using block chaining with linked lists.

A block descriptor consists of six registers: SARx, DARx, LLPx, CTLx, SSTATx, and DSTATx. The first four registers, along with the CFGx register, are used by the DMAC to set up and describe the block transfer.

Multi-Block Transfers

Note

Multi-block transfers—in which the source and destination are swapped during the transfer—are not supported. In a multi-block transfer, the direction must not change for the duration of the transfer.

Block Chaining Using Linked List

In this case, the DMAC reprograms the channel registers prior to the start of each block by fetching the block descriptor for that block from system memory. This is known as an LLI update.

DMAC block chaining uses a Linked List Pointer register (LLPx) that stores the address in memory of the next linked list item. Each LLI contains the corresponding block descriptors:

• SARx

• DARx

• LLPx

• CTLx

• SSTATx

• DSTATx

To set up block chaining, you program a sequence of Linked Lists in memory.

LLI accesses are always 32-bit accesses (Hsize = 2) aligned to 32-bit boundaries and cannot be changed or programmed to anything other than 32-bit, even if the OCP master interface of the LLI supports more than a 32-bit data width.

The SARx, DARx, LLPx, and CTLx registers are fetched from system memory on an LLI update. If configuration parameter DMAC_CHx_CTL_WB_EN = True, then the updated contents of the CTLx, SSTATx, and DSTATx registers are written back to memory on block completion. The following figures show how you use chained linked lists in memory to define multi-block transfers using block chaining.

Multi-block transfer using linked lists when DMAC_CHx_STAT_SRC set to true

It is assumed that no allocation is made in system memory for the source status when the configuration parameter DMAC_CHx_STAT_SRC is set to False. If this parameter is False, then the order of a Linked List item is as follows:

• SARx

• DARx

• LLPx

• CTLx

• DSTATx

Multi-block transfer using linked lists when DMAC_CHx_STAT_SRC set to false

Note

In order to not confuse the SARx, DARx, LLPx, CTLx, STATx, and DSTATx register locations of the LLI with the corresponding DMAC memory mapped register locations, the LLI register locations are prefixed with LLI; that is, LLI.SARx, LLI.DARx, LLI.LLPx, LLI.CTLx, LLI.SSTATx, and LLI.DSTATx.

The following figures show the mapping of a Linked List Item stored in memory to the channel registers block descriptor.

Mapping of block descriptor (LLI) in memory to channel registers when DMAC_CHx_STAT_SRC set to true

Mapping of block descriptor (LLI) in memory to channel registers when DMAC_CHx_STAT_SRC set to false

Rows 6 through 10 of Programming of transfer types and channel register update method show the required values of LLPx, CTLx, and CFGx for multi-block DMA transfers using block chaining.

Note

For rows 6 through 10 of Programming of transfer types and channel register update method , the LLI.CTLx, LLI.LLPx, LLI.SARx, and LLI.DARx register locations of the LLI are always affected at the start of every block transfer. The LLI.LLPx and LLI.CTLx locations are always used to reprogram the DMAC LLPx and CTLx registers. However, depending on Programming of transfer types and channel register update method row number, the LLI.SARx/LLI.DARx address may or may not be used to reprogram the DMAC SARx/DARx registers.

Programming of transfer types and channel register update method

No.	Transfer type	LLP.LOC=0	LLP_SRC_EN (CTLx)	RELOAD_SRC (CRGx)	LLP_DST_EN (CTLx)	RELOAD_DST (CRGx)	CTLx, LLPx update method	SARx update method	DARx update method	Write back
1	Single-block or last transfer of multi-block	Yes	0	0	0	0	None, user reprograms	None (Single)	None (Single)	No
2	Auto-reload multi-block transfer with contiguous SAR	Yes	0	0	0	1	CTLx, LLPx are reloaded from initial values	Contiguous	Auto-Reload	No
3	Auto-reload multi-block transfer with contiguous DAR	Yes	0	1	0	0	CTLx, LLPx are reloaded from initial values	Auto-Reload	Contiguous	No
4	Auto-reload multi-block transfer	Yes	0	1	0	1	CTLx, LLPx are reloaded from initial values	Auto-Reload	Auto-Reload	No
5	Single-block or last transfer of multi-block	No	0	0	0	0	None, user reprograms	None (Single)	None (Single)	Yes
6	Linked list multi-block transfer with contiguous SAR	No	0	0	1	0	CTLx, LLPx loaded from next Linked List item	Contiguous	Linked List	Yes
7	Linked list multi-block transfer with auto-reload SAR	No	0	1	1	0	CTLx, LLPx loaded from next Linked List item	Auto-Reload	Linked List	Yes
8	Linked list multi-block transfer with contiguous DAR	No	1	0	0	0	CTLx, LLPx loaded from next Linked List item	Linked List	Contiguous	Yes
9	Linked list multi-block transfer with auto-reload DAR	No	1	0	0	1	CTLx, LLPx loaded from next Linked List item	Linked List	Auto-Reload	Yes
10	Linked list multi-block transfer	No	1	0	1	0	CTLx, LLPx loaded from next Linked List item	Linked List	Linked List	Yes

Note

• Throughout this table, there are descriptions about fetching the LLI.CTLx register from the location pointed to by the LLPx register. This exact location is the LLI base address (stored in LLPx register) plus the fixed offset. For example, in Mapping of block descriptor (LLI) in memory to channel registers when DMAC_CHx_STAT_SRC set to true , the location of the LLI.CTLx register is LLPx.LOC + 0xc.

• Referring to Programming of transfer types and channel register update method , if the Write Back column entry is “Yes” and the configuration parameter DMAC_CHx_CTL_WB_EN = True, then the CTLx[63:32] register is always written to system memory (to LLI.CTLx[63:32]) at the end of every block transfer. The source status is fetched and written to system memory at the end of every block transfer if the Write Back column entry is “Yes,” DMAC_CHx_CTL_WB_EN = True, DMAC_CHx_STAT_SRC = True, and CFGx.SS_UPD_EN is enabled. The destination status is fetched and written to system memory at the end of every block transfer if the Write Back column entry is “Yes,” DMAC_CHx_CTL_WB_EN = True, DMAC_CHx_STAT_DST = True, and CFGx.DS_UPD_EN is enabled.

• The Write back column assumes that the configuration parameter DMAC_CHx_CTL_WB_EN = True. If DMAC_CHx_CTL_WB_EN = False, then there is never writeback of the control and status registers regardless of transfer type, and all rows of this column are “No”.

Auto-Reloading of Channel Registers

During auto-reloading, the channel registers are reloaded with their initial values at the completion of each block and the new values used for the new block. Depending on the row number in Programming of transfer types and channel register update method , some or all of the SARx, DARx, and CTLx channel registers are reloaded from their initial value at the start of a block transfer.

Contiguous Address between Blocks

In this case, the address between successive blocks is selected as a continuation from the end of the previous block.

Enabling the source or destination address to be contiguous between blocks is a function of the CTLx.LLP_SRC_EN, CFGx.RELOAD_SRC, CTLx.LLP_DST_EN, and CTLx.RELOAD_DST registers (see Programming of transfer types and channel register update method ).

Note

You cannot select both SARx and DARx updates to be contiguous. If you want this functionality, you should increase the size of the Block Transfer (CTLx.BLOCK_TS), or if this is at the maximum value, use Row 10 of Programming of transfer types and channel register update method and set up the LLI.SARx address of the block descriptor to be equal to the end SARx address of the previous block. Similarly, set up the LLI.DARx address of the block descriptor to be equal to the end DARx address of the previous block. For more information, refer to “Multi-Block Transfer with Linked List for Source and Linked List for Destination (Row 10)”

Suspension of Transfers between Blocks

At the end of every block transfer, an end-of-block interrupt is asserted if:

1. Interrupts are enabled, .INT_EN = 1, and

2. The channel block interrupt is unmasked, MaskBlock[n] = 1, where n is the channel number.

Note

The block-complete interrupt is generated at the completion of the block transfer to the destination.

For rows 6, 8, and 10 of Programming of transfer types and channel register update method , the DMA transfer does not stall between block transfers. For example, at the end-of-block N, the DMAC automatically proceeds to block (N + 1).

For rows 2, 3, 4, 7, and 9 of Programming of transfer types and channel register update method (SARx and/or DARx auto-reloaded between block transfers), the DMA transfer automatically stalls after the end-of-block interrupt is asserted, if the end-of-block interrupt is enabled and unmasked.

The DMAC does not proceed to the next block transfer until a write to the ClearBlock[n] block interrupt clear register, done by software to clear the channel block-complete interrupt, is detected by hardware.

For rows 2, 3, 4, 7, and 9 of Programming of transfer types and channel register update method (SARx and/or DARx auto-reloaded between block transfers), the DMA transfer does not stall if either:

• Interrupts are disabled, CTLx.INT_EN = 0, or

• The channel block interrupt is masked, MaskBlock[n] = 0, where n is the channel number.

Channel suspension between blocks is used to ensure that the end-of-block ISR (interrupt service routine) of the next-to-last block is serviced before the start of the final block commences. This ensures that the ISR has cleared the .RELOAD_SRC and/or .RELOAD_DST bits before completion of the final block. The reload bits .RELOAD_SRC and/or .RELOAD_DST should be cleared in the end-of-block ISR for the next-to-last block transfer.

Ending Multi-Block Transfers

All multi-block transfers must end as shown in either Row 1 or Row 5 of Programming of transfer types and channel register update method . At the end of every block transfer, the DMAC samples the row number, and if the DMAC is in the Row 1 or Row 5 state, then the previous block transferred was the last block and the DMA transfer is terminated.

Note

Row 1 and Row 5 are used for single-block transfers or terminating multi-block transfers. Transfers initiated in rows 2, 3 or 4 can only end in row 1; similarly, transfers initiated in rows 6 through 10 can only end in row 5. Ending in the Row 5 state enables status fetch and write-back for the last block. Ending in the Row 1 state disables status fetch and write-back for the last block.

For rows 2, 3, and 4 of Programming of transfer types and channel register update method , (LLPx.LOC = 0 and .RELOAD_SRC and/or .RELOAD_DST is set), multi-block DMA transfers continue until both the .RELOAD_SRC and .RELOAD_DST registers are cleared by software. They should be programmed to 0 in the end-of-block interrupt service routine that services the next-to-last block transfer; this puts the DMAC into the Row 1 state.

For rows 6, 8, and 10 of Programming of transfer types and channel register update method (both .RELOAD_SRC and .RELOAD_DST cleared), the user must set up the last block descriptor in memory so that both LLI.CTLx.LLP_SRC_EN and LLI.CTLx.LLP_DST_EN are 0.

The sampling of the LLPx.LOC bit takes place exclusively at the beginning of the transfer when the channel is enabled. This determines whether writeback is enabled throughout the complete transfer, and changing the value of this bit in subsequent blocks on the same transfer does not have any effect.

Note

The only allowed transitions between the rows of Programming of transfer types and channel register update method are from any row into Row 1 or Row 5. As already stated, a transition into row 1 or row 5 is used to terminate the DMA transfer; all other transitions between rows are not allowed. Software must ensure that illegal transitions between rows do not occur between blocks of a multi-block transfer. For example, if block N is in row 10, then the only allowed rows for block (N +1) are rows 10 or 5.

Disabling a Channel Prior to Transfer Completion

Under normal operation, software enables a channel by writing a 1 to the channel enable register, ChEnReg.CH_EN, and hardware disables a channel on transfer completion by clearing the ChEnReg.CH_EN register bit.

The recommended way for software to disable a channel without losing data is to use the CH_SUSP bit in conjunction with the FIFO_EMPTY bit in the Channel Configuration Register (CFGx).

1. If software wishes to disable a channel prior to the DMA transfer completion, then it can set the CFGx.CH_SUSP bit to tell the DMAC to halt all transfers from the source peripheral. Therefore, the channel FIFO receives no new data.

2. Software can now poll the CFGx.FIFO_EMPTY bit until it indicates that the channel FIFO is empty.

3. The ChEnReg.CH_EN bit can then be cleared by software once the channel FIFO is empty.

When CTLx.SRC_TR_WIDTH < CTLx.DST_TR_WIDTH and the CFGx.CH_SUSP bit is high, the CFGx.FIFO_EMPTY is asserted once the contents of the FIFO do not permit a single word of CTLx.DST_TR_WIDTH to be formed. However, there may still be data in the channel FIFO, but not enough to form a single transfer of CTLx.DST_TR_WIDTH. In this scenario, once the channel is disabled, the remaining data in the channel FIFO is not transferred to the destination peripheral.

It is permissible to remove the channel from the suspension state by writing a 0 to the CFGx.CH_SUSP register. The DMA transfer completes in the normal manner.

Note

• If a channel is disabled by software, an active single or burst transaction is not guaranteed to receive an acknowledgement.

• If the DMAC is configured to use defined length bursts (DMAC_INCR_BURSTS = 0), disabling the channel via software prior to completing a transfer is not supported.

Abnormal Transfer Termination

A DMAC transfer may be terminated abruptly by software by clearing the channel enable bit, ChEnReg.CH_EN. You must not assume that the channel is disabled immediately after the ChEnReg. The CH_EN bit is cleared over the AHB slave interface. Consider this as a request to disable the channel. You must poll ChEnReg.CH_EN and confirm that the channel is disabled by reading back 0. A case where the channel is not disabled after a channel disable request is where either the source or destination has received a split or retry response. The DMAC must keep re-attempting the transfer to the system HADDR that originally received the split or retry response until an OKAY response is returned; to do otherwise is an AMBA protocol violation.

Software may terminate all channels abruptly by clearing the global enable bit in the DMAC Configuration Register (DmaCfgReg[0]). Again, you must not assume that all channels are disabled immediately after the DmaCfgReg[0] is cleared over the AHB slave interface. Consider this as a request to disable all channels. You must poll ChEnReg and confirm that all channels are disabled by reading back 0.

Note

• If the channel enable bit is cleared while there is data in the channel FIFO, this data is not sent to the destination peripheral and is not present when the channel is re-enabled. For read-sensitive source peripherals, such as a source FIFO, this data is therefore lost. When the source is not a read-sensitive device (such as memory), disabling a channel without waiting for the channel FIFO to empty may be acceptable, since the data is available from the source peripheral upon request and is not lost.

• If a channel is disabled by software, an active single or burst transaction is not guaranteed to receive an acknowledgement.

• If the DMAC is configured to use defined length bursts (DMAC_INCR_BURSTS = 0), disabling the channel via software prior to completing a transfer is not supported.