Some tests are really just a wrapper around a test script in
configs/. Add a helper method to wrap these scripts to make sure they
are executed in a consistent environment. This wrapper sets up a
global environment that is identical to that created by main() when it
executes the script. Unlike the old wrappers, it updates the module
search path to make relative imports work correctly in Python 3.
Change-Id: Ie9f81ec4e2689aa8cf5ecb9fc8025d3534b5c9ca
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15976
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Most Ruby tests assume that the highest frequency in the system under
test is 1GHz and limits the global tick rate to this frequency. This
assumption is broken since the default Ruby configuration scripts
clock the CPU at 2Ghz, which results in warnings and sometimes
incorrect behaviour.
Change-Id: I4b204660862ce3b0ea4a13df42caacd4398fef8c
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15975
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
At Ia49298304f658701ea0800bd79e08db404a655c3 we removed the default
kernel and DTB filenames from FSConfig.py.
However, the regression tests rely on that to find those blobs.
This commit restores those default filenames just for the config of the
regression tests.
Change-Id: I9d7d869b0087ee8a3b63088693f753a703ead5d6
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15957
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The AtomicSimpleCPU used to be able to access memory directly to speed
up simulation if no caches are used. This is fine as long as no
switching between CPU models is required. In order to switch to a new
CPU model that requires caches, we currently need to checkpoint the
system and restore it into a new configuration. The new
'atomic_noncaching' memory mode provides a solution that avoids this
issue since caches are bypassed in this mode. This changeset removes
the old fastmem option from the AtomicSimpleCPU and introduces a new
CPU, NonCachingSimpleCPU, which derives from the AtomicSimpleCPU.
The NonCachingSimpleCPU uses the same mechanism as the AtomicSimpleCPU
used to use when accessing memory in when fastmem was enabled.
This changeset also introduces a new switcheroo test that tests
switching between a NonCachingSimpleCPU and a TimingSimpleCPU with
caches.
Change-Id: If01893f9b37528b14f530c11ce6f53c097582c21
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12419
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The class re-uses the existing MSHR and write queue. At the moment
every single access is handled by the cache, even uncacheable
accesses, and nothing is forwarded.
This is a modified version of a changeset put together by Andreas
Hansson <andreas.hansson@arm.com>
Change-Id: I41f7f9c2b8c7fa5ec23712a4446e8adb1c9a336a
Reviewed-on: https://gem5-review.googlesource.com/8291
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Prior to this changeset the bootloader rom (instantiated as a
SimpleMemory) in ruby Arm systems was treated as an IO device and it
was fronted by a DMA controller. This changeset moves the bootloader
rom and adds it to the system as another memory with a dedicated
directory controller.
Change-Id: I094fed031cdef7f77a939d94f948d967b349b7e0
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/8741
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
This patch adds two regression tests that execute the script in the
configs dir for triggering low power mode transitions. A separate
test is required for each page policy because for close-adaptive
page policy the DRAM goes into the Precharge Power-down mode while
for open-adaptive page policy it goes into the Activate Power-down
mode.
Change-Id: Iad61af23f132db046f2857cc3ef64b2bf42cf5e4
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5726
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Use the PyBind11 wrapping infrastructure instead of SWIG to generate
wrappers for functionality that needs to be exported to Python. This
has several benefits:
* PyBind11 can be redistributed with gem5, which means that we have
full control of the version used. This avoid a large number of
hard-to-debug SWIG issues we have seen in the past.
* PyBind11 doesn't rely on a custom C++ parser, instead it relies on
wrappers being explicitly declared in C++. The leads to slightly
more boiler-plate code in manually created wrappers, but doesn't
doesn't increase the overall code size. A big benefit is that this
avoids strange compilation errors when SWIG doesn't understand
modern language features.
* Unlike SWIG, there is no risk that the wrapper code incorporates
incorrect type casts (this has happened on numerous occasions in
the past) since these will result in compile-time errors.
As a part of this change, the mechanism to define exported methods has
been redesigned slightly. New methods can be exported either by
declaring them in the SimObject declaration and decorating them with
the cxxMethod decorator or by adding an instance of
PyBindMethod/PyBindProperty to the cxx_exports class variable. The
decorator has the added benefit of making it possible to add a
docstring and naming the method's parameters.
The new wrappers have the following known issues:
* Global events can't be memory managed correctly. This was the
case in SWIG as well.
Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Andrew Bardsley <andrew.bardsley@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2231
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Pierre-Yves Péneau <pierre-yves.peneau@lirmm.fr>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
It's currently possible to change the log level in gem5 by tweaking a
set of global variables. These variables are currently exposed to
Python using SWIG. This mechanism is far from ideal for two reasons:
First, changing the log level requires that the Python world enables
or disables individual levels. Ideally, this should be a single call
where a log level is selected. Second, exporting global variables is
poorly supported by most Python frameworks. SWIG puts variables in
their own namespace and PyBind doesn't seem to support it at all.
This changeset refactors the logging code to create a more abstract
interface. Each log level is associated with an instance of a Logger
class. This class contains common functionality, an enable flag, and a
verbose flag.
Available LogLevels are described by the LogLevel class. Lower log
levels are used for more critical messages (PANIC being level 0) and
higher levels for less critical messages. The highest log level that
is printed is controlled by calling Logger:setLevel().
Change-Id: I31e44299d242d953197a8e62679250c91d6ef776
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Gabor Dozsa <gabor.dozsa@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Names of DRAM configurations were updated to reflect both
the channel and device data width.
Previous naming format was:
<DEVICE_TYPE>_<DATA_RATE>_<CHANNEL_WIDTH>
The following nomenclature is now used:
<DEVICE_TYPE>_<DATA_RATE>_<n>x<w>
where n = The number of devices per rank on the channel
x = Device width
Total channel width can be calculated by n*w
Example:
A 64-bit DDR4, 2400 channel consisting of 4-bit devices:
n = 16
w = 4
The resulting configuration name is:
DDR4_2400_16x4
Updated scripts to match new naming convention.
Added unique configurations for DDR4 for:
1) 16x4
2) 8x8
3) 4x16
Change-Id: Ibd7f763b7248835c624309143cb9fc29d56a69d1
Reviewed-by: Radhika Jagtap <radhika.jagtap@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Swig wrappers for native objects currently share the _m5.internal name
space with Python code. This is undesirable if we ever want to switch
from Swig to some other framework for native binding (e.g., PyBind11
or Boost::Python). This changeset moves all of such wrappers to the
_m5 namespace, which is now reserved for native code.
Change-Id: I2d2bc12dbc05b57b7c5a75f072e08124413d77f3
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
This patch avoids compiling ALPHA six times as part of running
'util/regress', and instead relis on NULL with different protocols to
run the rubytest. All we need is the memory system, so there is really
no need to compile the ISA over and over again.
The one downside is the removal of running 'hello' for the variuos
ALPHA and protocol combinations, but if this is a concern we should
rather beef up the synthetic tests for the variuos protocols.
--HG--
rename : build_opts/NULL => build_opts/NULL_MESI_Two_Level
rename : build_opts/NULL => build_opts/NULL_MOESI_CMP_directory
rename : build_opts/NULL => build_opts/NULL_MOESI_CMP_token
rename : build_opts/NULL => build_opts/NULL_MOESI_hammer
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_Two_Level/config.ini => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MESI_Two_Level/config.ini
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_Two_Level/simerr => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MESI_Two_Level/simerr
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_Two_Level/simout => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MESI_Two_Level/simout
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_Two_Level/stats.txt => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MESI_Two_Level/stats.txt
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_directory/config.ini => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_directory/config.ini
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_directory/simerr => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_directory/simerr
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_directory/simout => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_directory/simout
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_directory/stats.txt => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_directory/stats.txt
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_token/config.ini => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_token/config.ini
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_token/simerr => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_token/simerr
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_token/simout => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_token/simout
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_token/stats.txt => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_CMP_token/stats.txt
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_hammer/config.ini => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_hammer/config.ini
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_hammer/simerr => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_hammer/simerr
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_hammer/simout => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_hammer/simout
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_hammer/stats.txt => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby-MOESI_hammer/stats.txt
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby/config.ini => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby/config.ini
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby/simerr => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby/simerr
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby/simout => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby/simout
rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby/stats.txt => tests/quick/se/60.rubytest/ref/null/none/rubytest-ruby/stats.txt
Continue along the same line as the recent patch that made the
Ruby-related config scripts Python packages and make also the
configs/common directory a package.
All affected config scripts are updated (hopefully).
Note that this change makes it apparent that the current organisation
and naming of the config directory and its subdirectories is rather
chaotic. We mix scripts that are directly invoked with scripts that
merely contain convenience functions. While it is not addressed in
this patch we should follow up with a re-organisation of the
config structure, and renaming of some of the packages.
This patch moves the addition of network options into the Ruby module
to avoid the regressions all having to add it explicitly. Doing this
exposes an issue in our current config system though, namely the fact
that addtoPath is relative to the Python script being executed. Since
both example and regression scripts use the Ruby module we would end
up with two different (relative) paths being added. Instead we take a
first step at turning the config modules into Python packages, simply
by adding a __init__.py in the configs/ruby, configs/topologies and
configs/network subdirectories.
As a result, we can now add the top-level configs directory to the
Python search path, and then use the package names in the various
modules. The example scripts are also updated, and the messy
path-deducing variations in the scripts are unified.
This patch changes the default behaviour of the SystemXBar, adding a
snoop filter. With the recent updates to the snoop filter allocation
behaviour this change no longer causes problems for the regressions
without caches.
Change-Id: Ibe0cd437b71b2ede9002384126553679acc69cc1
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
The traffic generator tests currently assume that they are run from
the root of the source directory. This sometimes breaks tests when
they are run using the new test framework.
Change-Id: I6538a7902694c5d2c980295e076ea1c09acc4291
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Disable the default snoop filter in the SystemXBar so that the
typical membus does not have a snoop filter by default. Instead,
add the snoop filter only when there are caches added to the system
(with the caches / l2cache options).
The underlying problem is that the snoop filter grows without
bounds (for now) if there are no caches to tell it that lines have
been evicted. This causes slow regression runs for all the atomic
regressions. This patch fixes this behaviour.
--HG--
extra : source : f97c20511828209757440839ed48d741d02d428f
The learning gem5 scripts currently assumes that the current working
directory is the root of gem5's source tree. This isn't necessarily
the case when running the tests using gem5's new test runner.
Change-Id: Ief569bbe77b1b3e2b0fb0e6c575fb0705bbba9b3
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
The 01.hello-2T-smt test case for the O3 CPU didn't correctly setup
the number of threads before creating interrupt controllers, which
confused the constructor in BaseCPU. This changeset adds SMT support
to the test configuration infrastructure.
--HG--
rename : tests/configs/o3-timing.py => tests/configs/o3-timing-mt.py
rename : tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing/config.ini => tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing-mt/config.ini
rename : tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing/simerr => tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing-mt/simerr
rename : tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing/simout => tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing-mt/simout
rename : tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing/stats.txt => tests/quick/se/01.hello-2T-smt/ref/alpha/linux/o3-timing-mt/stats.txt
These tests will ensure that Learning gem5 scripts are always up to date with
the changes in the mainline of gem5.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
This changeset moves the access trace functionality from the
CommMonitor into a separate probe. The probe can be hooked up to any
component that exports probe points of the type ProbePoints::Packet.
This patch moves the dependency on Google's Protocol Buffers library
from the CommMonitor to the MemTraceProbe, which means that the
CommMonitor (including stack distance profiling) no long depends on
it.
This changeset removes the stack distance calculator hooks from the
CommMonitor class and implements a stack distance calculator as a
memory system probe instead. The probe can be hooked up to any
component that exports probe points of the type ProbePoints::Packet.
Draining is currently done by traversing the SimObject graph and
calling drain()/drainResume() on the SimObjects. This is not ideal
when non-SimObjects (e.g., ports) need draining since this means that
SimObjects owning those objects need to be aware of this.
This changeset moves the responsibility for finding objects that need
draining from SimObjects and the Python-side of the simulator to the
DrainManager. The DrainManager now maintains a set of all objects that
need draining. To reduce the overhead in classes owning non-SimObjects
that need draining, objects inheriting from Drainable now
automatically register with the DrainManager. If such an object is
destroyed, it is automatically unregistered. This means that drain()
and drainResume() should never be called directly on a Drainable
object.
While implementing the new functionality, the DrainManager has now
been made thread safe. In practice, this means that it takes a lock
whenever it manipulates the set of Drainable objects since SimObjects
in different threads may create Drainable objects
dynamically. Similarly, the drain counter is now an atomic_uint, which
ensures that it is manipulated correctly when objects signal that they
are done draining.
A nice side effect of these changes is that it makes the drain state
changes stricter, which the simulation scripts can exploit to avoid
redundant drains.
The full-system SPARC tests depend on several binaries that aren't
generally available to the wider community. Flag the tests as skipped
instead of failed if these binaries can't be found.
This patch adds a parameter to the BaseCache to enable a read-only
cache, for example for the instruction cache, or table-walker cache
(not for x86). A number of checks are put in place in the code to
ensure a read-only cache does not end up with dirty data.
A follow-on patch adds suitable read requests to allow a read-only
cache to explicitly ask for clean data.
Add a set of scripts to automatically test checkpointing in the
regression framework. The checkpointing tests are similar to the
switcheroo tests, but instead of switching between CPUs, they
checkpoint the system and restore from the checkpoint again. This is
done at regular intervals, typically while booting Linux.
The implementation is fairly straight forward, with the exception that
we have to work around gem5's inability to restore from a checkpoint
after a system has been instantiated. We work around this by forking
off child processes that does the actual simulation and never
instantiate a system in the parent process unless a maximum checkpoint
count is reached (in which case we just simulate the system to
completion in the parent).
Checkpoint testing is currently only enabled 32- and 64-bit ARM
systems using atomic CPUs.
Note: An unfortunate side-effect of forking is that every new process
will overwrite the stats and terminal output from the previous
process. This means that the output directory only contains data from
the last checkpoint.
This patch introduces a few subclasses to the CoherentXBar and
NoncoherentXBar to distinguish the different uses in the system. We
use the crossbar in a wide range of places: interfacing cores to the
L2, as a system interconnect, connecting I/O and peripherals,
etc. Needless to say, these crossbars have very different performance,
and the clock frequency alone is not enough to distinguish these
scenarios.
Instead of trying to capture every possible case, this patch
introduces dedicated subclasses for the three primary use-cases:
L2XBar, SystemXBar and IOXbar. More can be added if needed, and the
defaults can be overridden.
The MemTest class really only tests false sharing, and as such there
was a lot of old cruft that could be removed. This patch cleans up the
tester, and also makes it more clear what the assumptions are. As part
of this simplification the reference functional memory is also
removed.
The regression configs using MemTest are updated to reflect the
changes, and the stats will be bumped in a separate patch. The example
config will be updated in a separate patch due to more extensive
re-work.
In a follow-on patch a new tester will be introduced that uses the
MemChecker to implement true sharing.
This patch removes the three MIPS and SPARC regressions that use the
deprecated InOrderCPU.
This is the first step in completely removing the code from the tree,
avoiding confusion, and focusing all development efforts on the
MinorCPU. Brave new world.
Re-use the existing traffic generator regression, and enable the stack
distance calculation in the comm monitor, along with the verification
stack.
The traffic generator config is also tuned to not increase the
run-time too much (and actually have some address re-use).
This patch is the final in the series. The whole series and this patch in
particular were written with the aim of interfacing ruby's directory controller
with the memory controller in the classic memory system. This is being done
since ruby's memory controller has not being kept up to date with the changes
going on in DRAMs. Classic's memory controller is more up to date and
supports multiple different types of DRAM. This also brings classic and
ruby ever more close. The patch also changes ruby's memory controller to
expose the same interface.
Both ruby and the system used to maintain memory copies. With the changes
carried for programmed io accesses, only one single memory is required for
fs simulations. This patch sets the copy of memory that used to reside
with the system to null, so that no space is allocated, but address checks
can still be carried out. All the memory accesses now source and sink values
to the memory maintained by ruby.
This changes the default ARM system to a Versatile Express-like system that supports
2GB of memory and PCI devices and updates the default kernels/file-systems for
AArch64 ARM systems (64-bit) to support up to 32GB of memory and PCI devices. Some
platforms that are no longer supported have been pruned from the configuration files.
In addition a set of 64-bit ARM regressions have been added to the regression system.
This patch changes the CPU and cache configurations used in the ARM SE and FS
regressions to make them more representative, and also get better code
coverage by exercising different replacement policies and use an L2
prefetcher.
