Sukarn, This is indeed a protocol issue in terms of correctness. This has already been fixed (Change-Id: I1e7b2c05439d08579c68d8eb444e0f332e75e07f on gerrit), reviewed and added to main repository.
Best, *Pouya Fotouhi* Graduate Student Department of Electrical and Computer Engineering University of Delaware Newark, DE 19716 On Wed, Jan 30, 2019 at 6:23 AM Sukarn Agarwal <[email protected]> wrote: > Hi, > > > Similar to this issue, there is also a confusion (may be i am wrong, > please correct me on this) in the transition: > > > transition({IS, S_IL0, M_IL0, E_IL0, MM_IL0}, {Inv, Fwd_GETX, Fwd_GETS}) { > z2_stallAndWaitL2Queue; > } > > > > The Inv event with state IS will make the deadlock situation in some of > the parsec benchmarks. The actions for state IS on event: Inv may be like > this: > fi_sendInvAck; > l_popL2RequestQueue; > > Thanks and Regards, > Sukarn Agarwal > IIT Guwahati > > ------------------------------ > *From:* gem5-users <[email protected]> on behalf of Shirshendu > Das <[email protected]> > *Sent:* Wednesday, January 30, 2019 1:58:04 PM > *To:* [email protected] > *Subject:* [gem5-users] Issue in MESI Three Level Protocol > > Dear All, > I was trying to understand the SLICC code for *MESI_Three_Level* > protocol. During the process, I have found an issue in the protocol. Please > correct me if I am wrong. > > *Caches in three level protocol:* L0 (Private), L1 (Private) and L2 > (shared). > *The issue:* The issue is between L1 and L0. When a forwarded GETS > request arrives at L1 (say L1-x) from any other L1 (say L1-y) via L2, the > block is evicted from the local L0 (L0-x) before forwarding it to the > requesting L1 (L1-y). In my understanding, a shared block should not get > evicted from L0-x before forwarding the block to L1-y under forwarded GETS > request. > > The following code is from *MESI_Three_Level_L1.sm*. In this code, in > case of *in_msg.Type == **CoherenceRequestType:GETS,* if the block is in > L0 then *trigger(Event:L0_Invalidate_Else, in_msg.addr,.....)* is called > to invalidate the block from L0. > > in_port(requestNetwork_in, RequestMsg, requestFromL2, rank = 2) { > .................................. > if (in_msg.Type == CoherenceRequestType:INV) { > if (is_valid(cache_entry) && > inL0Cache(cache_entry.CacheState)) { > trigger(Event:L0_Invalidate_Else, in_msg.addr, > cache_entry, tbe); > } else { > trigger(Event:Inv, in_msg.addr, cache_entry, tbe); > } > } else if (in_msg.Type == CoherenceRequestType:GETX || > in_msg.Type == CoherenceRequestType:UPGRADE) { > if (is_valid(cache_entry) && > inL0Cache(cache_entry.CacheState)) { // If the block is in L0 then remove > it. > trigger(Event:L0_Invalidate_Else, in_msg.addr, > cache_entry, tbe); > } else { > trigger(Event:Fwd_GETX, in_msg.addr, cache_entry, tbe); > //This line is forwarding block directly from L1. > } > * } else if (in_msg.Type == CoherenceRequestType:GETS) {* > if (is_valid(cache_entry) && > inL0Cache(cache_entry.CacheState)) { *// If the block is in L0 then > invalidate it.* > trigger(Event:L0_Invalidate_Else, in_msg.addr, > cache_entry, tbe); > } else { > trigger(Event:Fwd_GETS, in_msg.addr, cache_entry, tbe); > //This line is forwarding block directly from L1. > ............................................. > > The *MESI_Three_Level_L0.sm* has transitions for f*wd_GETS* and > *fwd_GETX,* but from my understanding, such transitions will never occur > in L0 as L1 is not sending appropriate CoherenceRequest to L0. The *Actions > *written in *MESI_Three_Level_L1.sm *are not forwarding any > *CoherenceClass:GETS* message to L0. The *Actions* written in L1 ( > *MESI_Three_Level_L1.sm*) are only sending *CoherenceClass:INV* request > to L0 (*MESI_Three_Level_L0.sm*). > > Thanks and Regards, > Dr. Shirshendu Das > Assistant Professor, > Department of CSE, > Indian Institute of Technology Ropar, Punjab, India > http://cse.iitrpr.ac.in/shirshendu/shirshendu.html > Ph: 9435277250 > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
