In the description of the modifiable transaction in section A4.3.1 of the AXI4 protocol, there is a paragraph that reads as follows:
"The memory attribute, AxCACHE, can be modified, but any modification must ensure that the visibility of transactions by other components is not reduced, either by preventing propagation of transactions to the required point, or by changing the need to look up a transaction in a cache. Any modification to the memory attributes must be consistent for all transactions to the same address range."
Regarding this paragraph, I have three questions:1. Does delaying the propagation of a transaction in a cache in an intermediate component for a long time reduce the visibility of that transaction to subsequent components?2. If a transaction that originally required a cache lookup is modified after passing through an intermediate component to no longer require a cache lookup, does this reduce the visibility of that transaction at the system-level cache?3. In terms of design, is a FIFO commonly used for handling bufferable transactions?
Hi there, thanks for asking a question. Please can you look at the list of Forums that we have here:https://community.arm.com/support-forums/ and let me know where to move your question to?
Moved thanks.
Not sure I can answer all of your questions, but I'll have a try.
The point about not changing the visibility of a transaction for other downstream components is to avoid an intermediate component changing a transaction AxCACHE type to be less strictly controlled.
For example if the originating CPU states a transaction is non-modifiable and non-bufferable, a downstream component can't change that to a less strict modifiable or bufferable description as that is not what the CPU allowed. A modifiable transaction can be made non-modifiable, or a bufferable transaction made non-bufferable, but not the other way round.
This ensures that if the CPU wanted a transaction to go all the way downstream to destination memory (to read real data and not cached data, or to write data to memory for all to see and not have it cached at a mid-way point), no intermediate component will change that CPU requirement.
If an intermediate component changed a non-modifiable or non-bufferable transfer type, that transfer could then be delayed from reaching further downstream (waiting for a cache line eviction or write buffer to drain), which leads on to your first question.
1. Yes, if you delay a transaction by storing it in a cache, it won't appear downstream until that cache line is evicted, meaning all downstream logic has reduced visibility of that updated cache line data (no visibility until the cache line is evicted).
2. Looking at the opposite case of a transaction changing from modifiable (cache lookup required) to a "normal" or "device" type where no lookup is required, this can improve visibility for downstream components if there was a cache between the component that change AxCACHE and these downstream components. Visibility of this transaction is improved for others because this cache is bypassed.
3. For bufferable transactions, a component does not have to buffer them, but if it does then the implementation of the buffering could be a FIFO, or it could just be memory with read and write pointers cycling round the buffer memory. So functionally operating as a FIFO, but the actual implementation is left for the designer to choose.
Hopefully that answers some of your questions.
Thank you for your reply, it was very helpful to me.