i read the specification of AXI 4 protocol. i want to know what action will be performed by the master when it receive okay,exokay,slverr or decerr. okay and exokay says that the transfer is completed either by normal access and by the exclusive access, so i think master doesn't have to perform any special thing but if response is slverr or decerr at that time master has to do something either it will reject data transfer request or it can re-initiate the transfer.
is it possible to stop the burst transfer after receiving either slverr or decerr?
what i know is the in axi we can't stop the burst transfer while transfer is going on. so is it possible that someone tell me what master has to do on each response error?
Firstly in AXI it isn't possible to stop bursts, the indicated number of data transfers on AxLEN must be completed. Note that the AXI master only sees a write response AFTER the burst of data transfers has completed, so it is only in the case of reads that a master could know an error response has been received before the end of the burst of data transfers.
AHB/AHB-lite supported early burst termination in a limited number of cases, but no such thing in AXI.
So when a master receives a SLVERR or DECERR response, and has completed the AxLEN number of transfers, it depends on the application what the master next does.
In a development system you can use the error indication to stop the system and debug what has gone wrong, so that hopefully you can fix that issue so that it doesn't happen again.
In a final application, hopefully errors are rare, but when they do occur what you can do might depend on why you got that response.
One improvement in error reponses in AXI compared to the older AHB protocols is that you now know whether the error originated in the destination slave (SLVERR) or the interconnecting logic (DECERR).
A DECERR response could then indicate that the master tried to access a slave that didn't (currently) exist, so perhaps a powered down clock domain. So the master needs to get a system controller to enable that clock domain ? Or the interconnecting logic needs to be reconfigured so that the expected slave appears at that address (simple address decoding issues).
A SLVERR response tells the master that the slave was "unhappy" with the attempted transaction, so then there might be less the master can do, those actions really depending on why the slave gave the SLVERR notification.
The master COULD just re-initiate the same transaction following an error response, but unless you know that the cause of the error might no longer exist, all you might expect is a repeat of the error response.
Either error response could require a system reset if the cause of the error cannot be determined or corrected, but one final option is that the master might just ignore the error, either because it doesn't now need that requested data (for example instruction prefetches no longer required) or because it expected that response (perhaps using a burst to access a range of registers, one of which it knows is not physically implemented).
There isn't any exact answer that you can get for this question, the reason why the error was signalled is too system specific, and the master's possible response to that error is also then very system specific, so the above is the best "generic" reply I can come up with.