Yes, the token protocol is definitely one of those protocols that prevents us
from tightly coupling the functional access support to the protocols. However,
I don't this issue will result in silently corrupted behavior. Instead, it
seems the result would be an error generated in the simulation, correct?
Specifically in the example you mention, all controllers are in the stable
Invalid state, right? Therefore, the functional access won't find a valid
block anywhere, and an error will be generated. That seems like the right
behavior to me.
Brad
-Original Message-
From: gem5-dev-boun...@m5sim.org [mailto:gem5-dev-
boun...@m5sim.org] On Behalf Of Nilay Vaish
Sent: Friday, June 10, 2011 8:50 AM
To: gem5-dev@m5sim.org
Subject: [gem5-dev] Ruby: Token Coherence and Functional Access
Brad, in the token coherence protocol, the l2 cache controller moves from
state O to I and sends data to the memory. I think this particular transition
is
may pose a problem in enabling functional accesses for the protocol. The
problem, I think, is that both the directory and the cache controller are in
stable states even though there is data travelling in the network. This means
that both the controllers will allow a functional write to go ahead. But then
the data will be over written by the value sent from the l2 controller to the
directory controller.
My understanding of the protocol implementation is close to \epsilon. I think
this is what I observed today in the morning. Do think this understanding is
correct?
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
