Date: | Mon, 2 Oct 2006 20:40:11 +0200 |
---|---|
From: | Enrique Vallejo Gutiérrez <enrique@xxxxxxxxxxxxx> |
Subject: | Re: [Gems-users] Regarding memory consistency issues |
Title: RE: [Gems-users] Regarding memory consistency issues
Mike, thank you for your quick reply. I know that GEMS is a Timing-first simulator, and then, strictly, this would not be possible. However, what confuses me is that, if DATA_BLOCK==true, then %GEMS/Rruby/module/ruby.c registers the Simics "snoop-memory" interface. This interface, according with the Simics Programming Guide, can be used to modify the result of loaded values. Thus, the timing interface models the timing of the request and the snoop interface can model the final value of the request. Also, in the SLICC code for the MESI LogTM protocol, there are callbacks like: sequencer.readCallback(address, getCacheEntry(address).DataBlk), which returns a value depending on the data held in the m_dataBlk member. However, I am not 100% sure about all this.
My problem is that I would like to simulate a system in which there might be several different speculative values for the same address, on different cache controllers. Obviously, this can not be directly implemented in Simics, due to the single global memory image. The different values should be held on the Ruby caches, and a snoop interface should be used to make Simics detect a value different from the global one. Also, this might have some effects on the consistency model; this is where the original questions came from.
Has anyone ever tried something similar? Any help would be appreciated. Thank you in advance, Enrique Vallejo University of Cantabria, Spain
-----Mensaje original----- High-level point: GEMS is a "timing first" simulation environment. Ruby/Opal can do whatever we want them to do, however Simics will always execute sequentially consistent. In other words, Ruby and Opal could try ot model the _timing_ of a non-sequentially consistent execution, but there would be no feedback to Simics because Simics is always executing SC. If Opal violates SC (which it can), then this will be detected and Opal will "reset" itself. If this happened quite often, then Opal would not be an effective timing model. But since it is extremely rare, the overall effect on target simulation time is next to nothing. That said, I do not believe that GEMS is the right tool to study the subtle execution effects of more relaxed consistency models. --Mike > > So, my main questions are: > - Can Ruby really model a different memory consistency model, or would > Simics "break down" in case of any SC violation? I have checked that LogTM > protocols hold cache data, but I don't know how to make a quick test about > the memory consistency model presented (Something like TSOTool or similar). > The ideas in the previous paragraph are what I understand from the code, but > I am not 100% sure about it. > - What about Ruby + Opal? Opal's Readme file states that only SC memory > orderings are allowed as registers are checked against Simics, but Simics > load results can be modified by Ruby, which might allow for other (TSO) > consistency models. I am not sure if the snoop_device interface is installed > when both Opal and Ruby are loaded. > - In conclusion, can Ruby be used to study different consistency models > performance? > > I would appreciate if anyone could correct any wrong ideas in this > mail, and could give some hints on his own experience. > > Thanks in advance, > > Enrique Vallejo > University of Cantabria, Spain > _______________________________________________ Gems-users mailing list Gems-users@xxxxxxxxxxx https://lists.cs.wisc.edu/mailman/listinfo/gems-users Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search. |
[← Prev in Thread] | Current Thread | [Next in Thread→] |
---|---|---|
|
Previous by Date: | Re: [Gems-users] Regarding memory consistency issues, Mike Marty |
---|---|
Next by Date: | Re: [Gems-users] Regarding memory consistency issues, Mike Marty |
Previous by Thread: | Re: [Gems-users] Regarding memory consistency issues, Mike Marty |
Next by Thread: | Re: [Gems-users] Regarding memory consistency issues, Mike Marty |
Indexes: | [Date] [Thread] |