layout: post title: “gem5-20.0 Released!” author: Jason Lowe-Power date: 2020-05-21 categories: project

After much waiting, and a few surprising issues, gem5-20.0 has been released! The master branch of the gem5 repo now points to the gem5-20 release instead of the gem5-19 release.

Thank you to everyone that made this release possible! This has been a very productive release with 84 issues, about 500 commits, and 30 unique contributors.

Below, I go over the major changes in gem5-20.0 since gem5-19, which can also be found in the file. This should cover all of the major changes and user-facing changes. The hope is that after reading the changelog, you can make updates to your local gem5 changes and then things will just work. I‘m sure this *isn’t* going to be that clean, but we can hope.


First, I want to look at a quick leaderboard of the most prolific contributors for this release. Going forward, I‘d like for these leaderboards to be living and automatically updated on the website. If you’re interested in helping out on this, let me know!


There was a total of 510 commits between the v19.0.0.0 tag and the v20.0.0.0 tag. gem5 v19.0.0.0 was tagged on February 20th, so this release was over 91 days or over 5.5 commits per day! This was quite a breakneck pace!

Having more commits doesn‘t necessarily mean that you’ve contributed more. However, being on this list of the top 10 committers does mean that you've put a significant amount of your time into gem5. For that, the community thanks you!

   235  Gabe Black
    66  Giacomo Travaglini
    46  Bobby R. Bruce
    24  Nils Asmussen
    21  Adrian Herrera
    21  Daniel Carvalho
    19  Nikos Nikoleris
    14  Matthew Poremba
    12  Timothy Hayes
     9  Ciro Santilli


Possibly more important than raw commits are the people who take time out of their days to review code. Here are the top 10 reviewers for this commit. Again, thank you for your work! The number of bugs that reviewers find is incredible, and without these people gem5's code quality would suffer.

While there were 510 commits, there were 642 reviews for an average of 1.25 reviews per change. The way we count reviews isn't perfect as it misses “re-reviews” and also skips “Maintainer” reviews. However, I would like to see this review ratio to be closer to 2 reviews per changeset in future releases.

    162 Jason Lowe-Power
    120 Bobby R. Bruce
     76 Nikos Nikoleris
     58 Gabe Black
     51 Daniel Carvalho
     49 Giacomo Travaglini
     44 Ciro Santilli
     13 Matthew Poremba
     10 Chun-Chen Hsu
      6 Ayaz Akram
      6 Andreas Sandberg

I want to call special attention to this list as there are a number of people who do more reviewing than writing code. This is incredibly helpful to the community, and we appreciate your contributions even if they aren't adding code!

Lessons learned

The gem5 community is committed to continually improving its processes based on best-practices and feedback from developers and users. In releasing gem5 20, our second official release of gem5, we have learned some lessons which which we shall take into account when developing future versions of gem5.

The gem5 project abides by a gitflow-inspired development setup where our “master” branch contains the latest release of gem5 at its HEAD, with a separate “develop” branch used for day-to-day gem5 development. Upon a release we create a staging branch from develop. This staging branch is then tested, and fixed if necessary, during which time development continues on the develop branch. Once all major tests are shown to pass, and no additional bugs can be found, the staging branch merged into both the master and develop branches, then subsequently deleted, thus completing the release. We have found, by and large, this policy works in our favor, though there is room for improvement.

For gem5 20, we had a policy of giving users exactly two weeks notice before creating the staging branch, with an additional two weeks given to test and fix errors on the staging branch. Our experience has revealed the two week notice prior to creating the staging was good at focusing the minds of developers, prompting prioritization of desired features for the release, and, overall, improving the churn of patchsets reviewed through our Gerrit code-review system. However, two weeks is, in hindsight, too short a notice for many, and resulted in a large Gerrit backlog from those wishing their features to be incorporated into gem5 20. In future releases, we are going to give a full month notice prior to creating the staging branch. Furthermore, we created the staging branch on a Friday, with the goal of merging the staging branch into the master and develop branches exactly two weeks later (another Friday). We found this led to long weeks of hectic changes, fatigue, and bad moral. Friday releases also have the daunting prospect of work leaking into the weekend, or complaints that aren‘t resolved until the following Monday. Going forward, **we’re going to commit to mid-week releases**.

We have also came to realize that our policy of the staging branch existing for two weeks is needlessly restrictive. Given only testing, bug fixes, and critical last-minute changes are permitted to be incorporated into the branch, we see no reason as to why the staging branch should not exist until its stability and reliability is sufficiently proven. In future releases, the gem5 staging branch shall exist for as long as it takes for tests to run, and bugs exposed by these tests to be fixed. As development can continue on the develop branch, this longer-lived staging branch shall not interfere with other gem5 activities.

