Arm Community
Site
Search
User
Site
Search
User
Support forums
Embedded and Microcontrollers forum
Puzzled by conflict in spec regarding memory types for AxCACHE bits
State
Accepted Answer
+1
person also asked this
people also asked this
Replies
1 reply
Subscribers
142 subscribers
Views
4053 views
Users
0 members are here
Options
Share
More actions
Related
How was your experience today?
Puzzled by conflict in spec regarding memory types for AxCACHE bits
Linda C.
over 4 years ago
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?
Top replies
Linda C.
over 4 years ago
+1
verified
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...
0
Quote