WRoenninger
commented
1 year ago Thank you. Just seen this issue, has been I while I looked at the code.
The cache was written in the notion that only physical addresses are used to access it. The main operating principle breaks each axi access from upstream down into multiple descriptors which operate exclusively on a single cache-line. When I say cache line, it is determined the memory address as well as the respective set/way/bank of the data store.
The check for eviction happens serially for all accesses in the axi_llc_hit_miss module. There it is determined what needs to happen to a specific line in the cache. So if it needs to be refilled evicted etc. In any case a descriptor will lock the cache-line until it has processed all required operations downstream (the descriptor is finished processing in either the read or write unit). The lock is saved in a bloom filter for space saving reasons.
So for your example what is intended to happen:
- The cache line is invalidated from the first descriptor before the second descriptor is allowed into the hit_miss unit so the second will try to fetch new data as it finds no valid in the tag store.
- If the second descriptor wanting to refill selects the same cache-line, it is locked from the previous eviction going on and waits in the hit_miss unit until the previous descriptor is finished. Then proceed to refill and operate on the line.
- If it selects a different way/set it will lock the respective cache-line and follow the previous descriptor into the evict/refill pipeline.
- The pipeline structure consists of the evict unit followed by the refill unit. So the first descriptor enters the eviction unit and flushes downstream. The first descriptor will stay in the eviction unit until it receives the B response from downstream.
- Meanwhile the second descriptor trying to refill the same data waits in the eviction unit behind the currently evicting descriptor.
- If the first is finished, it traverses the refill unit and does it's operation for the upstream access.
- The second descriptor enters the refill unit afterwards and finds the previously flushed line in the downstream memory. This is because the first descriptor waited until it got the B response from downstream. Then proceeds to access the data in the read or write units when the refill has taken place.
So to summarize all decisions on what to do is done in the hit_miss unit, everything that follows is done serially in FIFO fashion. If there is a clash on the cache line a descriptor is stalled in the hit_miss unit. Refill and eviction accesses downstream are done on the same ID so that there is no reordering,
Hope this helps ;)
panbin1207
I coundn't find a place to feedback so I use issue. If it is bad, please delete it.
Hi,
Firstly, an excellent job!
I have a question about evicting. Currently, according to the document, I suppose there is no address matching check in evict unit. Consider a situation, that a cache-line is evicted and a following request is pointing to the same physical address. Do we need to check whether that address is in "evict writing" or not. Because the downstream is also AXI and if we don't check it, a same address reading will be dispatched and might get old data. So I would like to know how the design manages this situation.
Best wishes.