Re: [gem5-dev] Ruby: Token Coherence and Functional Access

2011-06-13 Thread Beckmann, Brad
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


[gem5-dev] Ruby: Token Coherence and Functional Access

2011-06-10 Thread Nilay Vaish
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