 |
Now lets look at the Cache Subsystem, which acts as the central decision-making unit of GCCache.
On the left, you can see the three core functions. First, it determines hits by rapidly validating tag matches. Second, it updates states. Third, it triggers the ORP Subsystem when a cache miss occurs.
On the right, you can see the logic flow. When a request arrives with address and data, it enters the Core State Machine, which coordinates three parallel processing modules:
Hit Processing performs tag comparison and data retrieval.
State Processing handles coherence updates and status checks.
Replacement applies eviction policies and selects cache lines for replacement.
The key design choice here is that these three modules operate in parallel. The Core State Machine synchronizes their results and decides the appropriate action.
If the hit module indicates a cache hit, the state module updates the cache status, and hit information is output directly , achieving very low latency.
If a cache miss occurs, the miss information is sent to the ORP Subsystem to fetch data from the host.
This parallel architecture directly addresses Challenge 3 , the high latency requirement , by ensuring that cache lookups complete within just a few clock cycles. |
IEEE/ICACT20260320 Slide.11
[Big Slide]
[YouTube]