diff options
author | Joel Hestness <jthestness@gmail.com> | 2016-04-15 12:34:02 -0500 |
---|---|---|
committer | Joel Hestness <jthestness@gmail.com> | 2016-04-15 12:34:02 -0500 |
commit | 39e10ced035a7e1f53673fc998741f8b6067135d (patch) | |
tree | 481fd83c90f869034215115504d8eb5128e9a384 /configs/example/memcheck.py | |
parent | edbf748181bdd3ac86838e7c55d98a336b285e01 (diff) | |
download | gem5-39e10ced035a7e1f53673fc998741f8b6067135d.tar.xz |
ruby: Fix block_on behavior
Ruby's controller block_on behavior aimed to block MessageBuffer requests into
SLICC controllers when a Locked_RMW was in flight. Unfortunately, this
functionality only partially works: When non-Locked_RMW memory accesses are
issued to the sequencer to an address with an in-flight Locked_RMW, the
sequencer may pass those accesses through to the controller. At the controller,
a number of incorrect activities can occur depending on the protocol. In
MOESI_hammer, for example, an intermediate IFETCH will cause an L1D to L2
transfer, which cannot be serviced, because the block_on functionality blocks
the trigger queue, resulting in a deadlock. Further, if an intermediate store
arrives (e.g. from a separate SMT thread), the sequencer allows the request
through to the controller, and the atomicity of the Locked_RMW may be broken.
To avoid these problems, disallow the Sequencer from passing any memory
accesses to the controller besides Locked_RMW_Write when a Locked_RMW is in-
flight.
Diffstat (limited to 'configs/example/memcheck.py')
0 files changed, 0 insertions, 0 deletions