why use unaligned transfers in AXI

I think my feelings agree with your's here, I don't see a need for unaligned transaction support from a hardware perspective.

However this is possibly more from a software perspective, with the SW not always caring about data alignment (hence unaligned addresses coming out on the bus), so the AXI protocol is trying to support the unaligned transactions the SW suggests, converting them into HW transactions that can be performed.

For write transactions you do have the WSTRB information which tells you exactly what data is valid, so the alignment of the start address is largely unimportant, so whether or not the interface between SW and HW aligns this address really doesn't matter, it's the WSTRB value that specifies exactly what needs to be written.

But for read transactions we don't have strobes, so although the slave being addressed will probably just return an aligned data value, some slaves might be able to use the unaligned address value (I am guessing here, I don't have an example in mind).

So whether or not we signal an unaligned address from the master probably doesn't make any difference to the HW, but as we know the SW required start address, it might actually be simpler just to signal this value instead of trying to align it, and who knows, there might be a slave that can use the actual SW address alignment information for something.

If it was me designing with the AXI protocol I would just ignore the actual address alignment and for writes I would look to WSTRB to see what data is valid. AWADDR (ignoring the unaligned LSBs) then just tells me the start address for the transfer. And for reads I would just design a slave to drive the full ARSIZE width requested for the ARADDR (again ARSIZE aligned) value - although I suppose some might argue that I could save power by not driving some lower byte lanes for a read access when I can see the ARADDR start address tells me I don't need to (so a trade-off between design simplicity and power consumption).

Sorry for the vague answer.

I think my feelings agree with your's here, I don't see a need for unaligned transaction support from a hardware perspective.

However this is possibly more from a software perspective, with the SW not always caring about data alignment (hence unaligned addresses coming out on the bus), so the AXI protocol is trying to support the unaligned transactions the SW suggests, converting them into HW transactions that can be performed.

For write transactions you do have the WSTRB information which tells you exactly what data is valid, so the alignment of the start address is largely unimportant, so whether or not the interface between SW and HW aligns this address really doesn't matter, it's the WSTRB value that specifies exactly what needs to be written.

But for read transactions we don't have strobes, so although the slave being addressed will probably just return an aligned data value, some slaves might be able to use the unaligned address value (I am guessing here, I don't have an example in mind).

So whether or not we signal an unaligned address from the master probably doesn't make any difference to the HW, but as we know the SW required start address, it might actually be simpler just to signal this value instead of trying to align it, and who knows, there might be a slave that can use the actual SW address alignment information for something.

If it was me designing with the AXI protocol I would just ignore the actual address alignment and for writes I would look to WSTRB to see what data is valid. AWADDR (ignoring the unaligned LSBs) then just tells me the start address for the transfer. And for reads I would just design a slave to drive the full ARSIZE width requested for the ARADDR (again ARSIZE aligned) value - although I suppose some might argue that I could save power by not driving some lower byte lanes for a read access when I can see the ARADDR start address tells me I don't need to (so a trade-off between design simplicity and power consumption).

Sorry for the vague answer.