24.16.6.2. gem5 crossbar interconnect
Crossbar or XBar in the code, is the default CPU interconnect that gets used by fs.py if --ruby is not given.
It presumably implements a crossbar switch along the lines of: https://en.wikipedia.org/wiki/Crossbar_switch
This is the best introductory example analysis we have so far: gem5 event queue TimingSimpleCPU syscall emulation freestanding example analysis with caches and multiple CPUs. It contains more or less the most minimal example in which something interesting can be observed: multiple cores fighting over a single data memory variable.
Long story short: the interconnect contains the snoop mechanism, and it forwards packets coming form caches of a CPU to the caches of other CPUs in which the block is present.
It is therefore the heart of the Cache coherence mechanism, as it informs other caches of bus transactions they need to know about.
TODO: describe it in more detail. It appears to be a very simple mechanism.
Under src/mem/ we see that there is both a coherent and a non-coherent XBar.
In se.py it is set at:
if options.ruby:
...
else:
MemClass = Simulation.setMemClass(options)
system.membus = SystemXBar()
and SystemXBar is defined at src/mem/XBar.py with a nice comment:
# One of the key coherent crossbar instances is the system # interconnect, tying together the CPU clusters, GPUs, and any I/O # coherent masters, and DRAM controllers. class SystemXBar(CoherentXBar):
Tested in gem5 12c917de54145d2d50260035ba7fa614e25317a3.