4f7b3ed827
There are several parts to this PR to work towards #1349 . (1) Make RubySystem::getBlockSizeBytes non-static by providing ways to access the block size or passing the block size explicitly to classes. The main changes are: - DataBlocks must be explicitly allocated. A default ctor still exists to avoid needing to heavily modify SLICC. The size can be set using a realloc function, operator=, or copy ctor. This is handled completely transparently meaning no protocol or config changes are required. - WriteMask now requires block size to be set. This is also handled transparently by modifying the SLICC parser to identify WriteMask types and call setBlockSize(). - AbstractCacheEntry and TBE classes now require block size to be set. This is handled transparently by modifying the SLICC parser to identify these classes and call initBlockSize() which calls setBlockSize() for any DataBlock or WriteMask. - All AbstractControllers now have a pointer to RubySystem. This is assigned in SLICC generated code and requires no changes to protocol or configs. - The Ruby Message class now requires block size in all constructors. This is added to the argument list automatically by the SLICC parser. (2) Relax dependence on common functions in src/mem/ruby/common/Address.hh so that RubySystem::getBlockSizeBits is no longer static. Many classes already have a way to get block size from the previous commit, so they simply multiple by 8 to get the number of bits. For handling SLICC and reducing the number of changes, define makeCacheLine, getOffset, etc. in RubyPort and AbstractController. The only protocol changes required are to change any "RubySystem::foo()" calls with "m_ruby_system->foo()". For classes which do not have a way to get access to block size but still used makeLineAddress, getOffset, etc., the block size must be passed to that class. This requires some changes to the SimObject interface for two commonly used classes: DirectoryMemory and RubyPrefecther, resulting in user-facing API changes User-facing API changes: - DirectoryMemory and RubyPrefetcher now require the cache line size as a non-optional argument. - RubySequencer SimObjects now require RubySystem as a non-optional argument. - TesterThread in the GPU ruby tester now requires the cache line size as a non-optional argument. (3) Removes static member variables in RubySystem which control randomization, cooldown, and warmup. These are mostly used by the Ruby Network. The network classes are modified to take these former static variables as parameters which are passed to the corresponding method (e.g., enqueue, delayHead, etc.) rather than needing a RubySystem object at all. Change-Id: Ia63c2ad5cf0bf9d1cbdffba5d3a679bb4d3b1220 (4) There are two major SLICC generated static methods: getNumControllers() on each cache controller which returns the number of controllers created by the configs at run time and the functions which access this method, which are MachineType_base_count and MachineType_base_number. These need to be removed to create multiple RubySystem objects otherwise NetDest, version value, and other objects are incorrect. To remove the static requirement, MachineType_base_count and MachineType_base_number are moved to RubySystem. Any class which needs to call these methods must now have a pointer to a RubySystem. To enable that, several changes are made: - RubyRequest and Message now require a RubySystem pointer in the constructor. The pointer is passed to fields in the Message class which require a RubySystem pointer (e.g., NetDest). SLICC is modified to do this automatically. - SLICC structures may now optionally take an "implicit constructor" which can be used to call a non-default constructor for locally defined variables (e.g., temporary variables within SLICC actions). A statement such as "NetDest bcast_dest;" in SLICC will implicitly append a call to the NetDest constructor taking RubySystem, for example. - RubySystem gets passed to Ruby network objects (Network, Topology).
The gem5 Simulator
This is the repository for the gem5 simulator. It contains the full source code for the simulator and all tests and regressions.
The gem5 simulator is a modular platform for computer-system architecture research, encompassing system-level architecture as well as processor microarchitecture. It is primarily used to evaluate new hardware designs, system software changes, and compile-time and run-time system optimizations.
The main website can be found at http://www.gem5.org.
Testing status
Note: These regard tests run on the develop branch of gem5: https://github.com/gem5/gem5/tree/develop.
Getting started
A good starting point is http://www.gem5.org/about, and for more information about building the simulator and getting started please see http://www.gem5.org/documentation and http://www.gem5.org/documentation/learning_gem5/introduction.
Building gem5
To build gem5, you will need the following software: g++ or clang, Python (gem5 links in the Python interpreter), SCons, zlib, m4, and lastly protobuf if you want trace capture and playback support. Please see http://www.gem5.org/documentation/general_docs/building for more details concerning the minimum versions of these tools.
Once you have all dependencies resolved, execute
scons build/ALL/gem5.opt to build an optimized version of the gem5 binary
(gem5.opt) containing all gem5 ISAs. If you only wish to compile gem5 to
include a single ISA, you can replace ALL with the name of the ISA. Valid
options include ARM, NULL, MIPS, POWER, RISCV, SPARC, and X86
The complete list of options can be found in the build_opts directory.
See https://www.gem5.org/documentation/general_docs/building for more information on building gem5.
The Source Tree
The main source tree includes these subdirectories:
- build_opts: pre-made default configurations for gem5
- build_tools: tools used internally by gem5's build process.
- configs: example simulation configuration scripts
- ext: less-common external packages needed to build gem5
- include: include files for use in other programs
- site_scons: modular components of the build system
- src: source code of the gem5 simulator. The C++ source, Python wrappers, and Python standard library are found in this directory.
- system: source for some optional system software for simulated systems
- tests: regression tests
- util: useful utility programs and files
gem5 Resources
To run full-system simulations, you may need compiled system firmware, kernel binaries and one or more disk images, depending on gem5's configuration and what type of workload you're trying to run. Many of these resources can be obtained from https://resources.gem5.org.
More information on gem5 Resources can be found at https://www.gem5.org/documentation/general_docs/gem5_resources/.
Getting Help, Reporting bugs, and Requesting Features
We provide a variety of channels for users and developers to get help, report bugs, requests features, or engage in community discussions. Below are a few of the most common we recommend using.
- GitHub Discussions: A GitHub Discussions page. This can be used to start discussions or ask questions. Available at https://github.com/orgs/gem5/discussions.
- GitHub Issues: A GitHub Issues page for reporting bugs or requesting features. Available at https://github.com/gem5/gem5/issues.
- Jira Issue Tracker: A Jira Issue Tracker for reporting bugs or requesting features. Available at https://gem5.atlassian.net/.
- Slack: A Slack server with a variety of channels for the gem5 community to engage in a variety of discussions. Please visit https://www.gem5.org/join-slack to join.
- gem5-users@gem5.org: A mailing list for users of gem5 to ask questions or start discussions. To join the mailing list please visit https://www.gem5.org/mailing_lists.
- gem5-dev@gem5.org: A mailing list for developers of gem5 to ask questions or start discussions. To join the mailing list please visit https://www.gem5.org/mailing_lists.
Contributing to gem5
We hope you enjoy using gem5. When appropriate we advise charing your contributions to the project. https://www.gem5.org/contributing can help you get started. Additional information can be found in the CONTRIBUTING.md file.