How to invalidate cached data in ARM Core0 without flushing it.

Hi,

Thank you for your inquiry.

The dcache_invalidate() API is fully supported for SHARC processors.

However for ARM processors, the dcache_invalidate() API is currently under development. We are checking with our internal team regarding it's implementation status and asked whether they have any alternate solution for the same.

We will get back to you once we get a response from them.

Best Regards,
Santhakumari.V

Hi,

Thank you very much for your detailed response.
I appreciate you checking with your internal team regarding the implementation status and possible alternatives.

I will await your reply and look forward to hearing from you once you have an update.

Best regards,
MrKK

Hi MrKK,

As Santhakumari said, I'm afraid we do not currently have a production version of that API. We will look to schedule the work for an upcoming release of CCES.

An invalidate without flush is fairly unusual - perhaps you could provide details on what the circumstance is that requires it and we can think if an alternative design is possible?

Thanks,

Michael.

Hi,
Thank you for your reply.

The assumed use case is when the another core (e.g. SHARC Core1 or SHARC Core2) writes data to the L3 memory area, and the own core (e.g. ARM Core0) reads data from the L3 memory area.
If with flashing, it will overwrite the data that other cores or DMA have just rewritten, so we want to invalidate the cache without flashing.
Also, under memory operation environments that are independent of the own core (e.g. multi-core or DMA environments), we understand that performing cache invalidation alone is generally acceptable.
However, we would like to reserve addressing this issue by changing the attributes of a memory region to non-cached as a last resort.

Best regards,
MrKK

Hi,

Thanks for the information. 

A couple of things that might help.

Firstly, when a core writes to memory and the modified data is held in the cache, then the cache line is marked as "dirty". Only dirty lines are written back to L3 memory. So if the ARM is only reading the data, and never modifies it, then a flush-invalidate should operate exactly the same as a pure invalidate, because there are no dirty lines.

However, there is an important corollary to that, and that is that it becomes important to ensure that both the DMA and a core do not write into the same cache line. If that were to happen, there is no solution: a flush would overwrite the DMA-written data, while a pure invalidate would lose the core-written data. So do make sure that your buffers that you write to using DMA are aligned to cache line boundaries, and a multiple of the cache line size. There are macros in sys/platform.h (ADI_CACHE_ALIGN and ADI_CACHE_ROUND_UP_SIZE) that help you do this. You can find a comment explaining their operation in that file.

Hope this helps.

Michael.

Hi,
Thank you for your reply and response.
We would like to organize again using sequence diagrams.

We recognize the memory/cache/read/write flow as shown in the sequence diagram.
In other words, we understand that if invalidation is not performed before reading data, it will not be possible to read the updated data in the L3 memory area.
And we were responded that if the cache line is not marked as "dirty", then a flush with invalidate behaves the same as a pure invalidate.
In conclusion, in the use case shown in the sequence diagram, we understand that the "Invalidate" part of the red arrow in the sequence diagram can be replaced with the following code, but is this correct?

flush_data_buffer(l3_mem_area_start_addr, l3_mem_area_end_addr, ADI_FLUSH_DATA_INV);

Hi,

That should work, but I wouldn't recommend flush-invalidating the entirety of L3 memory, which could take a long time, and would also evict other data from your cache which is not part of your buffers. I would change to flush-invalidating only the buffers being targetted by the DMA, by specifying their start and end addresses in the flush_data_buffer call.

Michael.

Hi,
It took me a long time to confirm what MikeP said, so we are late in replying.

As a result of checking, if access is limited to read only as MikeP said, "flush_data_buffer(l3_mem_area_start_addr, l3_mem_area_end_addr, ADI_FLUSH_DATA_INV);" works exactly the same as pure invalidation.
Thank you for your time and support over the days. Thank you very much.
This concludes our questions.
Also, just to be sure, we have attached the project we used for verification.
Please take a look if you're interested.
7888.InvalidateSample_EngineerZone.zip

Best regards,
MrKK