In AXI Why there is a read response in each data transfer?

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).

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).