AHB/AHB-LITE/AHB_5 How to handle Last transfer error of a BURST Transaction ???

The main point for your first question is remembering that AHB transfers occur in two phases; the address phase and the data phase.

The address phase is when the AHB manager tells the system about the transfer it is requesting, and in this case when it drives HTRANS for each transfer in the burst.

This is then followed by the data phase in which the AHB subordinate responds to the manager's request, and drives HREADY and HRESP to indicate how that requested transfer is completing.

Then looking at the final transfer in a burst, once the final address phase is signalled, HTRANS could change to IDLE (or it could move on to start a new burst). The final data phase completes a pipelined cycle later than final address phase, so while HTRANS might now be IDLE, the data phase completing relates to that previous SEQ transfer in the burst, and so any ERROR response in this cycle refers to that last requested SEQ transfer from the burst, not the current HTRANS value.

So yes, if the subordinate needs to return an ERROR response to the final transfer in a burst, it should do so, and the AHB manager needs to be checking data phase responses for the currently completing data phase transfer as well as driving new address phase requests for whatever it needs to do next. The manager needs to be aware of both the current data phase transfer as well as the next transfer address phase.

Note also that there is no "should enter the IDLE state" in response to an ERROR. The manager has the choice of cancelling the new transfer address phase HTRANS type to IDLE, or it can ignore the ERROR and just keep HTRANS unchanged (treating the 2 cycle ERROR response as a wait state).

The behaviours described for ERROR responses have not changed in any of the AHB protocol releases, so the original IHI 0011A AHB protocol shows this in figure 3-14, and the later IHI-0033A, B and C releases for AHB-lite and AHB5 show this in figure 5-1. I guess your confusion with the original release figure 3-14 might be that it does not show when HTRANS could change to IDLE (the "Control" bus does not include HTRANS), but this would be in the 2nd of the 2-cycle ERROR response, as you can see in the previous figure 3-13 which does include HTRANS, showing the timing for a RETRY response (the bus timing is the same for both RETRY and ERROR).

Both figures show an initial wait state being added by the subordinate before it decides that a 2-cycle ERROR response is required, but this is not necessary and the subordinate could have gone straight to the 2-cycle ERROR response.

I tried to have a look at your waveforms but they were too small to be able to easily follow what was happening (my eyes are not as good as they used to be). But one thing I did spot was that you were using HMASTLOCK high for some of the transfers. Are you performing ATOMIC operations here that must be locked together, or were you asserting HMASTLOCK for another reason ?

The main point for your first question is remembering that AHB transfers occur in two phases; the address phase and the data phase.

The address phase is when the AHB manager tells the system about the transfer it is requesting, and in this case when it drives HTRANS for each transfer in the burst.

This is then followed by the data phase in which the AHB subordinate responds to the manager's request, and drives HREADY and HRESP to indicate how that requested transfer is completing.

Then looking at the final transfer in a burst, once the final address phase is signalled, HTRANS could change to IDLE (or it could move on to start a new burst). The final data phase completes a pipelined cycle later than final address phase, so while HTRANS might now be IDLE, the data phase completing relates to that previous SEQ transfer in the burst, and so any ERROR response in this cycle refers to that last requested SEQ transfer from the burst, not the current HTRANS value.

So yes, if the subordinate needs to return an ERROR response to the final transfer in a burst, it should do so, and the AHB manager needs to be checking data phase responses for the currently completing data phase transfer as well as driving new address phase requests for whatever it needs to do next. The manager needs to be aware of both the current data phase transfer as well as the next transfer address phase.

Note also that there is no "should enter the IDLE state" in response to an ERROR. The manager has the choice of cancelling the new transfer address phase HTRANS type to IDLE, or it can ignore the ERROR and just keep HTRANS unchanged (treating the 2 cycle ERROR response as a wait state).

The behaviours described for ERROR responses have not changed in any of the AHB protocol releases, so the original IHI 0011A AHB protocol shows this in figure 3-14, and the later IHI-0033A, B and C releases for AHB-lite and AHB5 show this in figure 5-1. I guess your confusion with the original release figure 3-14 might be that it does not show when HTRANS could change to IDLE (the "Control" bus does not include HTRANS), but this would be in the 2nd of the 2-cycle ERROR response, as you can see in the previous figure 3-13 which does include HTRANS, showing the timing for a RETRY response (the bus timing is the same for both RETRY and ERROR).

Both figures show an initial wait state being added by the subordinate before it decides that a 2-cycle ERROR response is required, but this is not necessary and the subordinate could have gone straight to the 2-cycle ERROR response.

I tried to have a look at your waveforms but they were too small to be able to easily follow what was happening (my eyes are not as good as they used to be). But one thing I did spot was that you were using HMASTLOCK high for some of the transfers. Are you performing ATOMIC operations here that must be locked together, or were you asserting HMASTLOCK for another reason ?