This adds a new scons flag --no-duplicate-sources to build without
linking source files to the build directory.
I find this very helpful when using CLion, since I can now generate a
compilation database using
`bear scons build/ALL/gem5.debug --no-duplicate-sources` and CLion will
now correctly semantically analyze all the files inside src/.
It also ensures that clicking on a build warning/error now opens the
real source file rather than a symlink.
This is not enabled by default since it's possible that certain use
cases are not working correctly, but the basic testing I've done so
far appears to work just fine.
It appears that with this change the `<root>/src` directory is no longer
added to `PYTHONPATH` when running `tests/main.py`, so this change
depends on https://gem5-review.git.corp.google.com/c/public/gem5/+/68757
Change-Id: Iddc9bf9c8211e68e5432c0a07f5c95f427c1ca16
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68518
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
These are no longer split out and shared in the root build/ directory.
This does result in a small amount of overhead from building redundant
copies of these files, although the overhead is not significant. When
building 7 different variants of gem5, all the ISAs and NULL, the
difference on my machine was:
Before:
real 41m25.372s
user 914m22.266s
sys 41m51.816s
After:
real 42m38.074s
user 921m36.852s
sys 43m2.949s
This is about a 2-3% difference, which is a worse than typical case,
since the overhead scales with the number of variants being built.
The benefit of pulling ext/ into the variant directory is that there can
now be a single config which applies to all files used to build gem5,
and that config is represented by the variant of gem5 being built.
Change-Id: I6f0db97c63a7f3e252e7e351aa862340978e701b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56750
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Compiling gem5 with dramsim2 included fails due to some inconsistencies in
including SimObjects. In this patch this issue is fixed along with
temporarily disabling -Werror=nonnull-compare in CCFLAGS. Also, the remote
for cloning dramsim2 has been changed.
Change-Id: Ia24095150d026d736352aaf0d735b7554ede10bb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31434
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch adds DRAMSim2 as a memory controller by wrapping the
external library and creating a sublass of AbstractMemory that bridges
between the semantics of gem5 and the DRAMSim2 interface.
The DRAMSim2 wrapper extracts the clock period from the config
file. There is no way of extracting this information from DRAMSim2
itself, so we simply read the same config file and get it from there.
To properly model the response queue, the wrapper keeps track of how
many transactions are in the actual controller, and how many are
stacking up waiting to be sent back as responses (in the wrapper). The
latter requires us to move away from the queued port and manage the
packets ourselves. This is due to DRAMSim2 not having any flow control
on the response path.
DRAMSim2 assumes that the transactions it is given are matching the
burst size of the choosen memory. The wrapper checks to ensure the
cache line size of the system matches the burst size of DRAMSim2 as
there are currently no provisions to split the system requests. In
theory we could allow a cache line size smaller than the burst size,
but that would lead to inefficient use of the DRAM, so for not we
fatal also in this case.