Stream to Memory sgdma problem

Thanks for your response BadOmen.

I did use a ping pong approach (I think). I first stream 1600 bytes of data into onchip memory "DAQ1_MEM" with the stream-to-memory sgdma called "CWstream_DMA1", and when that completes, the callback function "CWstream1_callback_function" starts to move that data into DDR3 with the memory-to-memory sgdma called "DDR3_DMA". While the DDR3 memory-to-memory transfer is happening, the second stream-to-memory sgdma "CWstream_DMA2" starts to stream 1600 bytes of data in onchip memory "DAQ2_MEM". Again, when CWstream_DMA2 is done gathering its data, the callback function "CWstream2_callback_function" starts the memory-to-memory sgdma "DDR3_DMA" to move the data into the next location of DDR3 memory.

You are correct to mention the race condition, because one has to make sure that the callbacks and transfers into DDR3 can finish before one of the streaming sgdma's are done. I found that the length of time of these callbacks and transfers is dependant on cpu speed, code memory location, and probably a bunch of other stuff. I used signal tap to look at some flags I set up (LED_PIO) in the callback functions to see when the transfers finished to make sure I didn't run into a condition where callback when happening out of order.

I'm using the cyclone V dev kit and run the entire NIOS based system on a 50 MHz clock. I spread the 1600 byte stream-to-memory transfers over a 100 ns time period to give the callbacks and transfers enough time. This setup essentially allows me to sample 8 x 16 bit waveforms at 1 MHz. I think I can double the amount of waveforms if I pushed it further.

Thank again for your comments BadOmen, and I appreciate any more comments or discussion.