This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Additional Control Information Questions

Hi. I recently got the ARM AMBA specification in my work, and now I am learning stuffs. But the Additional control information got me stuck for a day haha

My questions are

1. What is the reason to use the Cacheable bit in the Cache support? I wish I could get the example In real industry standard.

2. When reading the speicfication on the Cacheable bit, they say the multiple write can merge together in multiple writes. I cannot catch the viivd picture on this situation. Does this mean the several master can write the data on cache? can i get some real life example so that I can visualize the real problem with this write section?

3. I want to check whether I understand right in read section. So if the read happens with the cacheable bit flag HIGH, it means the data which the Master wants to read from the memory could be cached in the cache nearby the Master. And the principle of the Cache getting the data nearby the address which the Master asks to the Slave get applied here so some are 'pre-fetched' in the Cache. Is this right to understand what the specification explains??

What I feel while writing this question is that all understanding I have right now is all wrong. I feel like I got a wrong start move from the beginning.

  • 1. The cacheable bit was renamed the modifiable bit in AXI4, which is a more accurate name for its intended function.  In an actual system, its used to differentiate between an access to Normal memory or Device memory. 

    Normal memory offers higher performance, but relies on the fact that there are no requirements on various attributes of the access, such as the size, or whether it needs to propagate all the way to main memory.  DDR memory is an example of Normal memory.

    Device memory is used for accesses where we care about various attributes of the access being preserved.  For example, Device memory cannot be used speculatively, and may require that the size, length and number of accesses is preserved.  It also often requires that the access is sent all the way to its final destination, before a response can be sent back.  Peripheral registers are considered to be Device memory.

    In effect, this means that Normal memory can be cached, for example in a local CPU cache (hence this bit being named Cacheable), and does not need to propagate to main memory in order to complete.  Device memory cannot be cached, and responses need to come from the final destination.

    2. Since this bit indicates whether an access is to Normal memory, it determines whether this memory location is fussy about the attributes of the access being preserved.  If this location is not particular about the size or number of accesses, then the system can attempt to improve the efficiency of the accesses by merging multiple acceses together.

    For example, a CPU might make four 64 bit writes to a sequential group of locations.  Downstream in the system, the data bus width is actually 128 bits.  These accesses can potentially be merged meaning that the four 64 bit accesses is the equivalent of two 128 bit accesses.  This is more efficient as we're now using the full data bus width, and the access may only require two clock cycles to transfer the data, instead of four cycles.

    3.  Partially yes, but I think it makes more sense if you consider Normal and Device accesses.  An address with this bit high would mark as Normal memory, which means it could potentially be cached.  The line about prefetching really refers to whether an access can be performed speculatively or not - where a Device access would not allow this.

  • Could you please clarify two terms specified in the spec: "Memory type" and "Transaction attributes" both of them refer to AxCHACHE signals.

    If I'm correctly understand the "Memory type" specifies characteristic of memory attached to the slave port. It can be Normal or Device, Cacheable, etc.

    ------

    Your understanding of memory types is correct.  The transaction attributes include the memory type and all the other information encoded on the Ax channels.

    What I do not understand how master port can handle the behavior of memory through AxCHACHE signals? For example what happens if Master issues Write-back Read and Write-allocate transaction to the memory which physically doesn't have caches?

    Or each Master must know the type of memory in the Slave and send only correct transactions?

    ------

    Fundamentally, yes the master does need to know the nature of the slave that it's targeting.  If it's performing a register access, then the memory type should be Device.

    It also needs to be ensured that all the masters in the system are accessing the same region with the same memory attributes, as otherwise memory consistency could be lost.  For example, a Device access to region would not access any caches, and so might not see a cacheable write to the same region.

    As it happens, the example you give wouldn't be a problem.  If a master issued an allocatable cacheable access to a region that didn't have a cache, then the allocation hints would just be ignored and the access would be made to and from main memory.