Cyclone V SX SoC - DMA Controller Peripheral Request Interface

I'm more on the hardware side of the fence so I recommend the mailing list at rocketboards as well.

One thing to know is that if you want to maximize the throughput of moving data from SDRAM in the HPS to the FPGA the fastest method is to have the FPGA pull the data out of the SDRAM directly using the FPGA-to-SDRAM ports. You can have a 256-bit wide direct interface into the SDRAM from the FPGA which will dwarf the throughput of having the HPS DMA pushing the data out of the HPS-to-FPGA bridge. A DMA capable of memory-mapped to streaming transfers is all you need to make this possible and it should be a lot easier to program for as well.

Dear Ankit,

when you need help with die device driver, write the mailing list at rocketboards.org and look into the archive. I am also at a similar projekt, when you want to use "Master" Transfers (DMA-330 initializes transfer) there is no example driver. For "Slave" Transfers (Peripheral has to request transfers) you will find an example in the "linux-socfpga" repository. "fpga-dma.c" under "linux-socfpga\arch\arm\mach-socfpga" . just some hints. I am also not finished with my driver.

Kr,

Florian

Dear BadOmen

I am using altera’s cyclone V with the linux kernel 3.8

I am working on a project in which I to make a peripheral in which I write to a FIFO, the FIFO is read and some logic is performed to the data, and the results are stored in another FIFO. The goal is to transfer data between the HPS and the peripheral as fast as possible. To achieve this I want to use DMA transfers between the HPS and the peripheral using the hard DMA-330 IP in the HPS.

I am new to linux device drivers and I need help writing the device driver for this peripheral.

I saw your flow_control_fifo.v peripheral code and the fpga-dma.c driver code. Could you please guide me to have this working with my requirements? I understand the verilog code but I need help with driver.

Sincerely

Ankit

Actually I should have mentioned that the RTL I attached is infant what that FPGA DMA example driver is for. Peripherals can make two types of transfer requests bursts and singles. Burst requests are for transfer multiple words of data per request and single registers are for transferring only one word of data per request (by word I mean whatever data width the DMA is setup to transfer).

In the example FPGA DMA driver what should be happening is the DMA channel should be programmed with a burst length and the same burst size is programmed into the FIFO logic in the FPGA. This burst size can be changed but the important thing is that both the peripheral and DMA channel need to be using the same burst length. For example if the FIFO depth is 128 and the burst size for the peripheral is 4, that means when the DMA writes to the FIFO it's always being told there are at least 4 words worth of space in the FIFO. Now if the DMA was programmed for bursts of 8 words but the FIFO is programmed for bursts of 4, if the FIFO becomes already has 124 words of data buffered it will request a burst of 4 and the DMA will write 8 words and probably overflow the FIFO.

Normally I recommend that if data is being moved between the HPS and FPGA that users put a soft DMA engine into the FPGA fabric. This makes variable length ST to MM transfers much easier because it's tricky to setup a DMA-330 channel when you don't know how much incoming data is arriving, that might not make sense until you read the DMA chapter and see what the channel microcode looks like. Also if a lot of data bandwidth is needed, using soft DMA engines in the FPGA also have the additional benefit of more memory HPS SDRAM bandwidth. The DMA accesses SDRAM through a 32-bit connection so at 400Mhz you are talking at most 12.8Gbps of bandwidth. The FPGA has a 256-bit aggregate connection to the SDRAM so running at only 100Mhz gives you 25.6Gbps of bandwidth from the FPGA into HPS SDRAM. If using a soft DMA sounds feasible to you I would check recommend using the modular SGDMA which is available in Qsys version 14.0. Unfortunately it doesn't have a driver so you can get a Nios II baremetal driver and documentation from here: http://www.alterawiki.com/wiki/modular_sgdma porting it over to run on the ARM is fairly trivial I'm told.

Thanks for you Reply,

so this flow control fifo example and the fpga_dma example driver from altera just use DMA Controlled Length Management? Hard to understand the driver :/.

I thought I can give the length information with the DMA Request Interface. Like the fpga logic push a request with length information inside.

So either the DMA Controller has to read every time I want to use a peripheral request(with different packet size) the register of my fpga logic (DMA Controlled Length Managemengt )OR

the length information can be attached to the request (Peripheral Length Management).

In my case I receive Packets with different size via Avalon Streaming and want to give the information with the peripheral request, and not that the DMA Controller has to read every time the length register of my fpga logic. I would understand the documentation of altera that both scenarios are possible, but the FPGA peripheral requist interface is different compared to the interface inside the HPS logic.

I hope my english is understandable ;) . Thanks a lot badOmen

I would understand your post like I have to agree the length before the peripheral request occour?

The burst length is basically an arbitrary number that both the DMA and the peripheral must agree upon. So it doesn't have anything to do with burst transactions at a bus level but rather an agreed upon number of transfers.

So when the peripheral requests a burst the DMA has to know what the burst size is ahead of time. Typically you make the burst size programmable in the peripheral and you pass this size to the peripheral and the DMA when setting up the DMA transfers.

The reason why this is important is lets say the peripheral is a FIFO and the DMA writes into it. If the DMA and peipheral do not agree to the same burst length then the DMA could potentially read/write too much data causing an under/overflow to occur.

I have attached a file that contains more details in the comments about how to drive these request signals and how to react to the acknowledge back from the DMA.