Arm Community
Site
Search
User
Site
Search
User
Groups
Education Hub
Open Source Software and Platforms
Research Collaboration and Enablement
Forums
AI and ML forum
Architectures and Processors forum
Arm Development Platforms forum
Arm Development Studio forum
Arm Virtual Hardware forum
Automotive forum
Compilers and Libraries forum
Graphics, Gaming, and VR forum
High Performance Computing (HPC) forum
Infrastructure Solutions forum
Internet of Things (IoT) forum
Keil forum
Morello forum
Operating Systems forum
SoC Design and Simulation forum
SystemReady Forum
Blogs
AI and ML blog
Announcements
Architectures and Processors blog
Automotive blog
Graphics, Gaming, and VR blog
High Performance Computing (HPC) blog
Infrastructure Solutions blog
Internet of Things (IoT) blog
Operating Systems blog
SoC Design and Simulation blog
Tools, Software and IDEs blog
Support
Arm Support Services
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Support forums
Embedded forum
Puzzled by conflict in spec regarding memory types for AxCACHE bits
Jump...
Cancel
State
Accepted Answer
+1
person also asked this
people also asked this
Replies
1 reply
Subscribers
139 subscribers
Views
3173 views
Users
0 members are here
Options
Share
More actions
Cancel
Related
How was your experience today?
Puzzled by conflict in spec regarding memory types for AxCACHE bits
Linda C.
over 3 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 3 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...