Hi ...
In the Cortex-R5 TRM, there are some restrictions for the AXI.
Such as, no transaction ever crosses a 32-byte boundary in memory for AXI transfer.
Is there any restriction for Cortex-R52 ?
Per our test of Cortex-R52, for the same code, if the code cross two cache line address range will spend much more time than within one cache line address range when I cache is disabled.
BR
Grace
Hi Grace，
I went through R52 TRM, and not found any words about AXIM alignment restrict （guess you had do the same thing already）； thus my guess is R52 has no such restrict.
The reason why you see code spend more time if the code cross the cache line when I-Cache disabled, guess maybe R52 issue cross 32-btyes transfer but fabric may split them to two aligned xfer thus CPU suffering some more penalty.
B.R
Jerry
Hi Jerry
Thanks for your reply.
Why do you think it's 32-byte ?
I have new findings from Cortex-R52 TRM:
All WRAP bursts fetch a complete cache line starting with the critical word first. A burst does not cross a cache line boundary - AXIM section of R52 TRM.
Also, there are the same words in the flash interface section of R52 TRM.
Does the burst mean all the transactions on AXIM interface. If so, I can understand that all transactions on AXIM interface cannot cross a cache line boundary - 64bytes.
Here is my understanding.
#1. Usually WRAP xfer for NORMAL cacheable memory only. Let's say CPU want to read 0x1018. AXIM interface may issue WRAP access （start w/ 0x1018）, once the word at 0x1018 retrieved, CPU been feed and AXIM interface keep fetching to 0x101f then wrap to 0x1000， and put all data into one cache line. The benefit here is CPU be responded much earlier. Please be noticed that in the whole process, the access not crosses a 32-byte boundary (AKA, the cache line size)
#2. If cache disabled, let's assume CPU read 32 bytes from 0x1018; here is what happened on AXIM: read 8 bytes from 0x1018， then issue another xfer to read 24 bytes from 0x1020. If read 32 bytes from 0x1000， then AXIM just need one AXI xfer： read 32bytes from 0x1000.
Hope it helps.