Hi, 1) I was wondering if the MESI_CMP protocol is currently implemented as a 'blocking' protocol, similar to how the MOESI_CMP version is.
I see that on this link on the GEMS page that it indicates that the MOESI_CMP one is blocking, but doesn't indicate anything about the MESI_CMP version. http://www.cs.wisc.edu/gems/doc/gems-wiki/moin.cgi/Protocols?action=fullsearch&context=180&value=blocking&titlesearch=Titles In the MOESI_CMP Version there are coherenceResponseType Messages such as 'Unblock' / 'Exclusive_Unblock' which seems to enforce the blocking aspect, and I also see these types in the MESI version, but just implementing them does not necessarily enforce blocking in all possible situations. 2) Even if the MESI version is non-blocking, because Ruby only currently works with the Timing CPU Model, only one request can be issued to the memory model at a time anyway (and I believe the CPU stalls anyway until that request COMPLETES), but generally is it possible to have multiple outstanding/in progress in the ruby memory model even though Timing CPU is Blocking? For example, can Core 0 do a STORE X to L1 as L1 does a writeback of Data: Y to L2? I suspect no, that in a blocking Cache Coherence Protocol I cannot do that, but just wanted to confirm. Malek _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
