A special cache model called g-cache-ooo is provided with Simics MAI to handle multiple outstanding transactions and out-of-order execution. It is very similar to g-cache described in Simics User Guide so we describe here only the differences that are introduced by the special MAI requirements.
Although g-cache and g-cache-ooo have a very similar interface (in terms of attributes and commands), they do not handle transactions in the same way. Whereas g-cache takes care of a transactions in one pass, computing all the penalties and performing all the state changes as the transaction goes through its different phases, g-cache-ooo tries to present a more credible model for out-of-order execution. Each phase of a transaction in the cache is considered and handled separately. A transaction may trigger a copy-back that will last some cycles, then a fetch will be sent to the next level stalling the cache for some more cycles, and finally the result will be returned. During these phases, g-cache-ooo ensures that other transactions behave in a sensible manner: for example, if two transactions want to fetch the same cache line, the second transaction is considered as a delayed hit and its value will be returned when the first (missing) transaction is completed; cache lines are locked as long as the transaction using them is on-going.
g-cache-ooo supports the same options as g-cache except:
Some new, MAI specific features have been introduced:
g-cache-ooo can be used with any Simics configuration, even without MAI. However, since it relies quite heavily on the ability to stall transactions to handle state changes, only stallable transactions are considered cacheable. If you want to warm-up your caches with a normal run and wish to include transactions that are normally not stallable (and thus not cacheable) like x86 instruction fetches, you should: