Altera_Forum
Honored Contributor
Honored Contributordcache questions, bug in alt_dcache_flush
The alt_dcache_flush function from the hal may not correctly flush all dirty data in the cache. Consider the case where I want to flush the contents of a video buffer that is larger than the data cache.
const alt_u32 VideoRamSize = 38400; BYTE videoRam[VideoRamSize]; alt_dcache_flush(videoRam, sizeof(videoRam)); The current hal implementation uses the flushda instruction. If the data cache size is 8k the function limits the address range that may be flushed to the first 8k of the videoRam buffer (comment: "This is the most we would ever need to flush"). If the buffer was modified beyond this range and these addresses are cached they will not be flushed. This results in a screen full of garbled pixels. I changed the hal function to use the flushd instruction as in earlier versions. Then everything works as expected. One can also comment out: len = NIOS2_DCACHE_SIZE; now flushda also works but this leads to more iterations in the for loop. Could someone explain how flushd really works? In alt_dcache_flush(void *start, alt_u32 length) flushd is passed an address and in alt_dcache_flush_all an index starting at 0. Is there a way to invalidate an address range in the cache even if it is never modified by the processor? In my case some component other than the processor continuously writes data to a memory buffer. A program running on the NIOSII reads this data for further processing. So the data is never dirty from the processor's point of view. I would like to force the processor to invalidate any cached addresses from this buffer before starting a read-out cycle. If I read the documentation correctly the flushd instruction won't work and I have to use the IORD_32DIRECT macro. Are there any recommendations what cache line size to use depending on the data cache size and application type?
