In AXI protocol we have write response at the end of write transactions.
Whereas in read transaction we are providing response in each beat of transfer why is so?
Can we provide the read response at the end of the transaction same as write response?
For each of the AXI channels the flow of information is one direction, so for the AW, AR and W channels the flow is master to slave, and for R and B the flow is slave to master.
So for the R channel we already have a slave-master flow direction, with accompanying handshake signals, to easily support passing responses for each read data transfer.
But for the W channel we do not have any slave-master flow of information, so no easy way to pass back a response to each data transfer, without adding a new channel, which is what the B channel gives us.
To avoid unnecessary traffic, we don't pass a B channel response back for each W channel transfer, as typically if a transaction were to fail you would repeat the entire transaction (if one transfer fails it is likely that all would fail), so no performance advantage to know which or how many of the write transfers in a transaction failed. If a slave were to decide just one transfer in a transaction had a problem, you could consider adding a "fault status" type register to the slave to indicate what the problem was for the master's abort handler to interrogate.
The same "if one fails it is likely all would fail" arguement applies for the R channel, but as we already have the existing RVALID/RREADY handshakes and traffic flow for each transfer, returning a RRESP response for each data transfer was no additional effort or increase in complexity.
For read transaction, you COULD return default OKAY responses on RRESP for each individual transfer, and use just the final RRESP return to provide the real response for the entire burst, with the master then fixing whatever the problem was before repeating the entire transaction again. That would be a valid thing to do, but why not just return real responses to each transfer as it happens (probably simpler as you have that live information available at the time, rather than having to store it until the final transfer of the transaction).
It depends on the settings. You can provide a read response at the end of the transaction if you set this feature in the settings. I made the following settings for the page. Everything worked.
There is no setting to determine when a read response is returned in the AXI protocol. The protocol requires that a response is returned for EVERY transfer.
Are you referring to a specific AXI slave design in this reply TimothyPolini ?
- If yes, the AXI protocol would still require a response to be returned for every transfer in the transaction, but your slave implementation might then be giving a default OKAY response for all but the final transfer response, when a response for the overall transaction is generated by the slave, which is what I suggested in my first reply to this question.
- But to support this the AXI master requesting this transaction must also need to understand what this response means, so it isn't a standard solution applicable to all designs.