SGDMA to SDRAM speed?

Hello,

I don't know why the forum keeps resizing my image. If you don't mind, I've uploaded the image on the cloud:

http://1drv.ms/1ovvaw3

Hello,

I don't know why the forum keeps resizing my image. And if I post a link, the moderator must accept it, and I think it will take a very long time.

If you don't mind, I've uploaded the image on the cloud, hope there is no problem posting it here like this:

ht tp://1drv .ms/1OVVaw3

Just copy and paste it and delete the spaces.

Hello,

Thanks for your answer.

Yes, in fact they have different clocks. I tried looking into the solution you have proposed, but the Dual clock FIFO uses Avalon-ST, so the input is a sink ant the output is a streaming source. I'm still a newbie on this thing, so I'm not sure how I should connect this between my SGDMA and the SDRAM. Can you give me some tips?

I've now uploaded a better screenshot, and my qsys diagram in case you or anybody else would like to take a closer look. I'm not intending to delete this in the future, so if we solve this, I will upload the corrected version for other people to download.

(just paste and delete the spaces again if you're willing to take a look at this)

ht tp://1dr v.ms/1E91SZd

Modular SGDMA should be included in qsys now. Otherwise here is the link: http://www.alterawiki.com/wiki/modular_sgdma

In the diagram in the link, Read Master and Write Master are connected thru Avalon - ST. Place the DCFIFO in that path.

Hello,

That's nice and looks promising, thank you, I will try this out as soon as possible. Hope this will solve my throughput problem.

Put the dma descriptors into on-fpga memory.

Make sure the dma controller is doing Avalon burst transfers (probably 128 bytes, preferable 64 bits wide) into the pcie txs port.

You probably don't want burst transfers into the SDRAM - just pipelined.

Beware of large fifos in the dma controller - you don't need them.

The pcie txs block seems to complete write transfers quickly. I'm seeing reads take 128 clocks (of the 62.5MHz app clock) + a few clocks for the transfers size.

The same is true of host initiated transfers, writes are 'posted' and happen more or less back to back but there is a 128 clock delay between reads.

The only way to speed up DMA reads from host memory (once you are generating Avalon bursts and thus long PCIe TLP) is to generate concurrent read requests from multiple avalon masters.

krasner,

I've tried doing what you said, using mSGDMA. I think I've done something veeery wrong, because my board actually stopped working until I've reset the BIOS (I even thought I had lost it :( ). Before putting in the FIFOs, I've done the basic scheme, using the dispatcher and the read / write masters.

Here is the qsys scheme I've done for this:

ht tp://1dr v.ms/1IpfnYH

Notice that I've removed the old PLL, and now I'm using the pcie_core_clk, which provides 125MHz, on the DMA and SDRAM. I did that because the TimeQuest said it was not possible to get the 150MHz I was willing for.

I've also uploaded the new qsys on the same folder as before in case someone wants to take a look:

ht tp://1dr v.ms/1E91SZd

dsl,

Where should I put the dma descriptors? I'm very new, so sorry if that's a stupid question.

Notice that I'm not interested in using the onchip memory, but only to speed up the SDRAM. Also, I've tried using bursts but I don't understand how to use it. Everytime I activate burst transfers on the DMA, my host application stops being able to communicate with the FPGA.

Just to clarify, I'm using the Jungo Windows driver provided with the board. It works fine with the DMA scheme I've been using, but I'm getting these slow transfers I've been talking about. Is there any chance that the problem is actually in the driver?

Hope you guys still have some patience to help me.

Many thanks.