I'm having trouble with interpreting the AHB specification regarding what should happen when two pipelined non-burst transactions are both expected to fail (in my test I am generating transactions such that they both should be seen as invalid by the slave).
In Figure 5.1 of the specification, I understand that a correct error response to transaction A is given between T2 and T4, and that transaction B is cancelled.
However, I am not sure that what is the reason why transaction B is cancelled:
Is it cancelled due to HTRANS == IDLE in T3-T4, or is it cancelled implicitly due to the error response to transaction A?
Should the master always issue HTRANS = IDLE when an error occurs, and a second transaction (B in this case) that is known by the master to be in its address phase while an error in the transaction that immediately precedes it is signaled?
Should the master expect transaction B to always fail when transaction A fails?
Suppose that in T3-T4, HTRANS was not equal to IDLE, and I expect that transaction B should be rejected by the slave, should I expect a second error response, in the same manner as in transaction A (T1~T3)?
The first thing to say is that the master has the option to cancel the next transfer "B", or it can continue with "B" and just treat the ERROR response as a wait state on the bus. The protocol I think refers to continuing with the burst, but the burst bit is irrelevant and it just allows the master to ignore the ERROR for "A" and move on to "B".
The reason why we might need to cancel "B" is to preserve the order of events on the bus. Usually code will want access "A" to complete before "B", so if "A" has failed you don't want "B" to be seen by the target slave, and the 2-cycle ERROR response allows the master to cancel "B" at T3 and instead convert it to an IDLE transfer before it is seen by a slave at T4 when HREADY is driven high.
But the protocol also allows the master to continue with the next transfer because in some cases this might be what the application would want. For example if "A" and "B" are in the same burst, the exception handler code in the master might find it easier to handle any ERROR (or ERRORs) knowing that the defined length burst completed (so the ERROR isn't ignored, just noted for later handling). Or the other common scenario is that the ERROR response is being returned to a write transfer that was described as bufferable (HPROT[2]=1) which means that the transfer could have come from an intermediate buffer component, and any ERROR response returned would be meaningless to the original master as it received an OKAY response from the buffer and the master has now moved on to other operations (no way of knowing which transfer the ERROR relates to).
For your question about whether the master should expect "B" to fail if "A" failed, no. If "A" and "B" are in the same burst, it is probable that they would both fail (there is no slave implemented at the specified address range), but it could just be that "A" addressed a non-existent register in a slave address map, and "B" is implemented, so OKAY. If "A" and "B" are to two completely independent addresses (not in the same burst), there is no suggestion that "B" would fail just because "A" did.
For your final "Suppose" scenario, this is exactly what the protocol allows, the master continuing with the next transaction even though "A" received an ERROR response. Hopefully this question is answered in the previous paragraph.
So in summary, the master can choose to cancel "B" to preserve the order of events on the bus, but it also has the option to continue with the next indicated transfer "B" if the application prefers.