Let's think about the case that a master issues a exclusive write transaction to a slave.
On the AXI Specifiaction document, it says that if the slave doesn't support "Exclusive Accesss", then it will always update the target.
But what about the response?
If the slave respond with "OKAY", the master may think that target is not updated. ("OKAY" is error response for the exclusive write transaction)
But, as slave doesn't support "Exclusive Access", it can not respond with "EXOKAY".
How can slave handle this case?
If a slave doesn't support exclusive transactions it will simply treat this as a normal transaction and will both update the target and return an OKAY response.
So the master receiving this OKAY response to an exclusive transaction knows that this is an exclusive failure, and also must then understand that the target WAS updated.
However the protocol does not allow an exclusive write transaction before there has been a matching preceding exclusive read transaction, and as the target slave for that matching preceding exclusive read transaction would also presumably have returned an OKAY response telling the master that it does not support exclsuives, why would your master then attempt the exclusive write transaction, knowing that it must fail, AND that it then has to undo the result of that target being updated ?
Either your master has blindly attempted an exclusive write knowing that the target slave does not support exclusives (because it saw the OKAY response for the earlier matching exclsuive read), or the master is violating the protocol by performing an exclsuive write without a previous matching exclusing read, so both issues that can be fixed in the master design, meaning that you don't then have a scenario where the target slave is updated.
You mean, in this scenario
1. In most case, this scenario will not happen because Exclusive read must precede the Exclusive write.
2. But if the master issues Exclusive write without Exclusive read
1) Slave updates the data
2) Slave responds with OKAY
3) Master notices that Exclusive access is failed
4) Master notices that target is updated, so it may not retry.
But how can the master notices the OKAY response is diffent from the one from the slave that support exclusive access?
As the target is not monitored (No Exclusive read), Exclusive access will fail and the slave will return OKAY response.
But in this case the target is not updated, so the Exclusive access has to be retried.
The protocol does not allow an exclusive write before or without an exclusive read, so it is not a case of "in most case", this just cannot legally happen.
So then all your questions are irrelevant, you won't have to consider them in a correctly designed system.
To answer your questions, the master doesn't know if the OKAY response to an isolated exclusive write indicates the target was updated or not.
But if the master had CORRECTLY attempted an exclusive read beforehand, it would then know if the slave supports exclusives or not, so there wouldn't be any issue as to whether a subsequent exclusive write updated the target.
Can I ask what you are trying to achieve with this illegal sequence that will cause problems ?
I'm just wondering why this document cares about the case that master send an Exclusive write to the slave which does not support Exclusive access.
As you said if exclusvice read always precedes exclusive write, this will never happen.
I think I'm confused because Exclusive Write is permitted to be issued for AHB protocol.
But it is illegal for AXI protocol. Right?
The AHB5 protocol allows an exclusive write without an exclusive read, but it immediately says that this exclusive write must fail and HEXOKAY must be deasserted, so it would be a pointless thing to do.
The AXI spec in this area then seems more sensible in making this an illegal thing to do if it must always fail.
So in AHB5 it is legal (but pointless), and in AXI it is illegal.