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
