DMA Dropouts

[Altera_Forum]

Hi all, 

I'm just bringing up our first Cyclone Nios II board and all is going pretty well. however I do seem to have a small problem with a DMA transfer.  I've got a user peripheral with a second slave port that supports streaming for DMA transfers (reads). Now the only thing directly connected to this slave port is the main DMA channel. The dma is also a write master of the system SDRAM along with the other usual suspects (namely the CPU).   Now the streaming interface works correctly however it is hammering out data quite fast. In fact the system clock is 75MHz and the device collects 16 bit data at 30MHz. So to give the system a break I interleave the 16 bit data and deliver one 32 bit word every 5 processor clock cycles. This still seemed to cause a few problems with the DMA loosing data due to the intermediate FIFO overflowing (I've got a small 64 deep fifo coming out of my perihperal) with the standard arbitration settings. So the DMA has been given priority 12 compared to 1 for access to the SDRAM and now there are no missing data elements, (i.e. I request 6000 words and I get that many transfers). The DMA is typically used to transfer about 6000 32bit words in two blocks, the period of the transfers is one burst of 3000 words in 125uS followed by another burst of 125uS separated 150uS apart.   so to the problem When I clear a block of memory and set up a DMA transfer to it from the DMA port the data is transferred and the DMA completes however when I look at the data I typically find a block of zeroes where no data has been written by the DMA. I've verified this with signal tap looking at the data coming out of my peripheral and also through the DMA controller. Everything seems to come out intact. The DMA correctly increments the write address but it is like nothing is written. Sometimes the patchy area will move around after recompiling the hardware and sometimes the software but it typically occurs about half way through the written data.  I'm unsure of the cause. I did think that maybe the SDRAM reshresh cycle was killing the DMA but surely the interblock gap should allow enough time for that. Or is this a bug with the SDRAM controller?  Regards,  DW

[Altera_Forum]

Hi cybdenw, 

i had a similar problem, but in my situation the problem was the CPU data cache: in fact i didn't read the data written by the DMA in the SDRAM, but the CPU used the data cache instead of accessing SDRAM. Moreover I had to use dynamic memory allocation (malloc) to pass the buffer address where to write data, to the DMA...

[Altera_Forum]

Hi There, 

Yes I did read your thread and several others before posting. There is no particular reason why the DMA should store the transferred data via the dcache (which of course it doesn't) so the only reason why I should get data dropouts is if, when reading from SDRAM, the cpu thinks it has cached data for some of the locations. now I can discount that since I have a 4096 word dache however the dropouts do not occur until at l.east half way through the data, i.e. this implies that the dcache will well and truly have been flushed by the process of accessing and printing out the contents of the first 4-5000 elements.  So unlikely to be this, I'm really leaning towards a bug/issue with the SDRAM controller when writing sustained data burts from a dma controller. It just seems that the DMA ignores some combination of wait requests and carries on counting up its write address register.

[Altera_Forum]

Hi cybdenw, 

a stupid question: do u use IORD() to read the content of data written by the DMA? or what?

[Altera_Forum]

Any resolution to this problem? I'm seeing something very similar when doing successive transfers from an external device. 

 Ryan