alt_remap_uncached, alt_uncached_malloc?

[Altera_Forum]

Hi,  

 I'm writing to off chip DDR2. My question is should I use either of the alt_remap_uncached or the alt_uncached_malloc functions?  I saw that they use it in the NEEK demo. But I don't understand why.   My driver is stored in on-chip mem, but the video buffers are stored in off-chip DDR2, so I'm not sure if I need those functions for my design.   I should say that my controller worked without these functions, but now that I'm troubleshooting a bigger design, I'd like to know a little more about them.   My guess is that I want to actually use alt_remap_cached for the entire buffer ddr2 memory, so that the processor can cache some of the video buffer data and speed up the stream. Is this correct?   Thanks.

[Altera_Forum]

You need to use uncached addresses when the memory area you want to read/write is also accessed by hardware. It is the case for the frame buffer that is read by a DMA. If you don't use the uncached functions, in some cases the CPU can delay the write operation, and the DMA will read the previous contents of the frame buffer instead of what you just wrote. 

 But if you are writing a lot of data on consecutive words, you can use the CPU cache to speed up things, it will be a lot faster than using the unmapped area. To do that, don't use the unmapped functions and write to the address as usual, and at the end call the flush function. It will ensure that everything is written on the DDR before the hardware reads it. You should also enable the burst transfers from the cache in the Nios II configuration.

[Altera_Forum]

If I'm using a dma to write and another to read, so that hardware is doing both the writes and reads, then is the nios caching any data? 

 If so I guess I should perform a flush every time I initiate the read dma?  I ask because it seems that large chunks, the size of a small display span in memory, seem to be offset in the ddr2 in some magical way. I've gone through my code a million times and I seem to be managing the memory pointers properly, so I know there is something going on behind the scenes. But the cache isn't very big, so it wouldn't be able to offset the memory by that much i wouldn't think.    Thanks for the response.

[Altera_Forum]

No if the software doesn't access the data in any way, caching won't have any influence on the system. You should only flush the cache if the hardware has to read data that the CPU wrote to memory. 

Are you using burst transfers?

[Altera_Forum]

I fixed the bug. It was unrelated to caching as it turns out. I am writing/reading with the DDR2 directly to/from hardware.  

 I was performing a number of separate reads in a row from different addresses in memory, but the sgdma was getting backed up, as the "wait for current read transfer to finish" function I implemented wasn't working. This somehow caused the sgdma module to reverse the order of the read transfers. My solution was changing them to sync read transfers instead of asynch read transfers.   Thanks for your help.