[Gems-users] LogTM and L1 cache simulation

[Kevin Moore <kmoore@xxxxxxxxxxx>]

GEMS-LogTM users,

It has recently come to our attention that the LogTM code instructions 
and documentation fails to mention an important limitation of the LogTM 
simulator: the target system L1D cache latency is the same as the L2 
cache latency.  Many thanks to Dan Nussbaum for pointing out this 
discrepancy.
The released version of LogTM instructs users to set the ruby flag
"REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH" to true.  By default, memory 
requests that hit in the L1 cache bypass the protocol actions specified 
in the slicc files.  This flag disables that "fast path" and forces 
ruby to pass all memory requests through the protocol engine. 
Previously, LogTM protocols relied on this property to ensure that R & 
W bits were properly set for all transactional memory accesses. As 
discussed previously on this list, disabling the fast path causes 
non-CMP ruby protocols to treat L1D hits as L2 hits.  Although the data 
cache is simulated, its latency is the same as that of the L2.
We are currently testing a patch that will allow fast path accesses in 
the two LogTM protocols (MESI/MOESI_SMP_LogTM_directory).  We plan to 
release this update as soon as we complete our testing.
Thank you,

Kevin