website: Merge branch stable branch into develop
Change-Id: I624e77d68c4e55e6501b34d4dd73602ee74bc15a
diff --git a/_data/documentation.yml b/_data/documentation.yml
index a090246..e531391 100755
--- a/_data/documentation.yml
+++ b/_data/documentation.yml
@@ -40,6 +40,8 @@
url: http://doxygen.gem5.org/release/v20-1-0-5/index.html
- page: v21.0.0.0
url: http://doxygen.gem5.org/release/v21-0-0-0/index.html
+ - page: v21.0.1.0
+ url: http://doxygen.gem5.org/release/v21-0-1-0/index.html
- title: gem5 Resources
id: gem5_resources
@@ -217,10 +219,6 @@
url: /documentation/learning_gem5/part1/example_configs
- page: Extending gem5 for ARM
url: /documentation/learning_gem5/part1/extending_configs
- - page: ARM Power Modelling
- url: /documentation/learning_gem5/part1/arm_power_modelling
- - page: ARM DVFS Support
- url: /documentation/learning_gem5/part1/arm_dvfs_support
- title: Modifying/Extending
id: part2
diff --git a/_pages/documentation/general_docs/building/extras.md b/_pages/documentation/general_docs/building/extras.md
index 46cd3ce..69cd285 100644
--- a/_pages/documentation/general_docs/building/extras.md
+++ b/_pages/documentation/general_docs/building/extras.md
@@ -17,12 +17,12 @@
The following examples show how to compile the EIO code. By adding to or modifying the extras path, any other suitable extra could be compiled in. To compile in code using EXTRAS simply execute the following
```js
- scons EXTRAS=/path/to/encumbered build/ALPHA/gem5.opt
+ scons EXTRAS=/path/to/encumbered build/<ISA>/gem5.opt
```
In the root of this directory you should have a SConscript that uses the ```Source()``` and ```SimObject()``` scons functions that are used in the rest of M5 to compile the appropriate sources and add any SimObjects of interest. If you want to add more than one directory, you can set EXTRAS to a colon-separated list of paths.
-Note that EXTRAS is a "sticky" parameter, so after a value is provided to scons once, the value will be reused for future scons invocations targeting the same build directory (```build/ALPHA_SE``` in this case) as long as it is not overridden. Thus you only need to specify EXTRAS the first time you build a particular configuration or if you want to override a previously specified value.
+Note that EXTRAS is a "sticky" parameter, so after a value is provided to scons once, the value will be reused for future scons invocations targeting the same build directory (```build/<ISA>``` in this case) as long as it is not overridden. Thus you only need to specify EXTRAS the first time you build a particular configuration or if you want to override a previously specified value.
To run a regression with EXTRAS use a command line similar to the following:
```js
./util/regress --scons-opts = "EXTRAS=/path/to/encumbered" -j 2 quick
diff --git a/_pages/documentation/general_docs/checkpoints.md b/_pages/documentation/general_docs/checkpoints.md
index 1417381..a61c5cd 100644
--- a/_pages/documentation/general_docs/checkpoints.md
+++ b/_pages/documentation/general_docs/checkpoints.md
@@ -20,9 +20,9 @@
Restoring from a checkpoint can usually be easily done from the command line, e.g.:
```
- build/ALPHA/gem5.debug configs/example/fs.py -r N
+ build/<ISA>/gem5.debug configs/example/fs.py -r N
OR
- build/ALPHA/gem5.debug configs/example/fs.py --checkpoint-restore=N
+ build/<ISA>/gem5.debug configs/example/fs.py --checkpoint-restore=N
```
The number N is integer that represents checkpoint number which usually starts from 1 then increases incrementally to 2,3,4...
diff --git a/_pages/documentation/general_docs/debugging_and_testing/debugging/debugger_based_debugging.md b/_pages/documentation/general_docs/debugging_and_testing/debugging/debugger_based_debugging.md
index eb2ef2b..5b6bd39 100644
--- a/_pages/documentation/general_docs/debugging_and_testing/debugging/debugger_based_debugging.md
+++ b/_pages/documentation/general_docs/debugging_and_testing/debugging/debugger_based_debugging.md
@@ -25,12 +25,12 @@
session illustrates both of these approaches:
```
-% gdb m5/build/ALPHA/gem5.debug
+% gdb m5/build/<ISA>/gem5.debug
GNU gdb 6.1
Copyright 2002 Free Software Foundation, Inc.
[...]
(gdb) run --debug-break=2000 configs/run.py
-Starting program: /z/stever/bk/m5/build/ALPHA/gem5.debug --debug-break=2000 configs/run.py
+Starting program: /z/stever/bk/m5/build/<ISA>/gem5.debug --debug-break=2000 configs/run.py
M5 Simulator System
[...]
warn: Entering event queue @ 0. Starting simulation...
diff --git a/_pages/documentation/general_docs/debugging_and_testing/debugging/debugging_simulated_code.md b/_pages/documentation/general_docs/debugging_and_testing/debugging/debugging_simulated_code.md
index 5cc7e10..c2327ee 100644
--- a/_pages/documentation/general_docs/debugging_and_testing/debugging/debugging_simulated_code.md
+++ b/_pages/documentation/general_docs/debugging_and_testing/debugging/debugging_simulated_code.md
@@ -29,31 +29,30 @@
To attach the remote debugger, it's necessary to have a copy of the kernel and
of the source. Also to view the kernel's call stack, you must make sure Linux
was built with the necessary debug configuration parameters enabled. To run the
-remote debugger, do the following:
+remote debugger, do the following (assuming host=localhost and port=7000):
```
-ziff% gdb-linux-alpha arch/alpha/boot/vmlinux
-GNU gdb
-Copyright 2002 Free Software Foundation, Inc.
-GDB is free software, covered by the GNU General Public License, and you are
-welcome to change it and/or distribute copies of it under certain conditions.
-Type "show copying" to see the conditions.
-There is absolutely no warranty for GDB. Type "show warranty" for details.
-This GDB was configured as "--host=i686-pc-linux-gnu --target=alpha-linux"...
-(no debugging symbols found)...
-(gdb) set remote Z-packet on [ This can be put in .gdbinit ]
-(gdb) target remote ziff:7000
-Remote debugging using ziff:7000
-0xfffffc0000496844 in strcasecmp (a=0xfffffc0000b13a80 "", b=0x0)
- at arch/alpha/lib/strcasecmp.c:23
-23 } while (ca == cb && ca != '\0');
-(gdb)
+gdb-multiarch <path-to-linux>/vmlinux
+GNU gdb (Ubuntu 8.2-0ubuntu1~18.04) 8.2
+Copyright (C) 2018 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "x86_64-linux-gnu".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<http://www.gnu.org/software/gdb/bugs/>.
+Find the GDB manual and other documentation resources online at:
+ <http://www.gnu.org/software/gdb/documentation/>.
+
+(gdb) target remote <host>:<port>
```
The gem5 simulator is already running and the target remote command connects to
the already running simulator and stops it in the middle of execution. You can
set breakpoints and use the debugger to debug the kernel. It is also possible
-to use the remote debugger to debug console code and palcode. Setting that up
+to use the remote debugger to debug console code. Setting that up
is similar, but a how to will be left for future work.
If you're using both the remote debugger and the debugger on the simulator, it
@@ -67,7 +66,7 @@
listening on port 7001.
```
-%./build/ALPHA/gem5.debug configs/example/fs.py
+%./build/<ISA>/gem5.debug configs/example/fs.py
...
making dual system
Global frequency set at 1000000000000 ticks per second
@@ -86,32 +85,26 @@
## Getting a cross-architecture gdb
To use a remote debugger with gem5, the most important part is that you have
-gdb compiled to work with the target system you're simulating (e.g.
-`alpha-linux` if simulating an `Alpha` target, arm-linux if simulating an
-`ARM` target, etc). It is possible to compile an non-native architecture gdb on
-an `x86` machine for example. All that must be done is add the `--target=`
+gdb compiled to work with the target system you're simulating.
+The recommended approach is to install the gdb-multiarch package,
+providing a single gdb binary usable for multiple ISAs (archs)
+
+```
+% sudo apt-get update -y
+% sudo apt-get install -y gdb-multiarch
+```
+
+It is possible to compile a non-native architecture gdb on
+the host machine as an alternative. All that must be done is add the `--target=`
option to configure when you compile gdb. You may also get pre-compiled
debuggers with cross compilers. See Download for links to some cross compilers
that include debuggers.
```
-% wget http://ftp.gnu.org/gnu/gdb/gdb-6.3.tar.gz
---08:05:33-- http://ftp.gnu.org/gnu/gdb/gdb-6.3.tar.gz
- => `gdb-6.3.tar.gz'
-Resolving ftp.gnu.org... done.
-Connecting to ftp.gnu.org[199.232.41.7]:80... connected.
-HTTP request sent, awaiting response... 200 OK
-Length: 17,374,476 [application/x-tar]
-
-100%[====================================>] 17,374,476 216.57K/s ETA 00:00
-
-08:06:52 (216.57 KB/s) - `gdb-6.3.tar.gz' saved [17374476/17374476]
-```
-
-```
-% tar xfz gdb-6.3.tar.gz
-% cd gdb-6.3
-% ./configure --target=alpha-linux
+% wget http://ftp.gnu.org/gnu/gdb/<gdb-version>.tar.gz
+% tar xfz <gdb-version>.tar.gz
+% cd <gdb-version>
+% ./configure --target=<isa>
<configure output....>
% make
<make output...this may take a while>
diff --git a/_pages/documentation/general_docs/debugging_and_testing/debugging/trace_baced_debugging.md b/_pages/documentation/general_docs/debugging_and_testing/debugging/trace_baced_debugging.md
index cfc1a8d..177f1cb 100644
--- a/_pages/documentation/general_docs/debugging_and_testing/debugging/trace_baced_debugging.md
+++ b/_pages/documentation/general_docs/debugging_and_testing/debugging/trace_baced_debugging.md
@@ -19,7 +19,7 @@
Multiple flags can be specified by giving a list of strings, e.g.:
```
-build/ALPHA/gem5.opt --debug-flags=Bus,Cache configs/examples/fs.py
+build/<ISA>/gem5.opt --debug-flags=Bus,Cache configs/examples/fs.py
```
would turn on a group of debug flags related to instruction execution but leave
diff --git a/_pages/documentation/general_docs/developement/coding_style.md b/_pages/documentation/general_docs/developement/coding_style.md
index 31598ba..56240d8 100644
--- a/_pages/documentation/general_docs/developement/coding_style.md
+++ b/_pages/documentation/general_docs/developement/coding_style.md
@@ -397,4 +397,4 @@
* `warn()` and `warn_once()` should be called when some functionality isn't necessarily implemented correctly, but it might work well enough. The idea behind a `warn()` is to inform the user that if they see some strange behavior shortly after a `warn()` the description might be a good place to go looking for an error.
* `hack()` should be called when some functionality isn't implemented nearly as well as it could or should be but for expediency or history sake hasn't been fixed.
-* `inform()` Provides status messages and normal operating messages to the console for the user to see, without any connotations of incorrect behavior. For example it's used when secondary CPUs being executing code on ALPHA.
+* `inform()` Provides status messages and normal operating messages to the console for the user to see, without any connotations of incorrect behavior.
diff --git a/_pages/documentation/general_docs/fullsystem/building_arm_kernel.md b/_pages/documentation/general_docs/fullsystem/building_arm_kernel.md
index 5e22321..47d85bf 100644
--- a/_pages/documentation/general_docs/fullsystem/building_arm_kernel.md
+++ b/_pages/documentation/general_docs/fullsystem/building_arm_kernel.md
@@ -34,13 +34,9 @@
details.
## Linux 4.x
-Newer gem5 kernels for ARM (v4.x and later) are based on the vanilla Linux kernel and typically have a small number of patches to make them work better with gem5. The patches are optional and you should be able to use a vanilla kernel as well. However, this requires you to configure the kernel yourself. Newer kernels all use the VExpress\_GEM5\_V1 gem5 platform for both AArch32 and AArch64. The required DTB files to describe the hardware to the OS ship with gem5. To build them, execute this command:
+Newer gem5 kernels for ARM (v4.x and later) are based on the vanilla Linux kernel and typically have a small number of patches to make them work better with gem5. The patches are optional and you should be able to use a vanilla kernel as well. However, this requires you to configure the kernel yourself. Newer kernels all use the VExpress\_GEM5\_V1 gem5 platform for both AArch32 and AArch64.
-```
-make -C system/arm/dt
-```
-
-## Kernel Checkout
+# Kernel Checkout
To checkout the kernel, execute the following command:
```
@@ -52,22 +48,7 @@
git checkout -b gem5/v4.14
```
-## AArch32
-To compile the kernel, execute the following commands in the repository:
-
-```
-make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- gem5_defconfig
-make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j `nproc`
-```
-
-Testing the just built kernel:
-
-```
-./build/ARM/gem5.opt configs/example/fs.py --kernel=/tmp/linux-arm-gem5/vmlinux --machine-type=VExpress_GEM5_V1 \
- --dtb-file=$PWD/system/arm/dt/armv7_gem5_v1_1cpu.dtb
-```
-
-## AArch64
+# Kernel build
To compile the kernel, execute the following commands in the repository:
```
@@ -82,67 +63,6 @@
--disk-image=ubuntu-18.04-arm64-docker.img
```
-# Legacy kernels (pre v4.x)
-Older gem5 kernels for ARM (pre v4.x) are based on Linaro's Linux kernel for ARM. These kernels use either the VExpress\_EMM (AArch32) or VExpress\_EMM64 (AArch64) gem5 platform. Unlike the newer kernels, there is a separate AArch32 and AArch64 kernel repository and the device tree files are shipped with the kernel.
-
-## 32 bit kernel (AArch32)
-These are instructions to generate a 32-bit ARM Linux binary.
-
-To checkout the aarch32 kernel, execute the following command:
-
-```
-git clone https://gem5.googlesource.com/arm/linux-arm-legacy
-```
-
-The repository contains a tag per gem5 kernel release. Check the [project page](https://gem5-review.googlesource.com/#/admin/projects/arm/linux-arm-legacy) for a list of branches and release tags. To checkout a tag, execute the following in the repository:
-
-```
-git checkout -b TAGNAME
-```
-
-To compile the kernel, execute the following commands in the repository:
-
-```
-make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- vexpress_gem5_server_defconfig
-make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j `nproc`
-```
-
-Testing the just built kernel:
-
-```
-./build/ARM/gem5.opt configs/example/fs.py --kernel=/tmp/linux-arm-gem5/vmlinux \
- --machine-type=VExpress_EMM --dtb-file=/tmp/linux-arm-gem5/arch/arm/boot/dts/vexpress-v2p-ca15-tc1-gem5.dtb
-```
-
-## 64 bit kernel (AArch64)
-These are instructions to generate a 64-bit ARM Linux binary.
-
-To checkout the aarch64 kernel, execute the following command:
-
-```
-git clone https://gem5.googlesource.com/arm/linux-arm64-legacy
-```
-
-The repository contains a tag per gem5 kernel release. Check the [project page](https://gem5-review.googlesource.com/#/admin/projects/arm/linux-arm64-legacy) for a list of branches and release tags. To checkout a tag, execute the following in the repository:
-
-```
-git checkout -b TAGNAME
-```
-
-To compile the kernel, execute the following commands in the repository:
-
-```
-make ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- gem5_defconfig
-make ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- -j4
-```
-
-Testing the just built kernel:
-
-```
-./build/ARM/gem5.opt configs/example/fs.py --kernel=/tmp/linux-arm64-gem5/vmlinux --machine-type=VExpress_EMM64 \
- --dtb-file=/tmp/linux-arm64-gem5/arch/arm64/boot/dts/aarch64_gem5_server.dtb --disk-image=linaro-minimal-aarch64.img
-```
-
# Bootloaders
There are two different bootloaders for gem5. One of 32-bit kernels and one for 64-bit kernels. They can be compiled using the following command:
@@ -151,5 +71,14 @@
make -C system/arm/bootloader/arm64
```
+# Device Tree Blobs
+The required DTB files to describe the hardware to the OS ship with gem5. To build them, execute this command:
+
+```
+make -C system/arm/dt
+```
+
+We recommend to use these device tree files only if you are planning to amend them. If not, we recommend you to rely on DTB autogeneration: by running a FS script without the --dtb option, gem5 will automatically generate the DTB on the fly depending on the instantiated platform.
+
Once you have compiled the binaries, put them in the binaries directory in your
`M5_PATH`.
diff --git a/_pages/documentation/general_docs/fullsystem/guest_binaries.md b/_pages/documentation/general_docs/fullsystem/guest_binaries.md
index 1cbd6a3..4432ace 100644
--- a/_pages/documentation/general_docs/fullsystem/guest_binaries.md
+++ b/_pages/documentation/general_docs/fullsystem/guest_binaries.md
@@ -25,7 +25,7 @@
The tarball below contains a set of binaries: the Linux kernel and a set of bootloaders
-* <http://dist.gem5.org/dist/current/arm/aarch-system-201901106.tar.bz2>
+* <http://dist.gem5.org/dist/v21-0/arm/aarch-system-20210904.tar.bz2>
##### Latest Linux Disk Images (**recommended**)
@@ -33,7 +33,10 @@
Partition table: yes
- gem5 init: `/init.gem5`
+ gem5 init:
+ * default (using m5 ops): `/init.gem5`
+ * kvm (using m5 --addr ops): `/init.addr.gem5`
+ * fast models (using m5 --semi ops): `/init.semi.gem5`
* <http://dist.gem5.org/dist/current/arm/disks/aarch32-ubuntu-natty-headless.img.bz2>
diff --git a/_pages/documentation/general_docs/gem5_resources.md b/_pages/documentation/general_docs/gem5_resources.md
index f3b4c01..cb86fed 100644
--- a/_pages/documentation/general_docs/gem5_resources.md
+++ b/_pages/documentation/general_docs/gem5_resources.md
@@ -47,8 +47,8 @@
|simple/m5_exit | [x86 executable](https://dist.gem5.org/dist/v20-1/test-progs/m5-exit/bin/x86/linux/m5_exit) | [here (Along with other 'simple' executables)](https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/simple) |
|insttest | [insttest](https://dist.gem5.org/dist/v20-1/test-progs/insttest/bin/sparc/linux/insttest)| [here](https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/insttest) |
|square | [square.o](https://dist.gem5.org/dist/v20-1/test-progs/square/square.o) | [here](https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/square) |
-|spec-2006 | --- | [here](https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/spec-2017) |
-|spec-2017 | --- | [here](https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/spec-2006) |
+|spec-2006 | --- | [here](https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/spec-2006) |
+|spec-2017 | --- | [here](https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/spec-2017) |
|gapbs | [Disk Image (GZIPPED)](http://dist.gem5.org/dist/v20-1/images/x86/ubuntu-18-04/gapbs.img.gz) | [here](https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/gapbs) |
|parsec | [Disk Image (GZIPPED)](http://dist.gem5.org/dist/v20-1/images/x86/ubuntu-18-04/parsec.img.gz) | [here](https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/parsec) |
|npb | [Disk Image (GZIPPED)](http://dist.gem5.org/dist/v20-1/images/x86/ubuntu-18-04/npb.img.gz) | [here](https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/npb) |
diff --git a/_pages/documentation/general_docs/gpu_models/gcn3.md b/_pages/documentation/general_docs/gpu_models/gcn3.md
index fe006a7..15b9eb3 100644
--- a/_pages/documentation/general_docs/gpu_models/gcn3.md
+++ b/_pages/documentation/general_docs/gpu_models/gcn3.md
@@ -22,15 +22,25 @@
Thus, you should use the develop branch when running the GCN3 model.
We expect this support to be integrated into the gem5-v21.0 release.
-The [gem5 repository](https://gem5.goooglesource.com/public/gem5) comes with a dockerfile located in `util/dockerfiles/gcn-gpu/`. This dockerfile contains the drivers and libraries needed to run the GPU model
+The [gem5 repository](https://gem5.goooglesource.com/public/gem5) comes with a dockerfile located in `util/dockerfiles/gcn-gpu/`. This dockerfile contains the drivers and libraries needed to run the GPU model. A pre-built version of the docker image is hosted at `gcr.io/gem5-test/gcn-gpu`.
The [gem5-resources repository](https://gem5.googlesource.com/public/gem5-resources/) also comes with a sample application (square) that can be used to verify that the model runs correctly.
-#### Building the image
+#### Using the image
+The docker image can either be built or pulled from gcr.io
+
+To build the docker image from source:
```
+# Working directory: gem5/util/dockerfiles/gcn-gpu
docker build -t <image_name> .
```
+To pull the pre-built docker image:
+```
+docker pull gcr.io/gem5-test/gcn-gpu
+```
+You can also put `gcr.io/gem5-test/gcn-gpu` as the image in the docker run command without pulling beforehand and it will be pulled automatically.
+
#### Building gem5 using the image
The following command assumes the gem5 directory is a subdirectory of your current directory
```
@@ -40,7 +50,7 @@
#### Building a GPU application using the image
The following command assumes the gem5-resources directory is a subdirectory of your current directory
```
-docker run --rm -v $PWD/gem5-resources:/gem5-resources -w /gem5-resources <image_name> make square
+docker run --rm -v $PWD/gem5-resources:$PWD/gem5-resources -w $PWD/gem5-resources/src/square <image_name> make gfx8-apu
```
#### Running the sample application
@@ -49,8 +59,8 @@
docker run --rm -v $PWD/gem5:/gem5 -v $PWD/gem5-resources:/gem5-resources \
-w /gem5 <image_name> \
build/GCN3_X86/gem5.opt configs/example/apu_se.py -n2 \
- --benchmark-root=/gem5-resources/output/test-progs/square \
- -c square
+ --benchmark-root=/gem5-resources/src/square/bin \
+ -c square.o
```
## **ROCm**
diff --git a/_pages/documentation/general_docs/m5ops.md b/_pages/documentation/general_docs/m5ops.md
index d5a6eaf..985a2ec 100644
--- a/_pages/documentation/general_docs/m5ops.md
+++ b/_pages/documentation/general_docs/m5ops.md
@@ -24,10 +24,13 @@
* arm (arm-linux-gnueabihf-gcc)
* thumb (arm-linux-gnueabihf-gcc)
* sparc (sparc64-linux-gnu-gcc)
-* aarch64 (aarch64-linux-gnu-gcc)
+* arm64 (aarch64-linux-gnu-gcc)
+* riscv (riscv64-linux-gnu-gcc)
Note if you are using a x86 system for other ISAs you need to have the cross-compiler installed. The name of the cross-compiler is shown inside the parentheses in the list above.
+See util/m5/README.md for more details.
+
## The m5 Utility (FS mode)
The m5 utility (see util/m5/) can be used in FS mode to issue special instructions to trigger simulation specific functionality. It currently offers the following options:
diff --git a/_pages/documentation/general_docs/ruby/interconnection-network.md b/_pages/documentation/general_docs/ruby/interconnection-network.md
index 1774f48..dfeae63 100644
--- a/_pages/documentation/general_docs/ruby/interconnection-network.md
+++ b/_pages/documentation/general_docs/ruby/interconnection-network.md
@@ -17,7 +17,7 @@
**Simple Network**:
```
-./build/ALPHA/gem5.debug \
+./build/<ISA>/gem5.debug \
configs/example/ruby_random_test.py \
--num-cpus=16 \
--num-dirs=16 \
@@ -31,7 +31,7 @@
**Garnet network**:
```
-./build/ALPHA/gem5.debug \
+./build/<ISA>/gem5.debug \
configs/example/ruby_random_test.py \
--num-cpus=16 \
--num-dirs=16 \
diff --git a/_pages/documentation/learning_gem5/part1/part1_2_simple_config.md b/_pages/documentation/learning_gem5/part1/part1_2_simple_config.md
index 3bd3133..8f5e405 100644
--- a/_pages/documentation/learning_gem5/part1/part1_2_simple_config.md
+++ b/_pages/documentation/learning_gem5/part1/part1_2_simple_config.md
@@ -142,8 +142,8 @@
the membus. In this example system, we have no caches.
```
-system.cpu.icache_port = system.membus.slave
-system.cpu.dcache_port = system.membus.slave
+system.cpu.icache_port = system.membus.cpu_side_ports
+system.cpu.dcache_port = system.membus.cpu_side_ports
```
> **An aside on gem5 ports**
@@ -182,11 +182,11 @@
```
system.cpu.createInterruptController()
-system.cpu.interrupts[0].pio = system.membus.master
-system.cpu.interrupts[0].int_master = system.membus.slave
-system.cpu.interrupts[0].int_slave = system.membus.master
+system.cpu.interrupts[0].pio = system.membus.mem_side_ports
+system.cpu.interrupts[0].int_requestor = system.membus.cpu_side_ports
+system.cpu.interrupts[0].int_responder = system.membus.mem_side_ports
-system.system_port = system.membus.slave
+system.system_port = system.membus.cpu_side_ports
```
Next, we need to create a memory controller and connect it to the
@@ -194,9 +194,10 @@
be responsible for the entire memory range of our system.
```
-system.mem_ctrl = DDR3_1600_8x8()
-system.mem_ctrl.range = system.mem_ranges[0]
-system.mem_ctrl.port = system.membus.master
+system.mem_ctrl = MemCtrl()
+system.mem_ctrl.dram = DDR3_1600_8x8()
+system.mem_ctrl.dram.range = system.mem_ranges[0]
+system.mem_ctrl.dram.port = system.membus.mem_side_ports
```
After those final connections, we've finished instantiating our
@@ -241,8 +242,13 @@
execution contexts in the CPU.
```
+binary = 'tests/test-progs/hello/bin/x86/linux/hello'
+
+#for gem5 V21 and beyond, uncomment the following line
+#system.workload = SEWorkload.init_compatible(binary)
+
process = Process()
-process.cmd = ['tests/test-progs/hello/bin/x86/linux/hello']
+process.cmd = [binary]
system.cpu.workload = process
system.cpu.createThreads()
```
diff --git a/_pages/documentation/learning_gem5/part1/part1_3_cache_config.md b/_pages/documentation/learning_gem5/part1/part1_3_cache_config.md
index 8f51044..2cc018f 100644
--- a/_pages/documentation/learning_gem5/part1/part1_3_cache_config.md
+++ b/_pages/documentation/learning_gem5/part1/part1_3_cache_config.md
@@ -221,8 +221,8 @@
ports directly to the memory bus.
```
-system.cpu.icache_port = system.membus.slave
-system.cpu.dcache_port = system.membus.slave
+system.cpu.icache_port = system.membus.cpu_side_ports
+system.cpu.dcache_port = system.membus.cpu_side_ports
```
We can't directly connect the L1 caches to the L2 cache since the L2
diff --git a/_pages/documentation/learning_gem5/part1/part1_6_extending_configs.md b/_pages/documentation/learning_gem5/part1/part1_6_extending_configs.md
index ae4117a..58019fe 100644
--- a/_pages/documentation/learning_gem5/part1/part1_6_extending_configs.md
+++ b/_pages/documentation/learning_gem5/part1/part1_6_extending_configs.md
@@ -1,6 +1,6 @@
---
layout: documentation
-title: Extending gem5 to run ARM binaries
+title: Extending gem5 for ARM
doc: Learning gem5
parent: part1
permalink: /documentation/learning_gem5/part1/extending_configs
@@ -22,8 +22,8 @@
```
mkdir -p cpu_tests/benchmarks/bin/arm
cd cpu_tests/benchmarks/bin/arm
-wget gem5.org/dist/current/gem5/cpu_tests/benchmarks/bin/arm/Bubblesort
-wget gem5.org/dist/current/gem5/cpu_tests/benchmarks/bin/arm/FloatMM
+wget dist.gem5.org/dist/current/gem5/cpu_tests/benchmarks/bin/arm/Bubblesort
+wget dist.gem5.org/dist/current/gem5/cpu_tests/benchmarks/bin/arm/FloatMM
```
We'll use these to further test our ARM system.
diff --git a/_posts/2020-10-27-tme.md b/_posts/2020-10-27-tme.md
index b6d0486..ce49f11 100644
--- a/_posts/2020-10-27-tme.md
+++ b/_posts/2020-10-27-tme.md
@@ -10,6 +10,8 @@
**This post was originally posted on the Arm Research Blog: [here](
https://community.arm.com/developer/research/b/articles/posts/arms-transactional-memory-extension-support-)**
+April 16 2021: The code example in this article has been updated to reflect the [Armv9-A architecture](https://www.arm.com/company/news/2021/03/arms-answer-to-the-future-of-ai-armv9-architecture?_ga=2.247379204.1872122303.1618821498-1812760823.1604088481) release and to be functional with respect to the gem5/ruby model.
+
## A shift to concurrency
In 2005, Herb Sutter published his seminal article “The Free Lunch is Over” (Sutter, 2005). He outlined that the sequential performance of microprocessors would soon plateau, and the industry would respond by offering more performant processors by way of increased core counts. The consequence of this paradigm shift has been a move away from a purely sequential programming model for writing software to that of a concurrent one with multiple threads of execution. When applications inherently exhibit parallelism, dividing work between multiple threads can yield performance gains when the threads execute on different cores.
@@ -24,7 +26,7 @@
## Arm's TME
-The [Transactional Memory Extension (TME)](https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture) is part of Arm’s A-profile Future Architecture Technologies program, which provides advanced information on unreleased versions of the architecture. TME is a best effort HTM architecture which does not guarantee completion of transactions. The programmer must provide a fallback path to guarantee progress, such as a mutex-guarded critical section. It provides strong isolation, meaning transactions are isolated from both other transactions, and concurrent non-transactional memory accesses. It uses flattened nesting of transactions, in which nested transactions are subsumed by the outer transaction. The effects of a nested transaction do not become visible to other observers until the outer transaction commits. When a nested transaction aborts, it causes the outer transaction (and all its nested transactions within) to abort.
+The [Transactional Memory Extension (TME)](https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture) is an optional feature of [Armv9](https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools/armv9-a-a64-instruction-set-architecture-release-notes?_ga=2.155180600.1872122303.1618821498-1812760823.1604088481) (previously a part of Arm’s A-profile Future Architecture Technologies program). TME is a best effort HTM architecture which does not guarantee completion of transactions. The programmer must provide a fallback path to guarantee progress, such as a mutex-guarded critical section. It provides strong isolation, meaning transactions are isolated from both other transactions, and concurrent non-transactional memory accesses. It uses flattened nesting of transactions, in which nested transactions are subsumed by the outer transaction. The effects of a nested transaction do not become visible to other observers until the outer transaction commits. When a nested transaction aborts, it causes the outer transaction (and all its nested transactions within) to abort.
TME comprises four instructions:
@@ -70,7 +72,12 @@
To test the new functionality in gem5, we outline a simple program written in C that uses TME transactions to update a histogram in parallel. This program uses manual lock elision—a lock is used to protect a shared data structure but is bypassed, that is, elided, whenever possible in favor of transactions. This satisfies the requirements of a fallback path if a transaction cannot make progress.
-We first define a very simple spinlock that works with [AArch64](https://developer.arm.com/architectures/learn-the-architecture/aarch64-instruction-set-architecture?_ga=2.17759802.282459154.1604342475-1664555334.1603995267)’s weak memory model.
+We first define a very simple spinlock that works both with [AArch64](https://developer.arm.com/architectures/learn-the-architecture/aarch64-instruction-set-architecture?_ga=2.17759802.282459154.1604342475-1664555334.1603995267)’s weak memory model and TME. Arm's recommended locking acquisition sequences using Load-Exclusive/Store-Exclusive typically rely on a load-acquire exclusive instruction (e.g. LDAXR) for correct memory ordering. When this form of lock acquisition is used in conjunction with TME lock elision, mutual exclusion cannot be guaranteed.. To circumvent this issue, two solutions are possible:
+
+1. To construct a locking acquisition sequence using Armv8.1 Large System Extensions (LSE) atomics. This is the idiomatic and performant Armv8-A and Armv9-A locking sequence which can be found in the Linux kernel.
+2. To add a full memory barrier (DMB SY) before the first memory operation of the critical section.
+
+Since LSE atomics aren't currently implemented in gem5/ruby we use the second option.
```cpp
#include <stdatomic.h>
@@ -82,8 +89,12 @@
}
inline void lock_acquire(lock_t *lock) {
- while (atomic_exchange_explicit(lock, 1, memory_order_acquire))
+ // The following atomic exchange can use relaxed memory
+ // ordering since it is followed by a full barrier.
+ while (atomic_exchange_explicit(lock, 1, memory_order_relaxed))
; // spin until acquired
+ // This will generate a full memory barrier, e.g. DMB SY
+ atomic_thread_fence(memory_order_seq_cst);
}
inline int lock_is_acquired(lock_t *lock) {
@@ -233,9 +244,11 @@
TME is supported in GCC as of [version 10](https://gcc.gnu.org/gcc-10/changes.html)—this includes [ACLE intrinsics](https://developer.arm.com/documentation/101028/0010/Transactional-Memory-Extension--TME--intrinsics?_ga=2.211085974.282459154.1604342475-1664555334.1603995267). To compile source files with TME instructions, an AArch64 compiler must be used with the feature enabled via the march flag, for example, `-march=armv8-a+tme`.
```
-aarch64-linux-gnu-gcc -std=c11 -O2 -static -march=armv8-a+tme -pthread -o histogram.exe ./histogram.c
+aarch64-linux-gnu-gcc -std=c11 -O2 -static -march=armv8-a+tme+nolse -pthread -o histogram.exe ./histogram.c
```
+As of this writing, gem5 implements Arm’s Large System Extension (LSE) in the Classic memory system but not Ruby. In order to easily use system emulation mode, this feature should be disabled in the source tree. To do this in gem5 v20.1, modify **./src/arch/arm/isa.cc:l106** and change `haveLSE` from `true` to `false`.
+
gem5 must then be compiled with the new Ruby `MESI_Three_Level_HTM` protocol.
```
diff --git a/_posts/2021-03-19-gem5-21-0.md b/_posts/2021-03-19-gem5-21-0.md
new file mode 100644
index 0000000..9cda411
--- /dev/null
+++ b/_posts/2021-03-19-gem5-21-0.md
@@ -0,0 +1,68 @@
+---
+layout: post
+title: "gem5-21.0 Released!"
+author: Jason Lowe-Power
+date: 2021-03-19
+categories: project
+---
+
+Version 21.0 marks *one full year* of gem5 releases, and on this anniversary, I think we have some of the biggest new features yet!
+This has been a very productive release with [100 issues](https://gem5.atlassian.net/), over 813 commits, and 49 unique contributors.
+
+## 21.0 New features
+
+### AMBA CHI protocol implemented in SLICC: Contributed by *Tiago Mück*
+
+This new protocol provides a single cache controller that can be reused at multiple levels of the cache hierarchy and configured to model multiple instances of MESI and MOESI cache coherency protocols.
+This implementation is based of Arm’s [AMBA 5 CHI specification](https://static.docs.arm.com/ihi0050/d/IHI0050D_amba_5_chi_architecture_spec.pdf) and provides a scalable framework for the design space exploration of large SoC designs.
+
+See [the gem5 documentation](http://www.gem5.org/documentation/general_docs/ruby/CHI/) for more details.
+There is also a [gem5 blog post](http://www.gem5.org/2020/05/29/flexible-cache.html) on this new protocol as well.
+
+### Full support for AMD's GCN3 GPU model
+
+In previous releases, this model was only partially supported.
+As of gem5 21.0, this model has been fully integrated and is tested nightly.
+This model currently only works in syscall emulation mode and requires using the gcn docker container to get the correct version of the ROCm stack.
+More information can be found in [this blog post](http://www.gem5.org/2020/05/27/modern-gpu-applications.html).
+
+With this full support, we are also providing many applications as well.
+See [gem5-resources](http://resources.gem5.org/) for more information.
+
+### RISC-V Full system Linux boot support: Contributed by *Peter Yuen*
+
+The RISC-V model in gem5 can now boot unmodified Linux!
+Additionally, we have implemented DTB generation and support the Berkeley Boot Loader as the stage 1 boot loader.
+We have also released a set of resources for you to get started: <https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/develop/src/riscv-fs/>
+
+### New/Changed APIs
+
+There are multiple places where the developers have reduced boilerplate.
+
+* **[API CHANGE]**: No more `create()` functions! Previously, every `SimObject` required a `<SimObjectParams>::create()` function to be manually defined. Forgetting to do this resulted in confusing errors. Now, this function is created for you automatically. You can still override it if you need to handle any special cases.
+* **[API CHANGE]**: `params()`: Rather than defining a typedef and the `params()` function for every `SimObject`, you can now use the `PARAMS` macro.
+
+See <http://doxygen.gem5.org/release/current/classSimObject.html#details> for more details on these two API changes.
+
+* **[API CHANGE]**: All stats are now using *new style* groups instead of the older manual stat interface.
+ * The previous API (creating stats that are not part of a `Group`) is still supported, but it is now deprecated.
+ * If a stat is not created with the new `Group` API, it may not be automatically dumped using new stat APIs (e.g., the Python API).
+ * Next release, there will be a warning for all old-style stats.
+
+### Platforms no longer support
+
+* **[USER-FACING CHANGE]**: Python 2.7 is *no longer supported*. You must use Python 3.6+.
+* CLANG minimum version is now 3.9
+* Bump minimum C++ to C++14
+
+### Other improvements and new features
+
+* Extra options to build m5ops
+* m5term improvements
+* There is a new python-based library for handling statistics. This library *works*, but hasn't been thoroughly tested yet. Stay tuned for more on this next release.
+* Many improvements and additions to unit tests
+* Cleaning up the `StaticInst` type
+* Workload API changes
+* Many updates and changes to the m5 guest utility
+* [Support for running arm64 Linux kernel v5.8](https://gem5.atlassian.net/browse/GEM5-787)
+* [Arm SCMI implemented](https://gem5.atlassian.net/browse/GEM5-768)
diff --git a/_posts/2021-04-25-gem5-21-1-roadmap.md b/_posts/2021-04-25-gem5-21-1-roadmap.md
new file mode 100644
index 0000000..e8eb824
--- /dev/null
+++ b/_posts/2021-04-25-gem5-21-1-roadmap.md
@@ -0,0 +1,92 @@
+---
+layout: post
+title: "gem5-21.1 Roadmap"
+author: Jason Lowe-Power
+date: 2021-04-25
+categories: project
+---
+
+Early on in each release, we like to provide the community with a roadmap of what is being developed for the next gem5 release.
+This is a community-based document, and it is a summary of what different developers are currently work on.
+If you have something that you're working on that you are planning to contribute before the gem5-21.1 release, we'd love to include it here!
+
+To contribute to the roadmap you can following the steps below:
+
+1. Create a issue or an epic on our [issue tracker](https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/). If the contribution is large with many different individual contributions, it would be best to create an epic to group all of the separate issues together.
+2. Mark the issue as "Fix version 21.1" and assign yourself as the "Assignee".
+3. Update [this roadmap document](https://gem5.googlesource.com/public/gem5-website/+/refs/heads/stable/_posts/2021-05-01-gem5-21-1-roadmap.md) by [downloading the website source](https://gem5.googlesource.com/public/gem5-website/) and creating a changeset [on gerrit](https://gem5.googlesource.com/public/gem5-website/+/refs/heads/stable/README.md).
+
+## Roadmap for 21.1
+
+We're planning to release gem5-21.1 **during July** (about 4 months after the gem5-21.0 release).
+Below are the main features we're currently planning on including in 21.1.
+
+### [gem5 component library](https://gem5.atlassian.net/browse/GEM5-648)
+
+Wouldn't it be cool if using gem5 was like walking into [Microcenter](https://www.microcenter.com/) and choosing components?
+The goal of this project is to make this happen!
+
+We will create a library of components and "known-good" configurations.
+With the *components*, you can choose components like different cache systems (e.g., private L1, shared L2), different CPUs, and different RAMs to plug into a "board" to create a system.
+
+Alternatively, you can choose to use one of our prebuilt systems as a baseline.
+These prebuilt systems will be benchmarked/tested and the data will be publically available on the gem5-resources webpage: <http://resources.gem5.org/>.
+
+For the components, the goal is that they are always composable.
+In other words, any memory can be connected to any cache system which can be connected to any CPU.
+And, hopefully, this will work for any ISA, etc.
+
+We're working on the details now and will have a proposal on gerrit in the next few weeks.
+If you have feedback feel free to let us know on gem5-dev mailing list, the [Jira issue](https://gem5.atlassian.net/browse/GEM5-648), or the gerrit changesets when they are posted.
+
+### [Continue improving python-based stats](https://gem5.atlassian.net/browse/GEM5-644)
+
+In [gem5-21.0]({% post_url 2021-3-19-gem5-21-0 %}), we implemented a python-based API for accessing stats.
+However, this was not enabled by default.
+In 21.1, we are expecting this API to be improved and more features added.
+Let us know what you would like to see from a new stats interface in the [Jira issue](https://gem5.atlassian.net/browse/GEM5-644) or on the mailing list!
+
+### [SST integration](https://gem5.atlassian.net/browse/GEM5-399)
+
+We have been working to revamp the gem5-SST integration for a couple of releases now.
+We started by [creating a documented stable API](https://gem5.atlassian.net/browse/GEM5-172), which still has a few unresolved issues.
+We expect that by 21.1 we will have a proof-of-concept where gem5 can be used as a component in SST.
+
+### [Upstreaming power-gem5](https://gem5.atlassian.net/browse/GEM5-959)
+
+POWER support in gem5 has languished over the years.
+However, there has been significant effort in a [fork of gem5](https://github.com/power-gem5/gem5/tree/develop-power) to update to the latest POWER features and improve the support.
+
+There are currently many changes on gerrit: E.g., <https://gem5-review.googlesource.com/c/public/gem5/+/40948> working to merge these two.
+We would appreciate reviews and feedback on these changes especially if POWER support is important to you!
+
+### GPU updates
+
+#### [Full system GPU](https://gem5.atlassian.net/browse/GEM5-195)
+
+Currently, gem5 also only supports GPU runs in SE mode, not FS mode.
+As part of the next release, we plan on releasing FS mode support for gem5 GPU models.
+
+#### [Supporting new runtimes and GPUs](https://gem5.atlassian.net/browse/GEM5-962)
+
+Currently gem5's SE mode GPU support is for ROCm 1.6 and Carrizo-class GPUs, which is fairly old now.
+To help address this, we are planning on releasing support for ROCm 4.0 in the next version of gem5.
+Moreover, we will also include support for Vega-class GPUs, which are more modern.
+
+### Other things we're working on
+
+Below are some other things that we have either started to work on or would like to do, but are either smaller or on the back burner.
+If anyone is interested in contributing, picking up one of these issues could be a great way!
+
+- [Improving the multi-level TLB models](https://gem5.atlassian.net/browse/GEM5-790)
+ - No current active development, but significant interest from many different users/developers
+- [Pydoc documentation](https://gem5.atlassian.net/browse/GEM5-647)
+- [RISC-V PMP support](https://gem5.atlassian.net/browse/GEM5-917)
+- [Upgrade the replacement policies API to support state-of-the-art replacement policies](https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-204)
+ - [The respective chain does the change and adds SHiP to exemplify](https://gem5-review.googlesource.com/c/public/gem5/+/38118/5)
+- [Enable GTesting of SimObjects (key part) and add as many unit tests as possible](https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-4)
+ - (Respective chain)[https://gem5-review.googlesource.com/c/public/gem5/+/44109/3]
+- If the key changes of the GTesting issue are merged, [revamp probes](https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-857)
+ - [Respective chain](https://gem5-review.googlesource.com/c/public/gem5/+/38706/1)
+- Finally, add a gem5 namespace. The change itself does not necessarily need to be over by the next version, but it would be great to have a decision and the very few first steps taken by then.
+ - See <https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-730>
