Re: [Gems-users] Shared memory access on multicores

[Dan Gibson <degibson@xxxxxxxx>]

Simics does not model a bus. Instead, Simics assumes there is a single, global memory, and one processor at a time has access to that memory. Only one processor is ever 'running' at a time, and the running processor can do whatever it pleases with the memory. Simics round-robins between processors every cpu-switch-time cycles (we set this parameter to 1, usually). Hence, when two processors access the same location "in the same cycle", the accesses actually occur in two different 'simics cycles', and the race is always resolved in a manner that respects sequential consistency.

As an aside, this behaviour gives rise to one of the key tricky reasons why RUBY_CYCLES is not identically equal to Simics cycles * SIMICS_RUBY_MULTIPLIER, and why using RUBY_CYCLES is the preferred runtime metric.

On top of that interface, Ruby forces stalls in Simics to try to do a better job of modeling realistic interconnects, caches, protocols, etc., but the actual memory model is still SC.

Regards,
Dan

Cihat Basol wrote:

Hi,

What happens in simics (i.e. sunfire machine configuration without timing model) when more than one processor has a memory access to a shared-memory at the same cycle?
What if the access is for the exact location in the shared memory?

Does simics assume every processor can freely access any memory and location as if it is only one accessing everything including the bus?

Does memory access requires bus access in simics?
If yes, how does the arbitration happens when multi processors connected to the same bus, performing a memory access?


Thanks,
Cihat.

_______________________________________________
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.

  

-- 
http://www.cs.wisc.edu/~gibson [esc]:wq!