Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

strange speed for DMA transfer

Hi guys,

I got my DMA transfer running on a DE2-115 board, from off-chip SDRAM to off-chip SRAM.

The data to transfer was 0.5M 32-bit word type, just enough to fill the 2MB SRAM on the board. The burst option of the DMA was disabled. Everything was clocked at 50 MHz through a PLL.

I used a performance counter core to measure the transfer speed, and got an amazing reading of 400 us, 20048 clocks, which means in a single clock cycle there were 0.5M/20048=26words transferred, which I don't believe at all !!!

I also tested the performance core with usleep() function, and found the core work fine. So why did I get such a weirdly high speed reading of DMA transfer? My understanding is that DMA makes one transfer (with defined data width) every clock cycle, isn't it?

The data was transferred correctly, although it was a simple array from 1 to 524288 (2^19).

Any input is appreciated !

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Yes at most the DMA will transfer one world per clock cycle, so yes there is something strange.

    What DMA did you use? Some DMAs have a limit on the number of words they can transfer. Are you sure that all 2Mb were actually transferred?

    Are you sure that you wait until the DMA transfer is finished before triggering the performance timer? If set in asynchronous mode, the function that starts the DMA transfer will return before the transfer is actually complete.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    Yes at most the DMA will transfer one world per clock cycle, so yes there is something strange.

    What DMA did you use? Some DMAs have a limit on the number of words they can transfer. Are you sure that all 2Mb were actually transferred?

    Are you sure that you wait until the DMA transfer is finished before triggering the performance timer? If set in asynchronous mode, the function that starts the DMA transfer will return before the transfer is actually complete.

    --- Quote End ---

    Thanks for the input. I am using the DMA core from Qsys, not the SGDMA. The maximum transfer size in byte allowed by the DMA is 2^32. So I think 2MB is not over that limit.

    I cleared the data in SRAM before transfer data into it. Through step by step debug, I could see from the memory monitor that the data in SRAM was refreshed by the newer value, and I also have a comparison function to compare the result.

    As for the performance core, I started it before I post the transmit and receive request, and stopped it after the receiver set a bit saying the data has been received. I also set up an output test port with the same start and stop time and monitored it with an oscilloscope. And the results of the performance core and the oscilloscope met with each other...

    The only thing I can think of is the asynchronous mode you mentioned. But I didn't find related information in the description of DMA... How can I verify this?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    If you are using the DMA driver where you map a callback when the IRQ fires then maybe you are not measure the transfer time (just the setup time of the DMA). So normally with the driver the DMA is started and when the interrupt occurs a function (of your choosing) gets called when the DMA completes (IRQ fires).

    In other words if you are just measuring the time it takes for alt_dma_txchan_send() and/or alt_dma_rxchan_prepare take to complete then you are not measuring the total transfer time since those are non-blocking calls.