With a support entitlement you can also get direct access to our team of highly-qualified Arm experts 24-hours a day
Open a support case
In AXI4, spec changed the definition of the definition of AxCACHE[3:2] from Write Allocate/Read Allocate to be Allocate/Other Allocate.
But is there any concrete reason for this change? Actually I found some related statements from spec, but I couldn't get the point.
"The change to the definition of AxCACHE means that these signals can differ for a read and write transaction to the same location."
Does it mean with this change, we can distinguish the transaction type (i.e., read/write) from AxCACHE signal? However, from memory type encoding, the AxCACHE of "Read and Write-allocate" are the same for both read and write transactions.
I would think that the main point in this change, from reading section A4.3.3, is that AXI4 added new scenarios where the cache could have been previously allocated.
For a read transaction, the AXI3 "Write Allocate" bit would indicate that the cache location might have been allocated by an earlier write transaction. AXI4 adds that the cache location could also have been allocated because of the actions of another master (so a read or a write by the other master).
So as this other master could have caused a read from this cache location, "write allocate" is no longer a precise name, and so the bit is renamed "other allocate", a name that is meaningful for both the AXI3 and AXI4 conditions it could signal.
So for the "signals can differ" comment...
In AXI3 where you were only looking at allocation based on what this one master could do, so perhaps just "write-allocate", so AxCACHE[3:2] would be 2'b10 for both reads and writes.
However in AXI4 we have the possible scenario that this master only wants "write allocate", but other masters could also allocate, so AWCACHE[3:2] is 2'b11 ("write allocate" set and "other allocate" set) and ARCACHE[3:2] is 2'b10 ("other allocate" set but "read allocate" not set).
Referring to "A4-5 Memory type encoding", it does show that the ARCACHE and AWCACHE encodings CAN still be the same, but they also show an alternative value where the bits are not the same.