fb29eaab1104683ffa7b222bf81e0e8abad226e2
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Jason Lowe-Power
|
97542c1a4c |
mem-ruby,scons: Add scons option for multiple protocols
This change does many things, but they must all be atomically done. **USER FACING CHANGE**: The Ruby protocols in Kconfig have changed names (they are now the same case as the SLICC file names). So, after this commit, your build configurations need to be updated. You can do so by running `scons menuconfig <build dir>` and selecting the right ruby options. Alternatively, if you're using a `build_opts` file, you can run `scons defconfig build/<ISA> build_opts/<ISA>` which should update your config correctly. Detailed changes are described below. Kconfig changes: - Kconfig files in ruby now must all be declared in the ruby/Kconfig file - All of the protocol names are changed to match their slicc file names including the case - A new option is available called "Use multiple protocols" which should be selected if multiple protocols are selected. This is only used to set the PROTOCOL variable to "MULTIPLE" when in multiple mode. - The PROTOCOL variable can now be "MULTIPLE" which means it will be ignored. If it's not "MULTIPLE" then it holds the "main" protocol, which is necessary for backwards compatibility with the Ruby.py files. Ruby config changes: To make this change backwards compatible with Ruby.py, this change adds a new "protocol" config called MULTIPLE.py which is used to allow the user to set a "--protocol" option on the command line. This is only needed if you are using a gem5 binary with multiple protocols but need to use Ruby.py. stdlib changes: - Make the coherence protocol file behave like the ISA file - Add a function to get the coherence protocol from the `CacheHierarchy` like we do with the ISA in the `Processor`. - Use this function where `get_runtime_coherence_protocol` was used - Update the requires code to work with the ne CoherenceProtocol - Fix a typo in the AMD Hammer name and also add the missing MSI protocol Scons changes: - In Ruby we now gather up all of the protocols and build them all if there are multiple protocols - There's some bending over backwards to tell the user if they are using an out of date gem5.build/config file and how to update it - Note that multiple ruby protocols adds a significant amount of time to the build since we have to run slicc twice for each file. build_opts: - Update all files with new names - Add a new NULL_All_Ruby that will be used for testing Signed-off-by: Jason Lowe-Power <jason@lowepower.com> |
||
|
Roger Chang
|
d758df4b5c |
scons: Update the Kconfig build options
The CL updates the Kconfig: 1. Replace the USE_NULL_ISA with BUILD_ISA 2. The USE_XXX_ISAs are depends on BUILD_ISA 3. If the BUILD_ISA is set, at least one of USE_XXX_ISAs must be set 4. Refactor the USE_KVM option Change-Id: I2a600dea9fb671263b0191c46c5790ebbe91a7b8 |
||
|
Gabe Black
|
db3a6e8e84 |
scons: Use Kconfig to configure gem5.
These are not yet consumed by anything, but convert all the settings from SCons variables to Kconfig variables. If you have existing SConsopts files which need to be converted, you should take a look at KCONFIG.md to learn about how kconfig is used in gem5. You should decide if any variables need to be available to C++ or kconfig itself, and whether those are options which should be detected automatically, or should be up to the user. Options which should be measured automatically should still be in SConsopts files, while user facing options should be added to new or existing Kconfig files. Generally, make sure you're storing c++/kconfig visible options in env['CONF'][...]. Also remove references to sticky_vars since persistent options should now be handled with kconfig, and export_vars since everything in env['CONF'] is now exported automatically. Switch SCons/gem5 to use Kconfig for configuration, except EXTRAS which is still a sticky SCons variable. This is necessary because EXTRAS also controls what config options exist. If it came from Kconfig itself, then there would be a circular dependency. This dependency could theoretically be handled by reparsing the Kconfig when EXTRAS directories were added or removed, but that would be complicated, and isn't supported by kconfiglib. It wouldn't be worth the significant effort it would take to add it, just to use Kconfig more purely. Change-Id: I29ab1940b2d7b0e6635a490452d05befe5b4a2c9 |
||
|
Gabe Black
|
073c32be2c |
misc: Replace TARGET_ISA with USE_${ISA} variables.
The TARGET_ISA variable would let you select one ISA from a list of possible ISAs. That has now been replaced with USE_ARM_ISA, USE_X86_ISA, etc, variables which are boolean on or off. That will allow any number of ISAs to be enabled or disabled individually. Enabling something other than exactly one of these will probably prevent you from getting a working gem5 binary, but those problems are being addressed in other, parallel change series. I decided to use the USE_ prefix since it was consistent with most other on/off variables we have in gem5. One noteable exception is the BUILD_GPU setting which, you could convincingly argue, is a better prefix than USE_. Another option would be to use CONFIG_, in anticipation of using a kconfig style config mechanism in gem5. It seemed premature to start using a CONFIG_ prefix here, and if we decide to switch to some other prefix like BUILD_, it should be a purposeful choice and not something somebody just starts using. Change-Id: I90fef2835aa4712782e6c1313fbf564d0ed45538 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52491 Tested-by: kokoro <noreply+kokoro@google.com> Maintainer: Gabe Black <gabe.black@gmail.com> Reviewed-by: Jason Lowe-Power <power.jg@gmail.com> Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> |
||
|
Gabe Black
|
c498d8bced |
cpu: Specialize CPUs for an ISA at the leaves, not BaseCPU.
The BaseCPU type had been specializing itself based on the value of TARGET_ISA, which is not compatible with building more than one ISA at a time. This change refactors the CPU models so that the BaseCPU is more general, and the ISA specific components are added to the CPU when the CPU types are fully specialized. For instance, The AtomicSimpleCPU has a version called X86AtomicSimpleCPU which installs the X86 specific aspects of the CPU. This specialization is done in three ways. 1. The mmu parameter is assigned an instance of the architecture specific MMU type. This provides a reasonable default, but also avoids having having to use the ISA specific type when the parameter is created. 2. The ISA specific types are made available as class attributes, and the utility functions (including __init__!) in the BaseCPU class can refer to them to get the types they need to set up the CPU at run time. Because SimObjects have strange, unhelpful semantics as far as assigning to their attributes, these types need to be set up in a non-SimObject class, which is then brought in as a base of the actual SimObject type. Because the metaclass of this other type is just "type", things work like you would expect. The SimObject doesn't do any special processing of base classes if they aren't also SimObjects, so these attributes survive and are accessible using normal lookup in the BaseCPU class. 3. There are some methods like addCheckerCPU and properties like needsTSO which have ISA specific values or behaviors. These are set in the ISA specific subclass, where they are inherently specific to an ISA and don't need to check TARGET_ISA. Also, the DummyChecker which was set up for the BaseSimpleCPU which doesn't actually do anything in either C++ or python was not carried forward. The CPU type still exists, but it isn't installed in the simple CPUs. To provide backward compatibility, each ISA implements a .py file which matches the original .py for a CPU, and the original is renamed with a Base prefix. The ISA specific version creates an alias with the old CPU name which maps to the ISA specific type. This way, old scripts which refer to, for example, AtomicSimpleCPU, will get the X86AtomicSimpleCPU if the x86 version was compiled in, the ArmAtomicSimpleCPU on arm, etc. Unfortunately, because of how tags on PySource and by extension SimObjects are implemented right now, if you set the tags on two SimObjects or PySources which have the same module path, the later will overwrite the former whether or not they both would be included. There are some changes in review which would revamp this and make it work like you would expect, without this central bookkeeping which has the conflict. Since I can't use that here, I fell back to checking TARGET_ISA to decide whether to tell SCons about those files at all. In the long term, this mechanism should be revamped so that these compatibility types are only available if there is exactly one ISA compiled into gem5. After the configs have been updated and no longer assume they can use AtomicSimpleCPU in all cases, then these types can be deleted. Also, because ISAs can now either provide subclasses for a CPU or not, the CPU_MODELS variable has been removed, meaning the non-ISA specialized versions of those CPU models will always be included in gem5, except when building the NULL ISA. In the future, a more granular config mechanism will hopefully be implemented for *all* of gem5 and not just the CPUs, and these can be conditional again in case you only need certain models, and want to reduce build time or binary size by excluding the others. Change-Id: I02fc3f645c551678ede46268bbea9f66c3f6c74b Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52490 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Gabe Black <gabe.black@gmail.com> Tested-by: kokoro <noreply+kokoro@google.com> |
||
|
John Alsop
|
f5cf6d5f5e |
mem-ruby: Enable set size increase
Add NUMBER_BITS_PER_SET environment variable to control the size of the bitmask in Set.hh (default=64). Necessary for configs which require >64 instances of a given machine type. This can be set in the build_opts file, e.g. by adding the following line: NUMBER_BITS_PER_SET = <number> Change-Id: I314a3cadca8ce975fcf4a60d9022494751688e88 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18968 Reviewed-by: Tiago Mück <tiago.muck@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Maintainer: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com> |
||
|
Nilay Vaish
|
bb6d7d402b |
ruby: rename MESI_CMP_directory to MESI_Two_Level
This is because the next patch introduces a three level hierarchy. --HG-- rename : build_opts/ALPHA_MESI_CMP_directory => build_opts/ALPHA_MESI_Two_Level rename : build_opts/X86_MESI_CMP_directory => build_opts/X86_MESI_Two_Level rename : configs/ruby/MESI_CMP_directory.py => configs/ruby/MESI_Two_Level.py rename : src/mem/protocol/MESI_CMP_directory-L1cache.sm => src/mem/protocol/MESI_Two_Level-L1cache.sm rename : src/mem/protocol/MESI_CMP_directory-L2cache.sm => src/mem/protocol/MESI_Two_Level-L2cache.sm rename : src/mem/protocol/MESI_CMP_directory-dir.sm => src/mem/protocol/MESI_Two_Level-dir.sm rename : src/mem/protocol/MESI_CMP_directory-dma.sm => src/mem/protocol/MESI_Two_Level-dma.sm rename : src/mem/protocol/MESI_CMP_directory-msg.sm => src/mem/protocol/MESI_Two_Level-msg.sm rename : src/mem/protocol/MESI_CMP_directory.slicc => src/mem/protocol/MESI_Two_Level.slicc rename : tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/config.ini => tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_Two_Level/config.ini rename : tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/ruby.stats => tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_Two_Level/ruby.stats rename : tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/simerr => tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_Two_Level/simerr rename : tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/simout => tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_Two_Level/simout rename : tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/stats.txt => tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_Two_Level/stats.txt rename : tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/system.pc.com_1.terminal => tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_Two_Level/system.pc.com_1.terminal rename : tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/config.ini => tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_Two_Level/config.ini rename : tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/ruby.stats => tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_Two_Level/ruby.stats rename : tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/simerr => tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_Two_Level/simerr rename : tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/simout => tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_Two_Level/simout rename : tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/stats.txt => tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_Two_Level/stats.txt rename : tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_CMP_directory/config.ini => tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_Two_Level/config.ini rename : tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_CMP_directory/ruby.stats => tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_Two_Level/ruby.stats rename : tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_CMP_directory/simerr => tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_Two_Level/simerr rename : tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_CMP_directory/simout => tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_Two_Level/simout rename : tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_CMP_directory/stats.txt => tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_Two_Level/stats.txt rename : tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/config.ini => tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_Two_Level/config.ini rename : tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/ruby.stats => tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_Two_Level/ruby.stats rename : tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/simerr => tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_Two_Level/simerr rename : tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/simout => tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_Two_Level/simout rename : tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/stats.txt => tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_Two_Level/stats.txt rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_CMP_directory/config.ini => tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_Two_Level/config.ini rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_CMP_directory/ruby.stats => tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_Two_Level/ruby.stats rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_CMP_directory/simerr => tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_Two_Level/simerr rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_CMP_directory/simout => tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_Two_Level/simout rename : tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_CMP_directory/stats.txt => tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_Two_Level/stats.txt |