ARM Technical Support Knowledge Articles

Section 2.10. Burst Requests

Applies to: PL08x DMAC (DM & SM)

Answer

The first entry in Table B-1, Section B.4 on page B-4(Appendix B) shows only the DMACBREQ signal n the case of the Memory-to-Peripheral transfer where the peripheral is the request generator and the DMAC is the flow controller. How comes only the DMACBREQ is used?

As the DMA controller is the flow controller, it knows how many transfers are to be carried out and it need only monitor the DMACBREQ signal. If an odd number of transfers, say 17, is to be transferred, then DMACBREQ will be asserted and four words will be transferred. Then DMACBREQ will be asserted again, but this time the DMA controller knows it only wants to transfer one word and thus it transfers that remaining word. Therefore there is no need for DMACSREQ.

How is the DMACxCLR generated for a particular channel for a burst/single request? For a single request is this generated after each single transaction and for a burst request is it generated after each burst?

The DMACxCLR signal is asserted one clock after the end of the data phase of the last beat of the transfer. DMACCLR is not specific to a single request or a burst request. There is only one single DMACLLR request and this is asserted at the end of either a single or a burst request depending on which has been asserted. The functional diagram in figure B-23 on page B-21 (Appendix B) of the Technical Reference Manual shows the DMACCLR signal and describes when it is asserted and deasserted.

This diagram however, is an example. It assumes that the peripheral can recognize the assertion of the DMACCLR signal within a cycle and then deassert its request line in the next cycle, which is when the DMAC will acknowledge the deassertion of the request line and deassert the DMACCLR signal. The DMACCLR signal being deasserted will be in response to the peripheral request line being deasserted and hence is dependent on when the peripheral can respond to the assertion of the DMACCLR signal and when it can deassert its request signal.

Thus the example shown is for a best case scenario. However, one could imagine that there may well be peripherals that people are using that may not respond that quickly. The DMA controller is an AHB peripheral. However, the peripherals that are connected to the DMA controller could be on the APB and may thus be running at a different clock frequency.

Referring to the Functional Timing Diagram in Figure B-21 on page B-20 (Appendix B) of the Technical Reference Manual, is it legal or illegal to give a new DMAC request while DMACCLR is HIGH?

It would not be legal to have another DMAC request from the SAME peripheral whilst DMACCLR is HIGH, as the DMACCLR signal is used as a handshaking mechanism to acknowledge the request and deassert the request once it has been serviced. It may, however, be possible to have a new DMAC request from ANOTHER peripheral whilst DMACCLR is HIGH.

Thus considering an example of the sequence in question:

1) DMA{S/B}REQ goes active ->
2) data transfer ->
3) on last transfer DMACLR goes active ->
4) DMA{S/B}REQ goes inactive ->
5) DMA{S/B}REQ goes active indicating another transfer ->
6) DMACLR goes inactive.

The difference between step-4 and step-6 is only ONE clock. In step-4 the request is inactive. On the very next clock DMACLR goes inactive (having sampled the inactive request) and the channel-state-machine goes to IDLE. After this happens, only then can the request come back again.

In other words, the peripheral request should go low for at least ONE HCLK and only then can it can come back again.

What exactly is meant by "The two request signals are not mutually exclusive?"
Are there any cases where the burst requests DMACBREQ and DMACSREQ may not be mutually exclusive?

DMACBREQ and DMACSRREQ are not mutually exclusive in that they can both be asserted at the same time but the DMA controller, based on the information you have programmed it with, will monitor one of them as described in that paragraph. Note that the scenario quoted there is where the DMA channel is the flow controller and so controls the length of the packet as the packet length would have been programmed by software before the DMA controller was enabled.

The DMA controller being the flow controller means that, it knows how many transfers are to be carried out and it need only monitor the DMACBREQ signal. If an odd number of transfers, say 17, is to be transferred, then DMACBREQ will be asserted and four words will be transferred. Then DMACBREQ will be asserted again, but this time the DMA controller knows it only wants to transfer one word and thus it transfers that remaining word. Therefore it is not necessarily necessary to use DMACSREQ.

Yes, there may be cases where DMACBREQ and DMACSREQ are mutually exclusive, as you say. When the amount of data left is less than the burst size, the PrimeCell DMA controller monitors DMACSREQ and commences single transfers when requested, particularly when it is not the flow controller.

Can both software and hardware requests be used at the same time?

A request can be generated from either a peripheral or the software request register within theDMAC, but it is recommended that software and hardware peripheral requests are not used at the same time.

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

Rate this article

[Bad]
|
|
[Good]
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