The MMU-500 supports the AXI3 and AXI4 protocols when the sysbardisable_<tbuname> input signal is tied HIGH. In this mode, the following AXI3 features are not supported:
- Write data interleaving
Write data and write address ordering must be the same, otherwise data corruption can occur.
- Locked transfer
The input interface on a TBU contains only one bit of the AWLOCK and ARLOCK signals to ensure compliance with the AXI4 specification. Therefore, locked transfers are not supported even when the sysbardisable_<tbuname> signal is HIGH.
- The WID signal generation
The MMU-500 does not generate the WID signals for the TBU write data channels because these signals are not required for AXI4 and ACE-Lite modes. You must add logic to generate the WID signal based on the WID signal values that are used for the address channel transfer, and use the values for each write data channel transfer for a transaction.
The MMU-500 does not support write data interleaving. Therefore, the MMU-500 generates write data transfers in the sequence that the write addresses are issued.
Example 2.2 shows a scenario to generate the WID signal.
At the slave interface, you can connect the WID signal to the WUSER signal. At the master interface, you can generate WID by connecting WID to the same bit positions of the WUSER signal as at the slave interface.
See the ARM® AMBA® AXI and ACE Protocol Specification AXI3, AXI4, and AXI4-Lite ACE and ACE-Lite for more information about the WID and WUSER signals.
- Unused ACE-Lite ports
If an AXI3 interface is connected to an ACE-Lite port, then the unused ACE-Lite signals must be tied off to the values shown in Table 2.2.
- Normalization of memory attributes
The ARMv8 architecture generates a normalized version of the memory attribute. See Table 3.8.
By programming the SMMU_SACR.NORMALIZE bit, you can enable the normalization support.
You have to enable the normalization support only when the MMU-500 is instantiated in the ARMv8 system.