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 ‘bufferable’, 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.
View all questions in Embedded forum