Can anyone help me if re-order can also affect write transaction?
example>
AXI3 or 4
multiple outstanding depth : 4
When there is 4 AW and W (with wlast) transactions occured and waiting for the responses, can slave give a response to the latest one before giving responses to previous ones?
Can re-order depth affect this? For example, when re-order depth is 2, slave can give responses to the first 2 transactions only.
Thank you so much for your answer. It helped me a lot. I was wondering about this since I was not able to find related statements in the specification (IHI0022E). What I was able to see was only about read operation for re-ordering. Can you please let me know which statement is mentioning about this?
Section A5.3, 2nd bullet point, states that transactions with different IDs have no ordering restrictions, so covers this slightly. The 4th bullet point talks about writes specifically, and says that writes with the same ID must complete in order, which implies that writes using different IDs can complete out of order.
Section A5.3.3 then talks in more detail about write interleaving, so again with different IDs you can see interleaved write data traffic, and this would then allow one WID stream to complete before an earlier started different WID stream.
My earlier reply is trying to take all the info that is available and reword it in such a way that it specifically addresses your questions, so I can't always give you exact references as the points I made come from a number of areas.
Looks like I was not clear on my question point. My apologies. I didn't mean to ask you about all the behavior related to that. I was just wondering how re-ordering can affect write operation even though the specification only describes about read re-ordering. Looks like it is just implied. Thank you.
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.