1. The logger behavior change breaks verify.py.
commit 8deb205ea1
Author: Daniel Carvalho <odanrc@yahoo.com.br>
Date: Wed Mar 3 16:49:05 2021 -0300
base: Add LOC to Loggers
Printing the line and the file that triggered a log
is useful for debugging.
Change-Id: I74e0637b2943049134bd3e9a4bc6cab3766591a9
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42141
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
2. Use bytes diff in LogChecker.
In Python3, string is required to be in a certain encoding, while in Python2,
it is not. In the testcase, misc/cae_test/general/bitwise/or/datatypes,
it contains some invalid codepoint of utf-8, we need diff the log with
bytes in Pyhton3.
3. Python3 compatible.
* dict.iteritems -> dict.items
* remove object base class
* use `except as` when catching exceptions
* handle map and filter behavior change
Test with
src/systemc/tests/verify.py --update-json build/ARM -j `nproc` \
--filter-file src/systemc/tests/working.filt
src/systemc/tests/verify.py --update-json build/ARM -j `nproc` \
--filter-file src/systemc/tests/working.filt --phase verify --result-file
Change-Id: Ibf5b99d08a948387cf6162c476c294c49a7dac0f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44465
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45822
In systemc, a module name is consist of hierarchy names with dot
separated. The basename is the last part of the module name. Because
lack of hierarchy information, it's a chance that the basename is
duplicated. Although, ClockTick is using sc_gen_unique_name to solve
this, the warning from sc_gen_unique_name is annoying. To solve this
completely, we should use the full module name to construct the name of
ClockTick.
Change-Id: Ie664fe4757a05f72860be49c3a9d1172f824eb2e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44425
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45821
This reimplements the previously reverted change: Always generate default
create() methods.
The pybind code should only be generated when python is enabled. This
change passes whether python is enabled into the SimObject code creation
method. Then, the params code is optionally included.
Note: Due to some problems in GCC's linker (or something else...) we
need to have a single file with all of the generated code for the
SimObject.
Change-Id: I0f93b3d787d47f26db2de6c4447730f7df87a0dc
Issue-on: https://gem5.atlassian.net/browse/GEM5-1003
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46880
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
This was incorrectly kept as `http://dist.gem5.org/dist/develop` in the
v21.0.0 release of gem5. The `dist/develop` directory is used by the
develop branch, not by gem5 releases. This change updates the URL to
point towards the currect v21-0 branch, which will remain stable and
contain resoruces always compatible with the v21-0 release.
Change-Id: I5d9a9497cebffa91f08be253f1637e11e0d5e62c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44725
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 is addressing an issue raised in the mailing list [1]
where setting up a PCI mem bar for an ethernet device
resulted into an overlap of memory ranges:
fatal: system.iobus has two ports responding within range
[0x80000000:0x80020000]:
system.realview.ethernet.pio
system.iobridge.cpu_side_port
The reason for this is the following:
The PCI mem range in the DTB is using 0x40000000 (3rd word) as a
starting address in the PCI domain, which is linked to 0x40000000 in the
host domain.
<0x02000000 0x0 0x40000000 0x0 0x40000000 0x0 0x40000000>;
However the current mapping scheme works with simple fixed translation
So address 0x40000000 in the PCI domain will be mapped to 0x40000000 +
0x40000000 = 0x80000000, which is where DRAM starts
This is aligning with DTB autogeneration, which is setting up a
PCI mem range starting at PCI address = 0 [2]
[1]: https://www.mail-archive.com/gem5-users@gem5.org/msg18941.html
[2]: https://github.com/gem5/gem5/blob/v20.1.0.0/src/dev/arm/RealView.py#L161
Change-Id: I4538511453cfd5143fb4613a080780dc86b2244c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39915
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
gem5art is a utility to help manage the artifacts used in gem5
experiments, the output from those experiments, and running the
experiments in parallel (artifacts, run, and tasks packages
respectively).
The current documentation can be found on readthedocs [1], but we are
planning on migrating this to the gem5 website very soon [2].
More information on the motivation and design was discussed at the gem5
workshop last summer. See the blog post [3] for more details.
The current version (v1.3.1) is already deployed on PyPI, and you can
install it with `pip install gem5art-artifact gem5art-run gem5art-tasks`
Once this is merged, we will update the PyPI version to match the
version in gem5 (v1.4.0). The only differences are mostly documentation
based (pointers to the documentation and source), but we have also
updated the style to strictly match PEP8 with black [4].
gem5art is a *utility* to use with gem5. So, we expect that the
versioning and release schedule will not necessarily match gem5's (hence
a separate versioning structure and separate RELEASE-NOTES, etc.).
[1]: https://gem5art.readthedocs.io/en/latest/
[2]: https://www.gem5.org/documentation/gem5art
[3]: http://www.gem5.org/2020/05/26/gem5art.html
[4]: https://github.com/psf/black
Change-Id: Ic8af63edf0cb7df4693a46413f7278a3e8ac6846
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42121
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, RISC-V FS support was unable to support O3CPU.
It was due to two issues:
1. CLINT was calling tc->setMiscRegNoEffect which triggers
a conditionalSquash on O3CPU. These frequent squashes led
to assertion error in src/cpu/o3/inst_queue_impl.hh line
1293 (we still suspect that the assertion might contain
some assumptions).
2. A CSR write to SATP needs to trigger a squash (since
MMU can be activated). This is done by conditionally
adding the IsSquashAfter flag to CSR operations if the
target is SATP. This is a simple fix. (Else, an auipc
right after a CSR write to SATP might compute the wrong
value). In the future, a better implementation should
only set the flag for writes to the relevant bit(s).
Change-Id: Ieb9fd0b9aa09e4d2f270b28c2297ea821a81bf65
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43244
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Peter Yuen <petery.hin@huawei.com>
Changes:
1. RiscvBareMetal
The RiscvBareMetal class and API are preserved for backwards
compatibility, but the base class RiscvFSWorkload is removed
as it inherits from the Workload class. However, most needed
functionalities are already implemented in the KernelWorkload
class
2. RiscvLinux
The RiscvLinux class is added. A dtb filename can be specified
to be loaded to the corresponding memory address.
3. HiFive, Clint, Plic, Uart8250, VirtIOMMIO
Devicetree node generation function is added.
4. tlb, faults
Unnecessary includes of arch/riscv/fs_workload are removed.
Change-Id: Ia239b5614bd93d8e794330ead266f6121a4d13cb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42053
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Changed format from yaml to plain python. The new py configuration
file, when provided, must specialize the CHI node types defined in
configs/ruby/CHI_config.py (moved from configs/ruby/CHI.py). This
is required in order to setup the node->router bindings when the
CustomMesh topology is used.
See configs/example/noc_config/2x4.py (replaces
configs/example/noc_config/2x4.yaml) for an example.
--noc-config was also renamed to --chi-config, since the CHI node types
can be fully specialized in the configuration file.
Change-Id: Ic0c5407dba3d2483d5c30634c115b5410a5228fd
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43123
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 add a new Ruby cache coherence protocol based on Arm' AMBA5
CHI specification. The CHI protocol defines and implements two state
machine types:
- Cache_Controller: generic cache controller that can be configured as:
- Top-level L1 I/D cache
- A intermediate level (L2, L3, ...) private or shared cache
- A CHI home node (i.e. the point of coherence of the system and
has the global directory)
- A DMA requester
- Memory_Controller: implements a CHI slave node and interfaces with
gem5 memory controller. This controller has the functionality of a
Directory_Controller on the other Ruby protocols, except it doesn't
have a directory.
The Cache_Controller has multiple cache allocation/deallocation
parameters to control the clusivity with respect to upstream caches.
Allocation can be completely disabled to use Cache_Controller as a
DMA requester or as a home node without a shared LLC.
The standard configuration file configs/ruby/CHI.py provides a
'create_system' compatible with configs/example/fs.py and
configs/example/se.py and creates a system with private L1/L2 caches
per core and a shared LLC at the home nodes. Different cache topologies
can be defined by modifying 'create_system' or by creating custom
scripts using the structures defined in configs/ruby/CHI.py.
This patch also includes the 'CustomMesh' topology script to be used
with CHI. CustomMesh generates a 2D mesh topology with the placement
of components manually defined in a separate configuration file using
the --noc-config parameter.
The example in configs/example/noc_config/2x4.yaml creates a simple 2x4
mesh. For example, to run a SE mode simulation, with 4 cores,
4 mem ctnrls, and 4 home nodes (L3 caches):
build/ARM/gem5.opt configs/example/se.py \
--cmd 'tests/test-progs/hello/bin/arm/linux/hello' \
--ruby --num-cpus=4 --num-dirs=4 --num-l3caches=4 \
--topology=CustomMesh --noc-config=configs/example/noc_config/2x4.yaml
If one doesn't care about the component placement on the interconnect,
the 'Crossbar' and 'Pt2Pt' may be used and they do not require the
--noc-config option.
Additional authors:
Joshua Randall <joshua.randall@arm.com>
Pedro Benedicte <pedro.benedicteillescas@arm.com>
Tuan Ta <tuan.ta2@arm.com>
JIRA: https://gem5.atlassian.net/browse/GEM5-908
Change-Id: I856524b0afd30842194190f5bd69e7e6ded906b0
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42563
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The WalkCache stats are wrongly using the legacy framework.
With this patch we are registering those to the hierarchical structure.
As we need to pass the Stats::Group parent at construction time,
we are replacing 2d arrays with Vector2d for count stats and using a flat
vector of pointers for the Formula stats
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I8992bc262a376e4e81a4d608c11dff6902e0a01d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42984
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Added takeover methods for PMA Checker and RiscvTLB to ensure
that checkpoint restoration works. Also added logic in PLIC
to prevent posting interrupts to a CPU that has yet to complete
the current interrupt. PLIC's behaviour when a CPU claims another
interrupt before completion is also changed. Now PLIC will return
the uncompleted interrupt ID instead of return 0. This behaviour
is not documented in the specs but is designed this way to avoid
issues from CPU side (especially MinorCPU).
Change-Id: I68eaaf56d2c4d76cc1e0a1e2160f5abe184c2cd5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41933
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
We were originally generating default create() methods along side the
pybind definitions, but unfortunately those are only included when
python support is included. Since the SimObject Param structs are
unconditionally provided even if the thing calling their create()
methods is not, we need to also unconditionally provide the default
create() definitions. We do that by putting them in their own new .cc
files.
Change-Id: I29d1573d578794b3fe7ec2bc16ef5c8c58e56d0e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42589
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Earl Ou <shunhsingou@google.com>
This change:
systemc: remove pipe through flag in TLM extension
applied a change from gem5 proper in the gem5/TLM bridge improperly
here, adding a reference to a member variable that didn't exist. This
change removes the extra and invalid level of indirection to get things
to build again.
Change-Id: I77ffdb5408525e116d414df2095a944c58e40b4d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42586
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Earl Ou <shunhsingou@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This is in the Accellera version of systemc, used when gem5 is built
into systemc as a black box. std::gets was depdecated in c++11, and
removed entirely in c++14. Since gem5 has moved to c++14, this can't be
brought in with "using" in that header. More recent versions of systemc
from Accellera may have this fixed, and it's pretty bad practice to have
a universal header file squash unrelated namespaces like that in the
first place.
Rather tha update all of this copy of systemc, this change just makes
the smallest adjustment possible to get things to work again.
Change-Id: I8a95665d4b5d49ffc014097714cf2e602bf9b937
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42583
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Due the compute unit pipeline being executed in reverse order, there
exists a scenario where a compute unit will execute an extra
instruction when it's supposed to be stopped at a barrier. It occurs
as follows:
* The ScheduleStage sets a barrier instruction ready to execute.
* The ScoreboardCheckStage adds another instruction to the readyList.
This is where the barrier is checked, but because the barrier isn't
executing yet, the instruction can be passed along to ScheduleStage
* The barrier executes, and stalls
* The ScheduleStage sees that there's a new instruction and schedules
it to be executed.
* Only now will the ScoreboardCheckStage realize a barrier is active
and stall accordingly
* The subsequent instruction executes
This patch sets the wavefront status to be S_BARRIER in ScheduleStage
instead of in the barrier instruction execution in order to have
ScoreboardCheckStage realize that we're going to execute a barrier,
preventing it from marking another instruciton as ready.
Change-Id: Ib683e2c68f361d7ee60a3beaf53b4b6c888c9f8d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41573
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
