Can re-order depth affect functionality of write transaction?

Moving forward, AXI4 doesn't support write data interleaving, so all write data transfers for each transaction must appear at the destination in the order the write address transfers arrived (regardless of the transfer ID).

This was done because it was found that interleaving write data just made destination component interfaces a bit more complex, and the destination then had to de-interleave the write data streams. A more common solution implemented in systems was to buffer write data at source before it was transmitted in one continuous stream of transfers, so then there were not gaps in the data that would allow for interleaving to increase bandwidth usage.

Write transactions can still complete "out of order" if the B channel responses are returned in a different order to that of the AW channel transfers, but I'd struggle to think of an application where the destination of the write transfers might then see an advantage in doing so as it gets all the write data in order.

Read data interleaving is still supported in AXI4, I guess because an interconnect could be receiving data from multiple sources, so could make better use of available bandwidth if those read data sources were not supplying data in continuous streams.

The difference here compared to write interleaving is that the destination of these read data transfers is the transaction initiating component, where you can expect more complexity (if it can send out transactions with different IDs, it can presumably receive requested data for any of those pending transactions). The same can't always be assumed for transaction destination components.

Moving forward, AXI4 doesn't support write data interleaving, so all write data transfers for each transaction must appear at the destination in the order the write address transfers arrived (regardless of the transfer ID).

This was done because it was found that interleaving write data just made destination component interfaces a bit more complex, and the destination then had to de-interleave the write data streams. A more common solution implemented in systems was to buffer write data at source before it was transmitted in one continuous stream of transfers, so then there were not gaps in the data that would allow for interleaving to increase bandwidth usage.

Write transactions can still complete "out of order" if the B channel responses are returned in a different order to that of the AW channel transfers, but I'd struggle to think of an application where the destination of the write transfers might then see an advantage in doing so as it gets all the write data in order.

Read data interleaving is still supported in AXI4, I guess because an interconnect could be receiving data from multiple sources, so could make better use of available bandwidth if those read data sources were not supplying data in continuous streams.

The difference here compared to write interleaving is that the destination of these read data transfers is the transaction initiating component, where you can expect more complexity (if it can send out transactions with different IDs, it can presumably receive requested data for any of those pending transactions). The same can't always be assumed for transaction destination components.