unaligned transfers

Hi Colin,

Thank you for your response.

Right, AXI protocol allows unaligned transactions, but this does not mean that it worth using this feature, this significantly complicates all system; all memories/interfaces must support unaligned transactions. If memories support such accesses, performance is much lower compared to regular accesses.

Maybe you are right, but there is option 3 - unaligned access handled by core with L1 cache. In this case, the system interfaces, and memories (like DDR, higher-level memories) should not support/see unaligned access.

In more detail:
Unaligned access to Cacheable write-back memory space - store/load miss access in L1 cache in any case issue read aligned access to the system. Means value of the address (AxADDR) is a multiple of the size of the data being transferred (AxSIZE). In your example, the 32-bit unaligned transaction will be fetched by the L1 cache as 32 bytes (cache line size) with address 0.

Unaligned access to device memory is not supported.

Unaligned access to normal non-cachable memory can be issued as aligned access by core or by L1 caches. For example, the 32-bit unaligned read transaction can be sent to the system as an aligned 64-bit transaction (better option) or 2x32-bit transactions, core/L1 cache decides which data part to use. For write, use aligned write + write strobes.

This solution gives better bus/memory performance and utilization versus Unaligned access support in system memories and interfaces and also does not complicates the system.

Hi Colin,

Thank you for your response.

Right, AXI protocol allows unaligned transactions, but this does not mean that it worth using this feature, this significantly complicates all system; all memories/interfaces must support unaligned transactions. If memories support such accesses, performance is much lower compared to regular accesses.

Maybe you are right, but there is option 3 - unaligned access handled by core with L1 cache. In this case, the system interfaces, and memories (like DDR, higher-level memories) should not support/see unaligned access.

In more detail:
Unaligned access to Cacheable write-back memory space - store/load miss access in L1 cache in any case issue read aligned access to the system. Means value of the address (AxADDR) is a multiple of the size of the data being transferred (AxSIZE). In your example, the 32-bit unaligned transaction will be fetched by the L1 cache as 32 bytes (cache line size) with address 0.

Unaligned access to device memory is not supported.

Unaligned access to normal non-cachable memory can be issued as aligned access by core or by L1 caches. For example, the 32-bit unaligned read transaction can be sent to the system as an aligned 64-bit transaction (better option) or 2x32-bit transactions, core/L1 cache decides which data part to use. For write, use aligned write + write strobes.

This solution gives better bus/memory performance and utilization versus Unaligned access support in system memories and interfaces and also does not complicates the system.

Hi Norbert,

I do agree with virtually everything you write, an L1 cache can simplify things to some extent, and will usually improve master performance.

But where I still disagree is that unaligned access support complicates designs. As I mentioned previously slave (unless they are read sensitive) can ignore any AxADDR/AxSIZE misalignment. For write transactions the slave will see WSTRB indicate which byte lanes contain valid data (and this always needs checking because transfers can be sparse as well as unaligned), and for read transactions the slave can just return ARSIZE aligned data and let the master use the byte lanes it requested.

So the best option of all is for the SW to think of alignment when accessing data, but where the SW is not so tightly controlled you can use an L1 to improve performance and avoid unaligned accesses, and/or you support unaligned accesses when they are required, knowing that these don't complicate slave designs (unless your slave is also not supporting WSTRB), especially for non-cacheable transactions which should bypass the L1.

I'm not saying you are wrong, it's just that an L1 cache is not the only solution. As your Cortex-A master probably has an L1 it will reduce the occurence of unaligned transactions being needed to the memory system, but they are not a complication for slaves to support when they are needed.