Hi Malek, I think the term "blocking" is confusing because it's really an overloaded term. There's a distinction is between blocking CPUs and blocking memory systems, and they are distinct.
As you say below, a TimingCPU is a blocking CPU and only has one outstanding instruction going at a time. However, since GEMS is a coherence modeling infrastructure, obviously you take best advantage of it by running a CMP simulation or a multisocket simulation, where there are multiple CPUs. A blocking *protocol* is a protocol that essentially blocks on actions to an address that is in a transient state, e.g. in the process of writing back and not in a stable state like M/O/E/S/I. So, you could have a blocking protocol with a non-blocking CPU, for example, because they are talking about blocking totally different things (insts vs. addresses), e.g. the CPU has multiple memory operations outstanding, all being satisfied by the memory system, but once two CPUs try to do things to a *single* address that are in conflict, then operations on that address across the system become serialized. Even if you have blocking CPUs and a blocking protocol, you can still have multiple requests (up to N for N CPUs) flowing through Ruby, and the protocol will not block unless there is an issue with two of the CPUs accessing the same address in a conflicting way. I hope that helps and makes sense. Lisa On Mon, Mar 21, 2011 at 1:21 PM, Malek Musleh <malek.mus...@gmail.com>wrote: > 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 > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
