[gem5-users] Dram sim2 running with gem5

[Srikanta Chaitanya via gem5-users]

Hi ,
I am new to gem5 , I want to use dramsim2 with gem5 I cloned it and ran
scons

I am getting  error. ClockDoenv.cpp not found

Please help me .
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

[gem5-users] O3 model for ARM Cortex A55

[Jonathan Kang via gem5-users]

I’m interested in using Gem5’s O3 model but I’m trying to model the A55 CPU 
(since that’s what we use in silicon).

I know there’s previous work getting the O3 model configuration to correlate 
with Cortex A9. Has anyone done work on more recent ARM processors like the 
A76(or A77/A78) and the A55?

Jonathan
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

[gem5-users] cache-coherent numa config with classic memory system

[Antoine Kaufmann via gem5-users]

Hi everyone,

I am currently trying to build gem5 config with the classic memory/cache system
that reasonbly resembles a typical multi-socket x86 numa server, but have so far
not been successful. (I know Ruby has much more flexiblity here, but I would
also like a config with classic components if at all possible).

Conceptually I was expecting this should be straight forward: I create a
coherent xbar as the main system bus. For each numa node I create a separate
xbar where I connect the node's memory controller and local PCI devices, both
PIO and DMA, along with the shared L3 cache.

The bit I have not been able to figure out yet, is how to connect the
per-numa-node xbars to the system xbar.

Initially I was planning on using a pair of bridges (one per direction) to
connect each numa xbar to the system bus. The problem here is that the bridges
seem to be able to only advertise statically configured address ranges, fine for
the memory controllers but bad for PCI bars, which are configured dynamically.

Directly connecting both cpu and mem-side ports of the busses cross-wise clearly
also does not work because of overlapping address ranges once updates propagate.
(i.e. once numa node 0 receives the ranges from numa node 1 it will advertise to
the system xbar as well and then there are two ports with overlapping ranges).
I've also experimented with using the default port on the per-numa-node xbars to
connect to the system bus, but also without success.

So far I have not found a way to address this with existing classic memory
system components (despite coherent_xbar.hh mentioning that it can be used to
model things like qpi or hypertransport). Am I missing something obvious here?

Alternatively I am thinking of implementing a custom  "bi-directional" bridge
component that will only forward address ranges in the direction where it sees
them arrive first.

I would also appreciate any other ideas.

Thanks,
Antoine

-- 
Antoine Kaufmann



signature.asc
Description: PGP signature
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org