18.6 Using g-cache
Let us have a more detailed look at g-cache. It has the
- Configurable number of lines, line size and associativity. Note that the
line size must be a power of 2, but the only restriction on the cache structure
is that the number of lines divided by the associativity must be a power of
- Physical/virtual index and tag.
- Configurable write allocate/write back policy.
- Random, true LRU or cyclic replacement policies. It is
easy to add new replacement policies.
- Sample MESI protocol.
- Support for several processors connected to one cache.
- Configurable penalties for read/write accesses to the cache, and read/write
accesses initiated by the cache to the next level cache.
- Cache miss profiling.
Transactions are handled one at a time; all operations are done in order, at
once, and a total stall time is returned. The transaction is not reissued
afterward. Here's a short description of the way g-cache handles
a transaction (we assume a write-back, write allocate cache):
- If the transaction is uncacheable, g-cache ignores it.
- If the transaction is a read hit, g-cache returns
penalty_read cycles of penalty.
- If the transaction is a read miss, g-cache asks the
replacement policy to provide a cache line to allocate.
- The new cache line is emptied. If necessary, a copy-back transaction is
initiated to the next level cache. In this case, a penalty of
penalty_write_next is counted, added to the penalty returned by
the next level.
- The new data is fetched from the next level, incurring
penalty_read_next cycles penalty added to the penalty returned by
the next level.
- The total penalty returned is the sum of penalty_read, plus
the penalties associated with the copy-back (if any), plus the penalties
associated with the line fetch.
Note the usage of penalty_read/write and
penalty_read/write_next: a write-through cache would always take a
penalty_write_next penalty independently of the fact that a write
is a hit or a miss, but g-cache always reports hits and misses
according to the line lookup, not based on the fact that a transaction is
propagated to the next level.