Re: [Gems-users] Regarding memory consistency issues

[Mike Marty <mikem@xxxxxxxxxxx>]

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
>