• State Not Answered
  • Replies 1 reply
  • Subscribers 142 subscribers
  • Views 16960 views
  • Users 0 members are here
Options
Related
How was your experience today?

Why AXI4 changed the definition of AxCACHE?

Yu-Hsin

Hi,

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.

Thanks.

  • 0

    Hello Yu-Hsin,

    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.

    Colin