39e10ced03
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. |
||
---|---|---|
.. | ||
arch | ||
base | ||
cpu | ||
dev | ||
doc | ||
doxygen | ||
gpu-compute | ||
kern | ||
mem | ||
proto | ||
python | ||
sim | ||
unittest | ||
Doxyfile | ||
SConscript |