[SOLVED] DMA Controller location in SoC (different AMBA buses).

[Hjldioyitsi]

Hi all,

I have seen multiple diagrams of SoCs with DMA Controllers that support different types of AMBA buses, but some put the DMA Controller in between AMBA buses (e.g: AHB and APB, aside to the bus bridge) whilst others put the DMA Controller in the same AMBA bus as the core processor. Are these functionally equivalent? Is one way better than the other? Note that in the example below the DMA Controller has to support access between AHB memory and APB peripherals.
Thanks!

 

[SynthWorks]

Your DMA controller is moving data from one location to another. Locating it between the AHB and APB is going to allow it to address the AHB memory (on AHB) and move items to the SPI master (on APB).

Putting your DMA controller on AHB without anything co-located will require two accesses to the AHB to move data - one cycle to read it and a separate cycle to write it - consuming twice the band width on AHB.

 

[Hjldioyitsi]

True... thanks! BTW, I forgot to add the AHB SLAVE interface on the DMAC as well. It should have both AHB MASTER & AHB SLAVE.
Still isn't this somehow redundant? I mean, shouldn't I have to put an AHB2APB bridge inside my DMAC? Or maybe share the existing one...

Another option could be to make a dedicated AHB interface for the DMA accesses?

 

[dpaul]

The need to put a DMA core for your peripherals (here SPI and I2C), as you have depicted in the last two pictures, really depends on how much memory those slaves are having. If their memory is of the order of KB, using a DMA core to access their memories might be an overkill.
It is then better to gather the data from the slaves in a RAM first, and then the uP core can read them out from the RAM using DMA.

 

[Hjldioyitsi]

The need to put a DMA core for your peripherals (here SPI and I2C), as you have depicted in the last two pictures, really depends on how much memory those slaves are having. If their memory is of the order of KB, using a DMA core to access their memories might be an overkill.
It is then better to gather the data from the slaves in a RAM first, and then the uP core can read them out from the RAM using DMA.

Okay, thanks! But in this case we can assume the peripheral's memories are large enough.

 

[dpaul]

I have rarely seen I2C/SPI peripherads operate at freq >25MHz (25MHz is really high), whereas an ARM core based processor system will operate at >100MHz. So you are looking here to gather data from peripherals which are atleast 4x times slower.
So having large amount of memory space for such slow peripherals is a bad design, it is just a wastage of hardware resources. Any good hardware design engineer will try to save as much as possible silicon real estate.

Then again look at the AMBA spec of various protocols. 4KB is the recommended highest boundary for AXI slaves, 1KB is specified for AHB and if I am not mistaken, APB does not specify any minimum, instead it just takes the minimum defined by whatever bus is driving the APB bridge.

So considering the above, I DO NOT see a good reason to put a DMAC for the ARM to directly access the slaves with such low memory space.

 

[Hjldioyitsi]

I have rarely seen I2C/SPI peripherads operate at freq >25MHz (25MHz is really high), whereas an ARM core based processor system will operate at >100MHz. So you are looking here to gather data from peripherals which are atleast 4x times slower.
So having large amount of memory space for such slow peripherals is a bad design, it is just a wastage of hardware resources. Any good hardware design engineer will try to save as much as possible silicon real estate.

Then again look at the AMBA spec of various protocols. 4KB is the recommended highest boundary for AXI slaves, 1KB is specified for AHB and if I am not mistaken, APB does not specify any minimum, instead it just takes the minimum defined by whatever bus is driving the APB bridge.

So considering the above, I DO NOT see a good reason to put a DMAC for the ARM to directly access the slaves with such low memory space.

I forgot to say the picture is merely illustrative. You can forget "SPI" or "I2C" and just consider a generic peripheral that could be anything that would worth having a DMAC.

 

[dpaul]

It seems you have read only a part of my last post.
I have already explained the memory limits of AMBA slaves (you have shown us an AMBA bus based architecture and you need to keep in mind the limits of AMBA based slaves) and based on that it needs to be decided if a DMAC is needed for them.

Do you find anything wrong in my argument?

If yes let me hear about it, else I have nothing more to contribute!

 

[dpaul]

Ok, forgot about your architecture specific question....
Since you have a RAM and peripherals with large memories, for an efficient design, I would have a DMAC for the RAM and another DMAC for the peripherals. The DMAC for the peripherals, I would place on the peripheral bus itself (the DMAC block parallel to the SPI/I2C slave blocks).

 

[Hjldioyitsi]

Why some DMACs with two synchronous AHB MASTER interfaces uses internal FIFOs? E.g.: ARM's PL080 has a 4-word internal FIFO... what's the big advantage of that?

 

[dpaul]

Create a separate thread for a separate questions!

If you do not have any questions for your original post, mark this thread as solved.
If you do not do it or if a Moderator does not do it, then I will do it, since I have been mostly answering.