AXI Wrap Bursts

>do we have round to lower or upper value.

Wraps have to be aligned - so address 55 is not a legal address for 32-bit beat (must be 4 byte aligned). So it can't happen - a master should never generate the transaction.

If you had an aligned 32-bit wrap of 4 beats starting at address 0x4 then you would get the following access pattern:

0x4, 0x8, 0xc, 0x0

The wrap boundary is considered 0xf in this case.

Cheers, Iso

A wrap start address **must** be beat-aligned. It is illegal for a master to make an unaligned wrap request - it wouldn't be AXI conformant.

There are two kinds of alignment in a wrap:

Start_Address needs to be aligned on the beat-size, so for a 32-bit beat it needs 4-byte aligned, 16-bit beat needs to be 2-byte aligned, etc. In this case your start address (55) is not a valid Start_Address for a 32-bit beat  - ..., 52, 56, 60, 64, ... would be OK for example.

> Aligned_Address = (INT(Start_Address / Number_Bytes) ) x Number_Bytes.

Aligned_Address is the lowest address accessed by the wrap - and it is aligned on a boundary which matches the total number of bytes in the burst. So beat-size * number-of-beats. For a burst with 8 x 32-bit beats the Aligned_Address would be 256-bit aligned.

Using my example earlier. If you had a 32-bit wrap of 4 beats starting at address 0x4 then you would get the following access pattern:
0x4, 0x8, 0xc, 0x0

Start Address = 0x4
- this is allowed as it is aligned on a beat boundary.

Aligned_Address = (INT(0x4 / 0x10)) * 0x10 = INT(0.25) *0x10 = 0 x 0x10 = 0
- this is allowed as it is aligned on a total_bytes boundary.

Note that INT() is a C style cast - it always truncates decimal parts (rounds down).

However, assuming a start address of 56 the following calculation would apply:

Burst Len = 32-bit beat * 4 beats = 16 bytes

Aligned address:
= INT(56 / 16) * 16
= INT(3.5) * 16
= 3 * 16
= 48

Wrap boundary:
= highest byte accessed in burst
= 48 + 16 -1
= 63

Access Pattern:
= 56, 60, 48, 52