Does TCM configured as Strongly ordered memory have alignment alignment requirements?

Hi experts,

I've been studying the ARM Cortex-R5 Technical Reference Manual and I have some questions about memory region configurations, specifically regarding strongly ordered memory regions.

To clarify, I'd like to know:

1. Do the alignment requirements for strongly ordered memory regions, such as RAM, also apply to Tightly Coupled Memory (TCM)?

2. Are there any specific alignment requirements for TCM when it is configured as strongly ordered?

3. Could you please explain the alignment requirements for strongly ordered memory regions in general, as I want to ensure I understand the concept correctly?

Additionally, I've observed a specific behavior that I'd like to understand:

When I configure OCram (On-Chip RAM) as Strongly Ordered (SO) and perform an unaligned access, a data abort occurs.
However, when I configure TCM as SO and perform an unaligned access, no data abort occurs.
This seems to suggest that the alignment requirements for strongly ordered memory regions may not be enforced in the same way for TCM as they are for OCram.

Could you please help me understand the reasons behind this difference in behavior between OCram and TCM, and provide clarification on the alignment requirements for strongly ordered memory regions in general?

Parents
  • 1 & 2. I think you want this page of the TRM:

    https://developer.arm.com/documentation/ddi0460/d/Level-One-Memory-System/About-the-TCMs/TCM-attributes-and-permissions?lang=en

    Specifically:

    TCMs always behave as Non-cacheable Non-shared Normal memory, irrespective of the memory type attributes defined in the MPU for a memory region containing addresses held in the TCM.

    ...

    Any address in an MPU region with device or strongly-ordered memory type attributes is implicitly given execute-never (XN) permissions. If such an address is also in a TCM region, XN permissions are applied to TCM accesses to that address. None of the other device or strongly-ordered behaviors apply to an address in a TCM region.

    So - no.  The only aspect of Device/Strongly Ordered that would be applied by the MPU is the implicit XN permission.  Beyond that, the region is treated as Normal.  Accesses to Normal regions can, in some circumstances, generate unaligned access faults.

    3. Ignoring TCMs for the moment, accesses to Device and Strongly Ordered regions are required to be naturally aligned to the size of the element being accessed.  For single loads/stores, that's fairly straight forward.  For things like load/store multiples (LDM/STM), they are loading/storing multiple individual word sized quantities - so the alignment is word rather than to the total number of bytes being transferred.

    If you've not already come across it, I suggest you take a look at the R-profile guide: https://developer.arm.com/documentation/den0042/latest

Reply
  • 1 & 2. I think you want this page of the TRM:

    https://developer.arm.com/documentation/ddi0460/d/Level-One-Memory-System/About-the-TCMs/TCM-attributes-and-permissions?lang=en

    Specifically:

    TCMs always behave as Non-cacheable Non-shared Normal memory, irrespective of the memory type attributes defined in the MPU for a memory region containing addresses held in the TCM.

    ...

    Any address in an MPU region with device or strongly-ordered memory type attributes is implicitly given execute-never (XN) permissions. If such an address is also in a TCM region, XN permissions are applied to TCM accesses to that address. None of the other device or strongly-ordered behaviors apply to an address in a TCM region.

    So - no.  The only aspect of Device/Strongly Ordered that would be applied by the MPU is the implicit XN permission.  Beyond that, the region is treated as Normal.  Accesses to Normal regions can, in some circumstances, generate unaligned access faults.

    3. Ignoring TCMs for the moment, accesses to Device and Strongly Ordered regions are required to be naturally aligned to the size of the element being accessed.  For single loads/stores, that's fairly straight forward.  For things like load/store multiples (LDM/STM), they are loading/storing multiple individual word sized quantities - so the alignment is word rather than to the total number of bytes being transferred.

    If you've not already come across it, I suggest you take a look at the R-profile guide: https://developer.arm.com/documentation/den0042/latest

Children
No data