In testing on our staging branch, we found some bugs exposed by tests we run irregularly. In particular, and to our surprise, a simple check of building different gem5 ISAs with the set of compilers we officially support revealed many compilation errors. We will therefore aim to regularly test the supported compilers during the development of gem5. We will also continue to improve our testing procedures to run more tests more often, in particular by starting regular nightly builds where larger tests and build processes may be run. Finding bugs earlier, as they appear in our development process, will save us a lot of work compared to finding and fixing bugs later in the staging branch.

Finally, gem5 20 officially supports Python3, as well as being backwards compatible with Python2. We have learned that supporting both Python3 and Python2 is a laborious task, more so than we had anticipated. Significant resources have been deployed to ensure gem5 20 functions with Python3 while still functioning for those who continue to use, the now retired, Python2. This level of support, however, cannot be maintained indefinitely. We are therefore keen to accelerate our dropping of Python2 support in future releases of gem5.

We welcome any other feedback on how to improve this process. Please feel free to let us know on the mailing list or by opening an issue.


New features

  • gem5-resources repository
    • This new repository will store all of the sources (e.g., code) used to create testing and research resources. This includes disk images, testing binaries, kernel binaries, etc.
    • Binaries created with the sources are hosted on
    • Details on the new page for resources:
  • Memory SimObjects can now be initialized using an image file using the image_file parameter.
  • [USER-FACING CHANGE] The m5 utility has been revamped with a new build system based on scons, tests, and updated and more consistent feature support.
    • To build, now use scons build/<arch>/out/m5, not make.
    • Documentation coming soon.
  • Robust support for marshalling data from a function call inside the simulation to a function within gem5 using a predefined set of rules.
    • Developers can specify an ABI for guest<->simulator calls and then “just call functions”.
    • Unifies pseudo-inst, syscall, and other support.
    • Code within gem5 has been updated. However, users which added new pseudo-ops may have to update their code.
  • [PYTHON API CHANGE] Workload configuration pulled out into its own object, simplifying the System object and making workload configuration more modular and flexible.
  • Sv39 paging has been added to the RISC-V ISA, bringing gem5 close to running Linux on RISC-V.
    • (Some) Baremetal OSes are now supported.
  • Improvements to DRAM model:
    • Added support for verifying available command bandwidth.
    • Added support for multi-cycle commands.
    • Added new timing parameters.
    • Added ability to interleave bursts.
    • Added LPDDR5 configurations.

Removed features

  • Support for the ALPHA ISA has been dropped.
    • All ALPHA ISA code has been removed
    • Old “rcS” scripts for ALPHA have been removed

New supported platforms

  • Compiling and running gem5 with Python 3 is now fully supported.
    • Lots of code changes required for this.
    • There may still be some python code that‘s not up to date. Please open a Jira ticket if you find any code that doesn’t work with python3.
  • gem5 now supports Ubuntu 20.04.
  • Compiling gem5 with GCC 8 and 9 is now supported.
  • Compiling with clang up to version 9 is now supported.

Testing improvements

  • Scons-based tests have been migrated to the testlib framework.
    • Tests can now be run with tests/, except for the unittests.
    • Please consult for more information on how these may be run.
  • We are continuing to work on CI tests. Most of the plumbing is there for Google Cloud Build integration. See the Jira issue for details.

Other API changes

  • [API CHANGE] Ruby's prefetcher renamed to RubyPrefetcher.
    • Any SLICC protocols with prefetchers need to be updated.
    • Some config scripts for Ruby protocols with prefetchers may need to be updated.
  • [API CHANGE] SE mode improvements.
    • Better support for the mmap and related syscalls.
    • A new virtual memory area API for tracking SE mode allocations.
    • When implementing syscalls, the way that guest memory is allocated changes. All code in gem5 is updated, but if there are any external syscalls, they may need be updated.
  • [COMMAND LINE CHANGE] The --disk-image argument to is now optional.
    • However, the disk image names are no longer implied.
    • The script still implicitly searches M5_PATH, but the name of the disk image must be specified.
  • [API CHANGE] SLICC queueMemory is now enqueue.
    • All protocol configs must be updated with another message buffer in the memory controllers (directories).
    • All protocol SLICC files must replace queueMemoryRead and queueMemoryWrite with enqueue to another “special” message buffer named memQueue.
    • This allows finite buffering between the cache controllers and DRAMCtrl.
  • [API CHANGE] Added Prefetcher namespace
    • All prefetchers' names have changed from *Prefetcher to Prefetcher::*
    • If you have any prefetchers that are not in the gem5 mainline, your code will likely need to be updated.

Other changes

  • Implemented ARMv8.3-CompNum, SIMD complex number extension.
  • Support for Arm Trusted Firmware + u-boot with the new VExpress_GEM5_Foundation platform
  • Removed author list from source files.
    • This was originally so future people would know who to contact.
    • However, it was difficult to maintain and quickly out of date.
    • Copyright is unchanged.
  • Improvements to gem5's power model.
  • MESI_Three_Level Ruby protocol bugfixes.
  • Ruby functional reads now work in more cases.
  • GCN3 ISA added.
  • Indirect branch stats work correctly now.