• State Accepted Answer
  • +1 person also asked this people also asked this
  • Replies 1 reply
  • Subscribers 139 subscribers
  • Views 3190 views
  • Users 0 members are here
Options
Related
How was your experience today?

Puzzled by conflict in spec regarding memory types for AxCACHE bits

Linda C.
Table 4.5 which describes the Memory Type encodings is pretty clearly specified. There are 11 encodings specified and below the table it says all non-specified encodings are reserved. Looking at the table, you can see that the 'Other Allocate bit' is associated with cacheing, either write-through or write-back. The "Allocate" bit is associated with allocate vs no-allocate when caching is enabled. I also observe that the "Allocate" bit is never set unless the 'Other Allocate" bit is set. Bit 0, the 'bufferable' bit is really only indicating bufferability when caching is disabled (bits [3:2] are zero.
What confuses me is that Table 4.3 "ArCache bit allocations" and Table 4.4 "AwCache bit allocations" describe the 4 bits in a one-hot fashion. But this is not really the case, as the bufferable bit (bit0) is used to indicate write-through vs write-back when the allocate bit is set (per Table 4.5). Also the text of Table 4.3 says regarding "Allocate" bit "The transaction must also be looked up in a cache if AwCache[2] is asserted", where AwCache[2] is the "Other allocate" bit. This implies that "Allocate" can be asserted when "Other Allocate" is deasserted which contradicts the spec statement below Table 4.5 that this particular encoding is reserved. For example, 0110 is not a valid encoding for ArCache.
My main question is, should we ignore Table 4.3 and 4.4? They imply that the bits are one-hot and bits 2 & 3 just mean you should cache the transaction. Thus implying there is no support/no encodings left for allocate vs no-allocate or write-through vs write-back.
Tables A4-3 and A4-4 also mention the "Other allocate" bits exist because of transactions from "another master". What does this mean, and how do we interpret the affect of it?
Finally, can anyone explain why the modifiable bit is set in all the encodings of Table 4.5 except for when caching is disabled?
Parents
  • +1

    I have a way to interpret the tables A4-4 and A4-4 now which resolves some of my questions and I’m posting here in case other people have these same questions in the future.

    Although the table is structured in a way to suggest that bit 0 means ‘buffer    able’, the description in Tables A4-3 and A4-4 does say that it doesn’t mean ‘bufferable’ for certain encodings.

    Although the descriptions for Allocate and Other Allocate are nearly identical, they cause caching to be enabled for different reasons. Allocate is a caching feature so it makes sense you must look up in the cache when allocate is requested. “Other allocate” means some previous transaction had performed an allocate (put something in the cache) so this transaction should get it from the cache too.

    When Table A4-5 says “Allocate” is only set if “Other Allocate” is also set, with instruction to treat “Allocate set, Other Allocate clear” as RESERVED. But Tables A4-3 and A4-4 instruction to treat this case as if both were set, this is not so obvious how to resolve. However, you could guess that the author of Table A4-3 and A4-4 wants to describe a design which is AXI3 backwards compatible, in which case the “Allocate set, Other Allocate clear” case is not reserved.

    Any comments on this interpretation is welcomed.

Reply
  • +1

    I have a way to interpret the tables A4-4 and A4-4 now which resolves some of my questions and I’m posting here in case other people have these same questions in the future.

    Although the table is structured in a way to suggest that bit 0 means ‘buffer    able’, the description in Tables A4-3 and A4-4 does say that it doesn’t mean ‘bufferable’ for certain encodings.

    Although the descriptions for Allocate and Other Allocate are nearly identical, they cause caching to be enabled for different reasons. Allocate is a caching feature so it makes sense you must look up in the cache when allocate is requested. “Other allocate” means some previous transaction had performed an allocate (put something in the cache) so this transaction should get it from the cache too.

    When Table A4-5 says “Allocate” is only set if “Other Allocate” is also set, with instruction to treat “Allocate set, Other Allocate clear” as RESERVED. But Tables A4-3 and A4-4 instruction to treat this case as if both were set, this is not so obvious how to resolve. However, you could guess that the author of Table A4-3 and A4-4 wants to describe a design which is AXI3 backwards compatible, in which case the “Allocate set, Other Allocate clear” case is not reserved.

    Any comments on this interpretation is welcomed.

Children
No data