uDMA Transfer

I'm using uDMA to transfer content from source to destination. During each transfer, I see the source pointer and destination pointer is moved from the memory to the DMA. Ideally, we need to do that only once. Because of the source/destination pointer movements, each transfer is taking 4 cycles. Why is it required to move the source pointer and destination pointer in each cycle? Is there a mode in which this can be avoided? 

Parents
  • There isn't any way of avoiding this.

    The uDMA was intended to be the smallest possible gatecount DMA implementation, so one of the ways the designers saved gates was by not storing values if they could avoid it. But as you have seen this does have a big impact on performance, with 2/4 cycles used to fetch addresses that could have just been simple increments (again maybe they didn't want to have address incrementers because they are avoidable gatecounts).

    So the only option is to make sure that the channel control values are stored in zero-wait local memory, and then the impact is kept to the bare minimum possible.

    Alternatively there are other ARM DMA engines you could look at. For AHB there are the older (but better for performance) PL080 and PL081 designs, and there are newer AXI based solutions.

Reply
  • There isn't any way of avoiding this.

    The uDMA was intended to be the smallest possible gatecount DMA implementation, so one of the ways the designers saved gates was by not storing values if they could avoid it. But as you have seen this does have a big impact on performance, with 2/4 cycles used to fetch addresses that could have just been simple increments (again maybe they didn't want to have address incrementers because they are avoidable gatecounts).

    So the only option is to make sure that the channel control values are stored in zero-wait local memory, and then the impact is kept to the bare minimum possible.

    Alternatively there are other ARM DMA engines you could look at. For AHB there are the older (but better for performance) PL080 and PL081 designs, and there are newer AXI based solutions.

Children