Re: [gem5-dev] systemc reviews
Ok great, glad to hear it. Gabe On Mon, Jun 11, 2018 at 3:34 PM Matthias Jung wrote: > Hi Christian, > > I think you summarised the 3 approaches very well. I mean, we have > approach 1 already. It makes sense if Gabe drives approach 2 because > it has many advantages compared to approach 1. I think we could see > approach 3 as a longterm goal and we should go for approach 2 for now. > > Thanks for all the opinions so far, > Best, > Matthias > > > Am 11.06.2018 um 18:02 schrieb Christian Menard < > christian.men...@tu-dresden.de>: > > > > Hi, > > > > I am following the discussion for a while now and finally found the time > > to look at Gabe's proposal. > > > > As I see it, there are three approaches for combining gem5 and SystemC > > as outlined below. (Sorry for repeating stuff that was mentioned before, > > I just find it helpful to summarize some points) > > > > 1. Bridging gem5 ans Systemc. > > This is the approach I and Matthias implemented and presented last > > year. It provides bridges between the gem5 and SystemC communication > > interfaces, as well as a wrapper SystemC module that hosts a complete > > gem5 simulation on top of the SystemC kernel. While this approach > > certainly has limitations, it allows to combine gem5 and SystemC models. > > > > 2. Implementing the SystemC standard using gem5 > > This is the approach proposed by Gabe which, as I understand it, > > provides a wrapper around gem5 implementing the SystemC standard. With > > this approach, gem5 becomes a fully fledged SystemC kernel which > > arbitrary standard compliant SystemC models can run on. Compared to > > approach 1, this allows for more interaction between both domains, as > > everything can be compiled in a single pass and there is not just one > > single point of interaction. However, this approach prevents certain use > > cases, e.g. where SystemC models are closed source or where a specific > > SystemC implementation is required. > > > > 3. Replacing the gem5 simulation kernel by SystemC. > > This is the most radical approach but also gives most flexibility. It > > replaces the entire gem5 simulation kernel by SystemC. In this approach, > > gem5 could be seen as a system modeling framework and as an abstraction > > layer on top of SystemC. This would give maximum flexibility as > > arbitrary SystemC and gem5 models can be combined and even the SystemC > > kernel can be exchanged arbitrarily. However, it is not clear (at least > > to me) how exactly gem5 and SystemC modules could be connected and > > interact with each other. I think for this approach to work, aspects of > > approach 1 or/and 2 are still required. > > > > So as I see it: 3 covers more use cases than 2 but both are in a way > > superior to the existing approach (1). However, in order to implement 3 > > a lot of changes to the code base are required. Implementing these > > changes will take some time, so there will probably be two versions of > > gem5: a legacy one and the SystemC one. This again produces more work in > > maintaining the code base. Now I wonder: who is willing to do all this > > work? > > > > While I favour approach 3 for its benefits and the points Matthias made, > > I still like Gabe's idea very much. It minimizes the changes required to > > the existing code base while providing many benefits to a broader > > community. As Gabe mentioned before, his approach neither breaks with > > the existing bridges implemented by me and Matthias, nor does it prevent > > implementation of approach 3 in the future. To sum it up: there are no > > objections from my side. > > > > Unfortunately, I am not very active in hardware modeling anymore, but I > > am very interested in this development and I hope to find the time to > > have a look on the patches soon. > > > > Best, > > > > Christian > > > > Matthias Jung writes: > > > >> Hi Gabe, > >> > >> I totally agree with you. SytemC is a standard and the code maintained > >> by accellera is just an „example“ of how SystemC could be implemented. > >> > >> However, that is part of my argument. If I want to use e.g. another > >> fancy SystemC kernel (e.g. https://dl.acm.org/citation.cfm?id=2987374) > >> or a commercial one like the one in the Synopsys toolchains, I cannot > >> use gem5 (beside the coupling that is already there, which has also > >> several drawbacks). So I like more the separation of simulation models > >> and the kernel. > >> > >> But I also understand it from your side. In Google you don’t have this > >> specific need and you want to find quickly a solution with less effort. > >> Anyway we should discuss if a full switch to SystemC as a kernel might > >> be a reasonable long term goal. I think many people would benefit from > >> that. > >> > >> I’m also keen to know Christian’s, Andreas’ and Jason’s opinions. > >> > >> It’s a pitty that gem5 and SystemC started back at the same time > >> and evolved separately... > >> > >> Best, > >> Matthias > >> > >>> Am 09.06.2018 um 02:34
Re: [gem5-dev] systemc reviews
Hi Christian, I think you summarised the 3 approaches very well. I mean, we have approach 1 already. It makes sense if Gabe drives approach 2 because it has many advantages compared to approach 1. I think we could see approach 3 as a longterm goal and we should go for approach 2 for now. Thanks for all the opinions so far, Best, Matthias > Am 11.06.2018 um 18:02 schrieb Christian Menard > : > > Hi, > > I am following the discussion for a while now and finally found the time > to look at Gabe's proposal. > > As I see it, there are three approaches for combining gem5 and SystemC > as outlined below. (Sorry for repeating stuff that was mentioned before, > I just find it helpful to summarize some points) > > 1. Bridging gem5 ans Systemc. > This is the approach I and Matthias implemented and presented last > year. It provides bridges between the gem5 and SystemC communication > interfaces, as well as a wrapper SystemC module that hosts a complete > gem5 simulation on top of the SystemC kernel. While this approach > certainly has limitations, it allows to combine gem5 and SystemC models. > > 2. Implementing the SystemC standard using gem5 > This is the approach proposed by Gabe which, as I understand it, > provides a wrapper around gem5 implementing the SystemC standard. With > this approach, gem5 becomes a fully fledged SystemC kernel which > arbitrary standard compliant SystemC models can run on. Compared to > approach 1, this allows for more interaction between both domains, as > everything can be compiled in a single pass and there is not just one > single point of interaction. However, this approach prevents certain use > cases, e.g. where SystemC models are closed source or where a specific > SystemC implementation is required. > > 3. Replacing the gem5 simulation kernel by SystemC. > This is the most radical approach but also gives most flexibility. It > replaces the entire gem5 simulation kernel by SystemC. In this approach, > gem5 could be seen as a system modeling framework and as an abstraction > layer on top of SystemC. This would give maximum flexibility as > arbitrary SystemC and gem5 models can be combined and even the SystemC > kernel can be exchanged arbitrarily. However, it is not clear (at least > to me) how exactly gem5 and SystemC modules could be connected and > interact with each other. I think for this approach to work, aspects of > approach 1 or/and 2 are still required. > > So as I see it: 3 covers more use cases than 2 but both are in a way > superior to the existing approach (1). However, in order to implement 3 > a lot of changes to the code base are required. Implementing these > changes will take some time, so there will probably be two versions of > gem5: a legacy one and the SystemC one. This again produces more work in > maintaining the code base. Now I wonder: who is willing to do all this > work? > > While I favour approach 3 for its benefits and the points Matthias made, > I still like Gabe's idea very much. It minimizes the changes required to > the existing code base while providing many benefits to a broader > community. As Gabe mentioned before, his approach neither breaks with > the existing bridges implemented by me and Matthias, nor does it prevent > implementation of approach 3 in the future. To sum it up: there are no > objections from my side. > > Unfortunately, I am not very active in hardware modeling anymore, but I > am very interested in this development and I hope to find the time to > have a look on the patches soon. > > Best, > > Christian > > Matthias Jung writes: > >> Hi Gabe, >> >> I totally agree with you. SytemC is a standard and the code maintained >> by accellera is just an „example“ of how SystemC could be implemented. >> >> However, that is part of my argument. If I want to use e.g. another >> fancy SystemC kernel (e.g. https://dl.acm.org/citation.cfm?id=2987374) >> or a commercial one like the one in the Synopsys toolchains, I cannot >> use gem5 (beside the coupling that is already there, which has also >> several drawbacks). So I like more the separation of simulation models >> and the kernel. >> >> But I also understand it from your side. In Google you don’t have this >> specific need and you want to find quickly a solution with less effort. >> Anyway we should discuss if a full switch to SystemC as a kernel might >> be a reasonable long term goal. I think many people would benefit from >> that. >> >> I’m also keen to know Christian’s, Andreas’ and Jason’s opinions. >> >> It’s a pitty that gem5 and SystemC started back at the same time >> and evolved separately... >> >> Best, >> Matthias >> >>> Am 09.06.2018 um 02:34 schrieb Gabe Black : >>> >>> Also, I should point out that the systemc standard defines a set of >>> mechanisms and an interface, not an implementation. The Accellera version >>> of systemc is *not* the standard, it's just an implementation (a very >>> common and important one) of that standard. It's
[gem5-dev] Change in gem5/gem5[master]: arch-riscv: Add support for fault handling
Alec Roelke has uploaded a new patch set (#5) to the change originally created by Alec Roelke. ( https://gem5-review.googlesource.com/9161 ) Change subject: arch-riscv: Add support for fault handling .. arch-riscv: Add support for fault handling This patch adds support for handling RISC-V faults, including tracking current and previous execution privilege, correctly switching to the privilege mode specified by CSRs, and setting/storing the PC. It also includes changes introduced by patch #9821, which disables interrupts during handling of a fault. Change-Id: Ie9c0f29719620c20783540d3bdb2db44f6114fc9 --- M src/arch/riscv/faults.cc M src/arch/riscv/faults.hh 2 files changed, 147 insertions(+), 74 deletions(-) -- To view, visit https://gem5-review.googlesource.com/9161 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: Ie9c0f29719620c20783540d3bdb2db44f6114fc9 Gerrit-Change-Number: 9161 Gerrit-PatchSet: 5 Gerrit-Owner: Alec Roelke Gerrit-Reviewer: Alec Roelke Gerrit-Reviewer: Alec Roelke Gerrit-Reviewer: Robert Scheffel Gerrit-Reviewer: Tuan Ta Gerrit-CC: Christian Menard Gerrit-CC: Gabe Black Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: cpu-minor: Remove redundant thread startup call
Hello Giacomo Travaglini,
I'd like you to do a code review. Please visit
https://gem5-review.googlesource.com/11037
to review the following change.
Change subject: cpu-minor: Remove redundant thread startup call
..
cpu-minor: Remove redundant thread startup call
Don't call startup() twice on each of the threads.
Change-Id: Ibe3d1f25c4fdff291ee310abb9bcad3b184bab20
Signed-off-by: Andreas Sandberg
Reviewed-by: Giacomo Travaglini
---
M src/cpu/minor/cpu.cc
1 file changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/cpu/minor/cpu.cc b/src/cpu/minor/cpu.cc
index 68c0767..63efde2 100644
--- a/src/cpu/minor/cpu.cc
+++ b/src/cpu/minor/cpu.cc
@@ -183,9 +183,6 @@
BaseCPU::startup();
-for (auto i = threads.begin(); i != threads.end(); i ++)
-(*i)->startup();
-
for (ThreadID tid = 0; tid < numThreads; tid++) {
threads[tid]->startup();
pipeline->wakeupFetch(tid);
--
To view, visit https://gem5-review.googlesource.com/11037
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Ibe3d1f25c4fdff291ee310abb9bcad3b184bab20
Gerrit-Change-Number: 11037
Gerrit-PatchSet: 1
Gerrit-Owner: Andreas Sandberg
Gerrit-Reviewer: Giacomo Travaglini
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: dev-arm: Add a Mali compliant display processor model
Andreas Sandberg has uploaded a new patch set (#2). ( https://gem5-review.googlesource.com/10808 ) Change subject: dev-arm: Add a Mali compliant display processor model .. dev-arm: Add a Mali compliant display processor model This change adds a ARM Mali Display Processor model that is compatible with the DP650 register interface. Change-Id: I2fe596dc517028ed45bd572332174e5d99bd9956 Reviewed-by: Andreas Sandberg Signed-off-by: Andreas Sandberg --- M src/dev/arm/RealView.py M src/dev/arm/SConscript A src/dev/arm/dpu.cc A src/dev/arm/dpu.hh A src/dev/arm/dpu_regs.hh A src/dev/arm/dpu_utils.hh 6 files changed, 4,318 insertions(+), 3 deletions(-) -- To view, visit https://gem5-review.googlesource.com/10808 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I2fe596dc517028ed45bd572332174e5d99bd9956 Gerrit-Change-Number: 10808 Gerrit-PatchSet: 2 Gerrit-Owner: Andreas Sandberg Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: system-arm: Add a device tree for the VExpress_GEM5_V1_DPU
Hello Ciro Santilli,
I'd like you to do a code review. Please visit
https://gem5-review.googlesource.com/11036
to review the following change.
Change subject: system-arm: Add a device tree for the VExpress_GEM5_V1_DPU
..
system-arm: Add a device tree for the VExpress_GEM5_V1_DPU
The new platform needs a new device tree. Like the HDLCD-based
platform, the DPU is disabled by default since it requires display
timings to be specified separately.
Change-Id: I4cb357ab6e08d129b3e0d998ffc7e5d1415e94e4
Signed-off-by: Andreas Sandberg
Reviewed-by: Ciro Santilli
---
M system/arm/dt/Makefile
A system/arm/dt/platforms/vexpress_gem5_v1_dpu.dtsi
2 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/system/arm/dt/Makefile b/system/arm/dt/Makefile
index a162b9f..7371e49 100644
--- a/system/arm/dt/Makefile
+++ b/system/arm/dt/Makefile
@@ -39,7 +39,12 @@
armv8_gem5_v1_4cpu.dtb armv8_gem5_v1_8cpu.dtb \
armv8_gem5_v1_16cpu.dtb \
armv8_gem5_v1_big_little_2_2.dtb \
- armv8_gem5_v1_big_little_2_4.dtb
+ armv8_gem5_v1_big_little_2_4.dtb \
+ \
+ armv7_gem5_v1_dpu_1cpu.dtb armv7_gem5_v1_dpu_2cpu.dtb \
+ armv7_gem5_v1_dpu_4cpu.dtb armv7_gem5_v1_dpu_8cpu.dtb \
+ armv8_gem5_v1_dpu_1cpu.dtb armv8_gem5_v1_dpu_2cpu.dtb \
+ armv8_gem5_v1_dpu_4cpu.dtb armv8_gem5_v1_dpu_8cpu.dtb
GEN_DTS=mkdir -p .gen; \
$(CPP) -x assembler-with-cpp \
@@ -51,6 +56,13 @@
all: $(TARGETS)
platforms/vexpress_gem5_v1.dtsi: platforms/vexpress_gem5_v1_base.dtsi
+platforms/vexpress_gem5_v1_dpu.dtsi: platforms/vexpress_gem5_v1_base.dtsi
+
+.gen/armv7_gem5_v1_dpu_%cpu.dts: armv7.dts
platforms/vexpress_gem5_v1_dpu.dtsi
+ $(call GEN_DTS,vexpress_gem5_v1_dpu.dtsi,$*)
+
+.gen/armv8_gem5_v1_dpu_%cpu.dts: armv8.dts
platforms/vexpress_gem5_v1_dpu.dtsi
+ $(call GEN_DTS,vexpress_gem5_v1_dpu.dtsi,$*)
.gen/armv7_gem5_v1_%cpu.dts: armv7.dts platforms/vexpress_gem5_v1.dtsi
$(call GEN_DTS,vexpress_gem5_v1.dtsi,$*)
diff --git a/system/arm/dt/platforms/vexpress_gem5_v1_dpu.dtsi
b/system/arm/dt/platforms/vexpress_gem5_v1_dpu.dtsi
new file mode 100644
index 000..6f48ca8
--- /dev/null
+++ b/system/arm/dt/platforms/vexpress_gem5_v1_dpu.dtsi
@@ -0,0 +1,50 @@
+/*
+ * Copyright (c) 2015-2016, 2018 ARM Limited
+ * All rights reserved
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met: redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer;
+ * redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution;
+ * neither the name of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Authors: Andreas Sandberg
+ */
+
+#include "vexpress_gem5_v1_base.dtsi"
+
+/ {
+ /* The display processor needs custom configuration to setup its
+ * output ports. Disable it by default in the platform until the
+ * DT bindings have stabilize.
+*/
+ dp0: malidp@2b00 {
+ compatible = "arm,mali-dp650";
+
+ reg = <0 0x2b00 0 0x2>;
+ interrupts = <0 63 4>, <0 64 4>;
+ interrupt-names = "DE", "SE";
+ clocks = <_pxl>, <_pxl>, <_sys>, <_sys>;
+ clock-names = "pxlclk", "mclk", "aclk", "pclk";
+ arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
+
+ status = "disabled";
+ };
+};
--
To view, visit https://gem5-review.googlesource.com/11036
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I4cb357ab6e08d129b3e0d998ffc7e5d1415e94e4
Gerrit-Change-Number: 11036
Gerrit-PatchSet: 1
Gerrit-Owner: Andreas
[gem5-dev] Change in gem5/gem5[master]: system-arm: Split the VExpress_GEM5_V1 base dts
Hello Ciro Santilli,
I'd like you to do a code review. Please visit
https://gem5-review.googlesource.com/11035
to review the following change.
Change subject: system-arm: Split the VExpress_GEM5_V1 base dts
..
system-arm: Split the VExpress_GEM5_V1 base dts
With the introduction of the new DPU model, we need different
variations of the VExpress_GEM5_V1 platform. This splits the platform
dtsi file into a separate file for the base platform and the
HDLCD-based platform. This matches the hierarchy in RealView.py.
Change-Id: Id02380122655b5d3aa3548a703fdef178bba17d9
Signed-off-by: Andreas Sandberg
Reviewed-by: Ciro Santilli
---
M system/arm/dt/Makefile
M system/arm/dt/armv7.dts
M system/arm/dt/armv8.dts
M system/arm/dt/armv8_big_little.dts
M system/arm/dt/platforms/vexpress_gem5_v1.dtsi
A system/arm/dt/platforms/vexpress_gem5_v1_base.dtsi
6 files changed, 208 insertions(+), 173 deletions(-)
diff --git a/system/arm/dt/Makefile b/system/arm/dt/Makefile
index 62cf65f..a162b9f 100644
--- a/system/arm/dt/Makefile
+++ b/system/arm/dt/Makefile
@@ -50,6 +50,8 @@
all: $(TARGETS)
+platforms/vexpress_gem5_v1.dtsi: platforms/vexpress_gem5_v1_base.dtsi
+
.gen/armv7_gem5_v1_%cpu.dts: armv7.dts platforms/vexpress_gem5_v1.dtsi
$(call GEN_DTS,vexpress_gem5_v1.dtsi,$*)
diff --git a/system/arm/dt/armv7.dts b/system/arm/dt/armv7.dts
index aea4844..c9c2523 100644
--- a/system/arm/dt/armv7.dts
+++ b/system/arm/dt/armv7.dts
@@ -108,8 +108,8 @@
virt-encoder {
compatible = "drm,virtual-encoder";
port {
- hdlcd0_virt_input: endpoint@0 {
- remote-endpoint = <_output>;
+ dp0_virt_input: endpoint@0 {
+ remote-endpoint = <_output>;
};
};
@@ -132,12 +132,12 @@
};
};
- {
+ {
status = "ok";
port {
- hdlcd0_output: endpoint@0 {
- remote-endpoint = <_virt_input>;
+ dp0_output: endpoint@0 {
+ remote-endpoint = <_virt_input>;
};
};
};
diff --git a/system/arm/dt/armv8.dts b/system/arm/dt/armv8.dts
index 9e07dec..20d58a8 100644
--- a/system/arm/dt/armv8.dts
+++ b/system/arm/dt/armv8.dts
@@ -112,8 +112,8 @@
virt-encoder {
compatible = "drm,virtual-encoder";
port {
- hdlcd0_virt_input: endpoint@0 {
- remote-endpoint = <_output>;
+ dp0_virt_input: endpoint@0 {
+ remote-endpoint = <_output>;
};
};
@@ -136,12 +136,12 @@
};
};
- {
+ {
status = "ok";
port {
- hdlcd0_output: endpoint@0 {
- remote-endpoint = <_virt_input>;
+ dp0_output: endpoint@0 {
+ remote-endpoint = <_virt_input>;
};
};
};
diff --git a/system/arm/dt/armv8_big_little.dts
b/system/arm/dt/armv8_big_little.dts
index 70049bb..83d2db7 100644
--- a/system/arm/dt/armv8_big_little.dts
+++ b/system/arm/dt/armv8_big_little.dts
@@ -110,8 +110,8 @@
virt-encoder {
compatible = "drm,virtual-encoder";
port {
- hdlcd0_virt_input: endpoint@0 {
- remote-endpoint = <_output>;
+ dp0_virt_input: endpoint@0 {
+ remote-endpoint = <_output>;
};
};
@@ -134,12 +134,12 @@
};
};
- {
+ {
status = "ok";
port {
- hdlcd0_output: endpoint@0 {
- remote-endpoint = <_virt_input>;
+ dp0_output: endpoint@0 {
+ remote-endpoint = <_virt_input>;
};
};
};
diff --git a/system/arm/dt/platforms/vexpress_gem5_v1.dtsi
b/system/arm/dt/platforms/vexpress_gem5_v1.dtsi
index 442ce79..60f68f7 100644
--- a/system/arm/dt/platforms/vexpress_gem5_v1.dtsi
+++ b/system/arm/dt/platforms/vexpress_gem5_v1.dtsi
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015-2017 ARM Limited
+ * Copyright (c) 2015-2018 ARM Limited
* All rights reserved
*
* Redistribution and use in source and binary forms, with or without
@@ -28,62 +28,14 @@
* Authors: Andreas Sandberg
*/
+#include "vexpress_gem5_v1_base.dtsi"
+
/ {
- arm,hbi = <0x0>;
- arm,vexpress,site = <0xf>;
- interrupt-parent = <>;
- #address-cells = <2>;
- #size-cells = <2>;
-
- gic: interrupt-controller@2c001000 {
- compatible = "gem5,gic", "arm,gic-400";
- #interrupt-cells = <3>;
- #address-cells = <0>;
- interrupt-controller;
- reg = <0 0x2c001000 0 0x1000>,
- <0
[gem5-dev] Change in gem5/gem5[master]: misc: Substitute pointer to Request with aliased RequestPtr
Giacomo Travaglini has submitted this change and it was merged. (
https://gem5-review.googlesource.com/10995 )
Change subject: misc: Substitute pointer to Request with aliased RequestPtr
..
misc: Substitute pointer to Request with aliased RequestPtr
Every usage of Request* in the code has been replaced with the
RequestPtr alias. This is a preparing patch for when RequestPtr will be
the typdefed to a smart pointer to Request rather then a raw pointer to
Request.
Change-Id: I73cbaf2d96ea9313a590cdc731a25662950cd51a
Signed-off-by: Giacomo Travaglini
Reviewed-by: Nikos Nikoleris
Reviewed-on: https://gem5-review.googlesource.com/10995
Reviewed-by: Anthony Gutierrez
Reviewed-by: Daniel Carvalho
Maintainer: Anthony Gutierrez
---
M src/arch/alpha/locked_mem.hh
M src/arch/arm/locked_mem.hh
M src/arch/generic/locked_mem.hh
M src/arch/hsail/insts/mem.hh
M src/arch/mips/locked_mem.hh
M src/arch/riscv/locked_mem.hh
M src/cpu/base_dyn_inst.hh
M src/cpu/checker/cpu.cc
M src/cpu/checker/cpu.hh
M src/cpu/minor/lsq.cc
M src/cpu/minor/lsq.hh
M src/cpu/o3/lsq_unit.hh
M src/cpu/o3/lsq_unit_impl.hh
M src/cpu/simple/atomic.cc
M src/cpu/simple/base.cc
M src/cpu/simple/base.hh
M src/cpu/simple/timing.cc
M src/cpu/testers/directedtest/InvalidateGenerator.cc
M src/cpu/testers/directedtest/SeriesRequestGenerator.cc
M src/cpu/testers/garnet_synthetic_traffic/GarnetSyntheticTraffic.cc
M src/cpu/testers/memtest/memtest.cc
M src/cpu/testers/rubytest/Check.cc
M src/cpu/testers/traffic_gen/base_gen.cc
M src/gpu-compute/compute_unit.cc
M src/gpu-compute/fetch_unit.cc
M src/gpu-compute/gpu_dyn_inst.hh
M src/gpu-compute/shader.cc
M src/mem/abstract_mem.cc
M src/mem/abstract_mem.hh
M src/mem/cache/base.cc
M src/mem/cache/cache.cc
M src/mem/cache/prefetch/queued.cc
32 files changed, 68 insertions(+), 66 deletions(-)
Approvals:
Anthony Gutierrez: Looks good to me, approved; Looks good to me, approved
Daniel Carvalho: Looks good to me, approved
diff --git a/src/arch/alpha/locked_mem.hh b/src/arch/alpha/locked_mem.hh
index 36a6a03..a71a24c 100644
--- a/src/arch/alpha/locked_mem.hh
+++ b/src/arch/alpha/locked_mem.hh
@@ -85,7 +85,7 @@
template
inline void
-handleLockedRead(XC *xc, Request *req)
+handleLockedRead(XC *xc, RequestPtr req)
{
xc->setMiscReg(MISCREG_LOCKADDR, req->getPaddr() & ~0xf);
xc->setMiscReg(MISCREG_LOCKFLAG, true);
@@ -99,7 +99,7 @@
template
inline bool
-handleLockedWrite(XC *xc, Request *req, Addr cacheBlockMask)
+handleLockedWrite(XC *xc, RequestPtr req, Addr cacheBlockMask)
{
if (req->isUncacheable()) {
// Funky Turbolaser mailbox access...don't update
diff --git a/src/arch/arm/locked_mem.hh b/src/arch/arm/locked_mem.hh
index 2fcbc4a..d339785 100644
--- a/src/arch/arm/locked_mem.hh
+++ b/src/arch/arm/locked_mem.hh
@@ -91,7 +91,7 @@
template
inline void
-handleLockedRead(XC *xc, Request *req)
+handleLockedRead(XC *xc, RequestPtr req)
{
xc->setMiscReg(MISCREG_LOCKADDR, req->getPaddr());
xc->setMiscReg(MISCREG_LOCKFLAG, true);
@@ -111,7 +111,7 @@
template
inline bool
-handleLockedWrite(XC *xc, Request *req, Addr cacheBlockMask)
+handleLockedWrite(XC *xc, RequestPtr req, Addr cacheBlockMask)
{
if (req->isSwap())
return true;
diff --git a/src/arch/generic/locked_mem.hh b/src/arch/generic/locked_mem.hh
index 68a4ff5..f653799 100644
--- a/src/arch/generic/locked_mem.hh
+++ b/src/arch/generic/locked_mem.hh
@@ -63,7 +63,7 @@
template
inline void
-handleLockedRead(XC *xc, Request *req)
+handleLockedRead(XC *xc, RequestPtr req)
{
}
@@ -76,7 +76,7 @@
template
inline bool
-handleLockedWrite(XC *xc, Request *req, Addr cacheBlockMask)
+handleLockedWrite(XC *xc, RequestPtr req, Addr cacheBlockMask)
{
return true;
}
diff --git a/src/arch/hsail/insts/mem.hh b/src/arch/hsail/insts/mem.hh
index 36a6cbc..68a61fe 100644
--- a/src/arch/hsail/insts/mem.hh
+++ b/src/arch/hsail/insts/mem.hh
@@ -461,9 +461,10 @@
*d = gpuDynInst->wavefront()->ldsChunk->
read(vaddr);
} else {
-Request *req = new Request(0, vaddr,
sizeof(c0), 0,
-
gpuDynInst->computeUnit()->masterId(),
- 0, gpuDynInst->wfDynId);
+RequestPtr req = new Request(0,
+vaddr, sizeof(c0), 0,
+gpuDynInst->computeUnit()->masterId(),
+0, gpuDynInst->wfDynId);
gpuDynInst->setRequestFlags(req);
PacketPtr pkt = new Packet(req,
MemCmd::ReadReq);
@@ -588,7 +589,7 @@
gpuDynInst->statusBitVector = VectorMask(1);
gpuDynInst->useContinuation = false;
// create request
-
Re: [gem5-dev] systemc reviews
Hi, I am following the discussion for a while now and finally found the time to look at Gabe's proposal. As I see it, there are three approaches for combining gem5 and SystemC as outlined below. (Sorry for repeating stuff that was mentioned before, I just find it helpful to summarize some points) 1. Bridging gem5 ans Systemc. This is the approach I and Matthias implemented and presented last year. It provides bridges between the gem5 and SystemC communication interfaces, as well as a wrapper SystemC module that hosts a complete gem5 simulation on top of the SystemC kernel. While this approach certainly has limitations, it allows to combine gem5 and SystemC models. 2. Implementing the SystemC standard using gem5 This is the approach proposed by Gabe which, as I understand it, provides a wrapper around gem5 implementing the SystemC standard. With this approach, gem5 becomes a fully fledged SystemC kernel which arbitrary standard compliant SystemC models can run on. Compared to approach 1, this allows for more interaction between both domains, as everything can be compiled in a single pass and there is not just one single point of interaction. However, this approach prevents certain use cases, e.g. where SystemC models are closed source or where a specific SystemC implementation is required. 3. Replacing the gem5 simulation kernel by SystemC. This is the most radical approach but also gives most flexibility. It replaces the entire gem5 simulation kernel by SystemC. In this approach, gem5 could be seen as a system modeling framework and as an abstraction layer on top of SystemC. This would give maximum flexibility as arbitrary SystemC and gem5 models can be combined and even the SystemC kernel can be exchanged arbitrarily. However, it is not clear (at least to me) how exactly gem5 and SystemC modules could be connected and interact with each other. I think for this approach to work, aspects of approach 1 or/and 2 are still required. So as I see it: 3 covers more use cases than 2 but both are in a way superior to the existing approach (1). However, in order to implement 3 a lot of changes to the code base are required. Implementing these changes will take some time, so there will probably be two versions of gem5: a legacy one and the SystemC one. This again produces more work in maintaining the code base. Now I wonder: who is willing to do all this work? While I favour approach 3 for its benefits and the points Matthias made, I still like Gabe's idea very much. It minimizes the changes required to the existing code base while providing many benefits to a broader community. As Gabe mentioned before, his approach neither breaks with the existing bridges implemented by me and Matthias, nor does it prevent implementation of approach 3 in the future. To sum it up: there are no objections from my side. Unfortunately, I am not very active in hardware modeling anymore, but I am very interested in this development and I hope to find the time to have a look on the patches soon. Best, Christian Matthias Jung writes: > Hi Gabe, > > I totally agree with you. SytemC is a standard and the code maintained > by accellera is just an „example“ of how SystemC could be implemented. > > However, that is part of my argument. If I want to use e.g. another > fancy SystemC kernel (e.g. https://dl.acm.org/citation.cfm?id=2987374) > or a commercial one like the one in the Synopsys toolchains, I cannot > use gem5 (beside the coupling that is already there, which has also > several drawbacks). So I like more the separation of simulation models > and the kernel. > > But I also understand it from your side. In Google you don’t have this > specific need and you want to find quickly a solution with less effort. > Anyway we should discuss if a full switch to SystemC as a kernel might > be a reasonable long term goal. I think many people would benefit from > that. > > I’m also keen to know Christian’s, Andreas’ and Jason’s opinions. > > It’s a pitty that gem5 and SystemC started back at the same time > and evolved separately... > > Best, > Matthias > >> Am 09.06.2018 um 02:34 schrieb Gabe Black : >> >> Also, I should point out that the systemc standard defines a set of >> mechanisms and an interface, not an implementation. The Accellera version >> of systemc is *not* the standard, it's just an implementation (a very >> common and important one) of that standard. It's dangerous to conflate >> those two ideas, and it leads to a lot of problems for everybody. >> >> Gabe >> >> On Fri, Jun 8, 2018 at 12:50 PM Gabe Black wrote: >> >>> Giacomo, if you're proposing linking in the systemc library and then >>> adding wrappers to somehow plug that into gem5's underlying mechanisms, I'm >>> not sure that's technically feasible since the existing implementation >>> isn't intended to be built on top of something else. Also a lot of the >>> mechanisms are built into base classes, and so if you change what data >>> members are in the base
[gem5-dev] Change in gem5/gem5[master]: misc: Using smart pointers for memory Requests
Hello Anthony Gutierrez, Daniel Carvalho, Jason Lowe-Power, Andreas Sandberg, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/10996 to look at the new patch set (#3). Change subject: misc: Using smart pointers for memory Requests .. misc: Using smart pointers for memory Requests This patch is changing the underlying type for RequestPtr from Request* to shared_ptr. Having memory requests being managed by smart pointers will simplify the code; it will also prevent memory leakage and dangling pointers. Change-Id: I7749af38a11ac8eb4d53d8df1252951e0890fde3 Signed-off-by: Giacomo Travaglini Reviewed-by: Andreas Sandberg --- M ext/sst/ExtMaster.cc M ext/sst/ExtSlave.cc M src/arch/alpha/locked_mem.hh M src/arch/alpha/tlb.cc M src/arch/alpha/tlb.hh M src/arch/arm/isa.cc M src/arch/arm/locked_mem.hh M src/arch/arm/stage2_lookup.cc M src/arch/arm/stage2_lookup.hh M src/arch/arm/stage2_mmu.cc M src/arch/arm/stage2_mmu.hh M src/arch/arm/table_walker.cc M src/arch/arm/table_walker.hh M src/arch/arm/tlb.cc M src/arch/arm/tlb.hh M src/arch/arm/tracers/tarmac_parser.cc M src/arch/arm/tracers/tarmac_parser.hh M src/arch/arm/vtophys.cc M src/arch/generic/locked_mem.hh M src/arch/generic/tlb.cc M src/arch/generic/tlb.hh M src/arch/hsail/insts/mem.hh M src/arch/mips/locked_mem.hh M src/arch/mips/tlb.cc M src/arch/mips/tlb.hh M src/arch/power/tlb.cc M src/arch/power/tlb.hh M src/arch/riscv/locked_mem.hh M src/arch/riscv/tlb.cc M src/arch/riscv/tlb.hh M src/arch/sparc/tlb.cc M src/arch/sparc/tlb.hh M src/arch/x86/intmessage.hh M src/arch/x86/pagetable_walker.cc M src/arch/x86/pagetable_walker.hh M src/arch/x86/tlb.cc M src/arch/x86/tlb.hh M src/cpu/base.cc M src/cpu/base_dyn_inst.hh M src/cpu/base_dyn_inst_impl.hh M src/cpu/checker/cpu.cc M src/cpu/checker/cpu.hh M src/cpu/checker/cpu_impl.hh M src/cpu/kvm/base.cc M src/cpu/kvm/x86_cpu.cc M src/cpu/minor/fetch1.cc M src/cpu/minor/fetch1.hh M src/cpu/minor/lsq.cc M src/cpu/minor/lsq.hh M src/cpu/o3/cpu.hh M src/cpu/o3/fetch.hh M src/cpu/o3/fetch_impl.hh M src/cpu/o3/lsq.hh M src/cpu/o3/lsq_impl.hh M src/cpu/o3/lsq_unit.hh M src/cpu/o3/lsq_unit_impl.hh M src/cpu/simple/atomic.cc M src/cpu/simple/atomic.hh M src/cpu/simple/base.cc M src/cpu/simple/base.hh M src/cpu/simple/timing.cc M src/cpu/simple/timing.hh M src/cpu/testers/directedtest/InvalidateGenerator.cc M src/cpu/testers/directedtest/RubyDirectedTester.cc M src/cpu/testers/directedtest/SeriesRequestGenerator.cc M src/cpu/testers/garnet_synthetic_traffic/GarnetSyntheticTraffic.cc M src/cpu/testers/memtest/memtest.cc M src/cpu/testers/rubytest/Check.cc M src/cpu/testers/rubytest/RubyTester.cc M src/cpu/testers/traffic_gen/base_gen.cc M src/cpu/testers/traffic_gen/traffic_gen.cc M src/cpu/trace/trace_cpu.cc M src/cpu/translation.hh M src/dev/dma_device.cc M src/dev/x86/i82094aa.cc M src/gpu-compute/compute_unit.cc M src/gpu-compute/fetch_unit.cc M src/gpu-compute/gpu_tlb.cc M src/gpu-compute/gpu_tlb.hh M src/gpu-compute/shader.cc M src/gpu-compute/shader.hh M src/learning_gem5/part2/simple_cache.cc M src/mem/abstract_mem.cc M src/mem/abstract_mem.hh M src/mem/cache/base.cc M src/mem/cache/blk.hh M src/mem/cache/cache.cc M src/mem/cache/mshr.cc M src/mem/cache/noncoherent_cache.cc M src/mem/cache/prefetch/queued.cc M src/mem/packet.hh M src/mem/page_table.cc M src/mem/page_table.hh M src/mem/port.cc M src/mem/port_proxy.cc M src/mem/request.hh M src/mem/ruby/slicc_interface/AbstractController.cc M src/mem/ruby/system/CacheRecorder.cc M src/mem/ruby/system/GPUCoalescer.cc M src/mem/ruby/system/GPUCoalescer.hh M src/mem/ruby/system/RubyPort.cc M src/mem/ruby/system/Sequencer.cc M util/tlm/src/sc_master_port.cc 103 files changed, 609 insertions(+), 651 deletions(-) -- To view, visit https://gem5-review.googlesource.com/10996 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I7749af38a11ac8eb4d53d8df1252951e0890fde3 Gerrit-Change-Number: 10996 Gerrit-PatchSet: 3 Gerrit-Owner: Giacomo Travaglini Gerrit-Reviewer: Andreas Sandberg Gerrit-Reviewer: Anthony Gutierrez Gerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jason Lowe-Power Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: mem-cache: Promote targets that don't require writable
Hello Daniel Carvalho, Jason Lowe-Power, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/11017 to look at the new patch set (#2). Change subject: mem-cache: Promote targets that don't require writable .. mem-cache: Promote targets that don't require writable Until now, all deferred targets of an MSHR would be promoted together as soon as the targets were serviced. Due to the way we handle cache clean operations we might need to promote only deferred targets that don't require writable, leaving some targets as deferred. This change adds support for this selective promotion. Change-Id: I502e523dc9adbaf394955cbacea8286ab6a9b6bc --- M src/mem/cache/mshr.cc M src/mem/cache/mshr.hh 2 files changed, 70 insertions(+), 16 deletions(-) -- To view, visit https://gem5-review.googlesource.com/11017 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I502e523dc9adbaf394955cbacea8286ab6a9b6bc Gerrit-Change-Number: 11017 Gerrit-PatchSet: 2 Gerrit-Owner: Nikos Nikoleris Gerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Nikos Nikoleris Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: misc: Using smart pointers for memory Requests
Hello Anthony Gutierrez, Daniel Carvalho, Jason Lowe-Power, Andreas Sandberg, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/10996 to look at the new patch set (#2). Change subject: misc: Using smart pointers for memory Requests .. misc: Using smart pointers for memory Requests This patch is changing the underlying type for RequestPtr from Request* to shared_ptr. Having memory requests being managed by smart pointers will simplify the code; it will also prevent memory leakage and dangling pointers. Change-Id: I7749af38a11ac8eb4d53d8df1252951e0890fde3 Signed-off-by: Giacomo Travaglini Reviewed-by: Andreas Sandberg --- M ext/sst/ExtMaster.cc M ext/sst/ExtSlave.cc M src/arch/alpha/locked_mem.hh M src/arch/alpha/tlb.cc M src/arch/alpha/tlb.hh M src/arch/arm/isa.cc M src/arch/arm/locked_mem.hh M src/arch/arm/stage2_lookup.cc M src/arch/arm/stage2_lookup.hh M src/arch/arm/stage2_mmu.cc M src/arch/arm/stage2_mmu.hh M src/arch/arm/table_walker.cc M src/arch/arm/table_walker.hh M src/arch/arm/tlb.cc M src/arch/arm/tlb.hh M src/arch/arm/tracers/tarmac_parser.cc M src/arch/arm/tracers/tarmac_parser.hh M src/arch/arm/vtophys.cc M src/arch/generic/locked_mem.hh M src/arch/generic/tlb.cc M src/arch/generic/tlb.hh M src/arch/hsail/insts/mem.hh M src/arch/mips/locked_mem.hh M src/arch/mips/tlb.cc M src/arch/mips/tlb.hh M src/arch/power/tlb.cc M src/arch/power/tlb.hh M src/arch/riscv/locked_mem.hh M src/arch/riscv/tlb.cc M src/arch/riscv/tlb.hh M src/arch/sparc/tlb.cc M src/arch/sparc/tlb.hh M src/arch/x86/intmessage.hh M src/arch/x86/pagetable_walker.cc M src/arch/x86/pagetable_walker.hh M src/arch/x86/tlb.cc M src/arch/x86/tlb.hh M src/cpu/base.cc M src/cpu/base_dyn_inst.hh M src/cpu/base_dyn_inst_impl.hh M src/cpu/checker/cpu.cc M src/cpu/checker/cpu.hh M src/cpu/checker/cpu_impl.hh M src/cpu/kvm/base.cc M src/cpu/kvm/x86_cpu.cc M src/cpu/minor/fetch1.cc M src/cpu/minor/fetch1.hh M src/cpu/minor/lsq.cc M src/cpu/minor/lsq.hh M src/cpu/o3/fetch.hh M src/cpu/o3/fetch_impl.hh M src/cpu/o3/lsq.hh M src/cpu/o3/lsq_impl.hh M src/cpu/o3/lsq_unit.hh M src/cpu/o3/lsq_unit_impl.hh M src/cpu/simple/atomic.cc M src/cpu/simple/atomic.hh M src/cpu/simple/base.cc M src/cpu/simple/base.hh M src/cpu/simple/timing.cc M src/cpu/simple/timing.hh M src/cpu/testers/directedtest/InvalidateGenerator.cc M src/cpu/testers/directedtest/RubyDirectedTester.cc M src/cpu/testers/directedtest/SeriesRequestGenerator.cc M src/cpu/testers/garnet_synthetic_traffic/GarnetSyntheticTraffic.cc M src/cpu/testers/memtest/memtest.cc M src/cpu/testers/rubytest/Check.cc M src/cpu/testers/rubytest/RubyTester.cc M src/cpu/testers/traffic_gen/base_gen.cc M src/cpu/testers/traffic_gen/traffic_gen.cc M src/cpu/trace/trace_cpu.cc M src/cpu/translation.hh M src/dev/dma_device.cc M src/dev/x86/i82094aa.cc M src/gpu-compute/compute_unit.cc M src/gpu-compute/fetch_unit.cc M src/gpu-compute/gpu_tlb.cc M src/gpu-compute/gpu_tlb.hh M src/gpu-compute/shader.cc M src/gpu-compute/shader.hh M src/learning_gem5/part2/simple_cache.cc M src/mem/abstract_mem.cc M src/mem/abstract_mem.hh M src/mem/cache/base.cc M src/mem/cache/blk.hh M src/mem/cache/cache.cc M src/mem/cache/mshr.cc M src/mem/cache/noncoherent_cache.cc M src/mem/cache/prefetch/queued.cc M src/mem/packet.hh M src/mem/page_table.cc M src/mem/page_table.hh M src/mem/port.cc M src/mem/port_proxy.cc M src/mem/request.hh M src/mem/ruby/slicc_interface/AbstractController.cc M src/mem/ruby/system/CacheRecorder.cc M src/mem/ruby/system/GPUCoalescer.cc M src/mem/ruby/system/GPUCoalescer.hh M src/mem/ruby/system/RubyPort.cc M src/mem/ruby/system/Sequencer.cc M util/tlm/src/sc_master_port.cc 102 files changed, 555 insertions(+), 636 deletions(-) -- To view, visit https://gem5-review.googlesource.com/10996 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I7749af38a11ac8eb4d53d8df1252951e0890fde3 Gerrit-Change-Number: 10996 Gerrit-PatchSet: 2 Gerrit-Owner: Giacomo Travaglini Gerrit-Reviewer: Andreas Sandberg Gerrit-Reviewer: Anthony Gutierrez Gerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jason Lowe-Power Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Cron /z/m5/regression/do-regression quick
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/minor-timing: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/o3-timing: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-atomic: FAILED! *** diff[simout]: SKIPPED* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing: FAILED! *** stat_diff: FAILURE: Statistics mismatchStatistics mismatch* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing-ruby: FAILED! *** diff[simerr]: SKIPPED* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/o3-timing: FAILED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: CHANGED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: CHANGED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: CHANGED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby: CHANGED!*** diff[simerr]: SKIPPED * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: CHANGED! * build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple: CHANGED! * build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level: CHANGED! * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: CHANGED!* build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual: CHANGED! * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: CHANGED! * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual: CHANGED! * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: CHANGED! * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: CHANGED!Maximum error magnitude: +18.899759% * build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple: CHANGED! * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: CHANGED! * build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level: CHANGED! * build/NULL/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby: CHANGED! * build/NULL/tests/opt/quick/se/80.dram-closepage/null/none/dram-lowp: CHANGED! * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl: CHANGED! * build/NULL_MOESI_hammer/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_hammer: CHANGED! * build/NULL_MESI_Two_Level/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MESI_Two_Level: CHANGED! * build/NULL_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory: CHANGED! * build/NULL_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_token: CHANGED! * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: CHANGED! * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby: CHANGED!*** stat_diff: FAILURE: Statistics mismatch * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: CHANGED!Statistics mismatch * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: CHANGED! * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing: CHANGED! Statistics mismatch* build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-two-level: CHANGED! * build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple: CHANGED! * build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp: CHANGED!--- quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp --- * build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp: CHANGED! * build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-timing-mp: CHANGED! * build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-timing: CHANGED! * build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-timing: CHANGED! * build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing: CHANGED!*** stat_diff: FAILURE: Statistics mismatch * build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic: CHANGED! * build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby: CHANGED! * build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing: CHANGED! * build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-simple: CHANGED! * build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-two-level: CHANGED!*** stat_diff: FAILURE: Statistics mismatch * build/X86/tests/opt/quick/se/10.mcf/x86/linux/simple-atomic: CHANGED! *** diff[smred.pl2]: SKIPPED* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-atomic: CHANGED! * build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-timing:
