ARM Technical Support Knowledge Articles

Section 2.13. Synchronization

Applies to: PL08x DMAC (DM & SM)


Can peripherals operating on a different clock to the DMAC be used?

Yes, when a peripheral generating a DMA request runs on a different clock to the DMA controller, synchronization logic must be used. For peripherals running on the same clock as the DMAC, disabling the synchronization logic improves the DMA response time.

When doing the simplest transfer, let say a transfer of one word from source to destination, what is the number of cycle needed for the transfer inside the DMA?

How many clocks it takes depends on how the data is transferred and this will depend on how you have configured the DMAC.

You would have programmed the DMAC with the burst size, transfer size, width and so forth.

How the burst is broken up will depend on a number of factors:

  • The amount of data to be transferred;
  • The width of the transfer;
  • The space (or amount of data) in the channel's FIFO;
  • Size of burst

The DMAC will build/break up the transfers appropriately based on the information programmed into the DMAC.

The two master interface allows, for example, the PrimeCell DMA controller to transfer data directly from the memory connected to AHB port 1 to any peripheral connected to AHB port 2. This can take place whilst a transfer is taking place on AHB port 1 independent of what is taking place on AHB port 2. The dual master interface minimizes system bus overhead performance.

Thus having the source and destination on separate buses means that data can be written out in the next cycle. If the memory is the source, again INCR16 will be used for byte accesses and INCR4 for word accesses, but you are limited by the size of the FIFO. If the memory is the destination then INCR will be used.

Things to consider in this time are:

1)Arbitration - changing from source to destination
2)Synchronisation time - 2 cycles
3)Time for changing between channels if this is the case

1)There is typically about three idle cycles between source and destination transfers which is due to the arbitration logic within the DMAC.

2)There is also some synchronisation logic within the DMAC which accounts for two cycles and so performance can be improved a bit by disabling this if the clock(s) of the peripheral(s) generating the request(s) is/are the same as the DMAC clock.

3) Assuming requests are pending and that the fixed priority has already been sorted out, the current channel must finish its AHB transfer and so it will depend on the number of transfers being carried out. At worst case it could be for 16beats as the largest AHB burst that can be carried out is an INCR16 transfer.

Article last edited on: 2008-09-09 15:47:25

Rate this article

Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential