gem5-20.1 路线图
在我们成功发布 gem5-20 之后，是时候开始考虑 gem5 的下一个发布 gem5-20.1 了！
我们在与 gem5 研讨会一起举行的 gem5 市政厅期间收到了关于社区希望在下一次发布中看到的新功能的良好反馈。
基于此反馈，以下是我们计划为 gem5-20.1 发布完成的主要项目，并附有 Jira 问题的链接。 我们欢迎对此路线图的任何反馈！ 请使用 gem5-dev 邮件列表告诉我们您的想法！
如果您想建议其他要包含在 gem5-20.1 中的功能/修复，请在 Jira 上将它们标记为”修复版本” “gem5 20.1”。 您可以在此 Jira 页面上找到我们计划在 20.1 发布之前完成的所有当前问题（注意：您可能需要登录才能看到发布页面）。
我们计划在 8 月底发布 gem5-20.1。 我们预计在 8 月 24 日创建 staging 分支并关闭合并窗口，给每个人超过 6 周的时间来完成这些重大更改！
继续定义 gem5 的 API
在 gem5-20 中，我们开始为 gem5 定义内部 API。
您可以在 Doxygen 文档中看到我们所做的工作。
在 gem5-20 中，我们的目标是适度的。
我们只添加了 SimObject 和 SimObject 依赖的类的信息。
具体来说，我们为 SimObject、Drain、Serialize、EventQueue 和 Statistics 制定了 API。
为了将这些添加到 API，我们已使用 Doxygen 组标记了作为 API 一部分的方法。 目前，我们将依靠代码审查来捕获对 API 的任何更改。 我们将努力保持 API 不变，但为了改进模拟器，API 必须更改。 但是，API 只会在”主要”发布时更改，我们将在发布说明中添加详细信息，说明如果您的代码使用了更改的 API，如何更新您的代码。
对于 gem5-20.1，我们将进一步扩展 API 定义涵盖的方法。 我们将专注于以下内容：
- 为当前 API 添加更多文档，包括统计、drain、序列化、事件队列和
SimObject。 - 定义事件队列的”外部” API。这些对于希望通过自己驱动事件队列或让 gem5 的事件队列驱动外部模拟器来连接到 gem5 的其他模拟器很有用。
- 端口接口。端口是 gem5 中使用最广泛的对象之一。它们促进所有内存系统对象之间的通信。这个接口在过去几年中有所变化，文档没有跟上。我们将确保这个接口得到很好的文档记录。
- “Base” 实用类。
base/目录中有许多在整个代码库中使用的类。我们将这些添加为 API，以确保这些广泛使用的接口不会在没有文档的情况下更改。
我们还在考虑记录模拟器输入和输出的最佳方法。
具体来说，我们认为输出文件（例如，stats.txt、config.ini、检查点等）应该在发布之间保持稳定。
但是，Doxygen 可能不是记录这些接口的正确方法。
我们很想听听您关于如何最好地记录和执行这些接口的想法。
请参见此 Jira Epic 以跟踪此问题的当前进度。
改进统计
我们在 gem5 用户市政厅收到的最常见反馈是统计难以使用且不够灵活。 为此，我们将在 gem5-20.1 中努力改进统计。
我们的第一步将是将所有 SimObject 的统计转换为 “新样式”统计。 大约一年前，我们添加了对分层统计的支持。 此更改显著提高了统计包的可用性。 但是，我们决定保持向后兼容性，当时我们没有更新所有 SimObject 以使用此新 API。 对于 gem5-20.1，我们将迁移所有 SimObject 以使用新样式，并且我们将正式弃用旧 API。
我们收到的关于统计的其他主要反馈是当前输出不容易被机器读取。 为此，我们将添加更易于机器读取的新输出格式。 我们目前考虑的主要格式是 csv、与 pandas 数据框兼容的内容，以及用于流式时间序列统计的 protobuf。
除了上面链接的新 Jira 问题外，还有一些正在进行的工作，涉及当前在 gerrit 上的变更集（或最近合并的）。
改进 Python 接口
Python<->C++ 接口是 gem5 的最佳功能之一。
但是，这些代码中的大部分是在 10 多年前编写的，并且已经对此代码进行了许多添加。
“默认”配置文件 se.py 和 fs.py 尤其如此，它们已经增长到数千行代码（包括导入的文件时）。
对于 gem5-20.1，我们将开始重构一些 Python 代码以改进设计、添加更多文档并使事情更容易使用。
目前，这将是一个新的库（gem5 而不是 m5），以为当前使用的所有配置提供向后兼容性。
我们还将开发一个”单元测试”接口用于测试 python 级别的 SimObject。 这不会完全是单元测试，但将允许 SimObject 设计者测试他们的对象，而不必运行整个 gem5 模拟。 目前这需要构建所有 gem5，但我们会考虑未来不需要这样做的情况。
我们将使用 pydoc 文档记录 Python API。 这将使我们能够更清楚地定义此 API。 我们还将开始包含 Python 类型注释。 但是，由于类型注释需要 Python 3.5+，我们最初只会在文档字符串中记录这一点，并在稍后将其移入主代码。
最后，我们将开始开发一个纯 Python 模型库。
此模型库将允许用户编写更简单的 Python 脚本来配置模拟器。
最终，此库将取代 se.py 和 fs.py。
此外，它将成为 gem5 的”已知良好配置”的基础，这些配置将基于真实硬件的公开验证模型。
测试
我们有很多方法希望改进 gem5-20 发布的测试。 最高优先级之一是用自托管的 CI 解决方案替换 kokoro。 Google 托管的 kokoro 流程在捕获错误方面非常有用。 但是，对于 Google 外部的人来说配置很困难，并且目前它使用带有 GCC 4.8 的旧 VM/docker 容器。 迁移到自托管解决方案将为我们提供更多的灵活性和控制。 它还将帮助我们完成其他一些测试目标。
另一个目标是启动并运行夜间构建。 我们标记了”快速”和”长时间”回归，但目前我们不运行大多数”长时间”回归（它们需要 16-24 小时）。 我们计划每晚运行这些，但这在 kokoro 系统中是不可能的。 我们还将研究添加其他类型的测试，例如测试以确保 gem5 构建我们支持的所有编译器，以及运行地址清理器和其他静态分析工具。
为了实现这些目标，我们认为最好的前进方式是使用我们自己的自托管 Jenkins 实例。 目前，我们将在 Google 的云基础设施上运行此实例。 However, one of the benefits of Jenkins is that we can easily move it to any public cloud or local compute resources.
We’ll also be working on fixing some failing integration tests, fixing some of the failing Linux boot tests, and continue to work on increasing our unittest coverage.
Full system GPU support
As discussed in the gem5 users workshop, developers at AMD are working to make it possible to use the GPU model in full system mode in gem5. The goal is to be able to use the GPU model with the upstream driver and runtimes. Currently, the SE mode-based GPU model is tied to an old version of the RoCM stack, and by implementing this full system support we’ll be able to support newer runtime versions.
The current status of this support can be found on this Jira Epic. There’s a lot of little things to get done here, but the developers are hard at work on them!
Memory system improvements
There are a number of improvements to gem5’s memory system that we are targeting for gem5-20.1 including an NVM model, support for transactional memory, and a new Ruby protocol that supports a flexible cache hierarchy.
NVM Model
Wendy Elsasser and other developers at Arm have been working on an improved memory controller that has both DRAM and non-volatile memory attached. More details on this development can be found in her gem5 workshop presentation.
There are a set of patches on gerrit right now for this new support. We fully expect these to be integrated into gem5 before the gem5-20.1 release.
You can follow the development on this Jira issue.
HTM Model
Hardware transactional memory has moved from research to products with Intel and ARM supporting some form of transactional memory in their ISAs.
There is current work to support HTM in both the ISA models and Ruby. We expect that these changesets on gerrit will be merged before the release of gem5-20.1.
You can follow the progress on the Ruby Jira issue and the ARM TME Jira issue.
Heterogarnet (Garnet 3.0)
As described in the gem5 workshop talk there has been work to extend Garnet to support 3D integration and other heterogeneous systems. We will be working to merge this support into the gem5-20.1 release.
A discussion on ISA support
gem5 supports a large number of ISAs. This is one of gem5’s best features, but the support for each ISA isn’t uniform. Each ISA has varying completeness, support for the latest revisions, fidelity, system architecture support, and testing.
We are going to solicit feedback on how to proceed with our ISA support during the gem5 20.1 development cycle.
This issue is about having a conversation about removing support for some ISAs. Whether or not we remove these ISAs is up to the community at large.