summaryrefslogtreecommitdiff
path: root/src/sim/SConscript
AgeCommit message (Collapse)Author
2014-10-16config: Add the ability to read a config file using C++ and PythonAndreas Hansson
This patch adds the ability to load in config.ini files generated from gem5 into another instance of gem5 built without Python configuration support. The intended use case is for configuring gem5 when it is a library embedded in another simulation system. A parallel config file reader is also provided purely in Python to demonstrate the approach taken and to provided similar functionality for as-yet-unknown use models. The Python configuration file reader can read both .ini and .json files. C++ configuration file reading: A command line option has been added for scons to enable C++ configuration file reading: --with-cxx-config There is an example in util/cxx_config that shows C++ configuration in action. util/cxx_config/README explains how to build the example. Configuration is achieved by the object CxxConfigManager. It handles reading object descriptions from a CxxConfigFileBase object which wraps a config file reader. The wrapper class CxxIniFile is provided which wraps an IniFile for reading .ini files. Reading .json files from C++ would be possible with a similar wrapper and a JSON parser. After reading object descriptions, CxxConfigManager creates SimObjectParam-derived objects from the classes in the (generated with this patch) directory build/ARCH/cxx_config CxxConfigManager can then build SimObjects from those SimObjectParams (in an order dictated by the SimObject-value parameters on other objects) and bind ports of the produced SimObjects. A minimal set of instantiate-replacing member functions are provided by CxxConfigManager and few of the member functions of SimObject (such as drain) are extended onto CxxConfigManager. Python configuration file reading (configs/example/read_config.py): A Python version of the reader is also supplied with a similar interface to CxxConfigFileBase (In Python: ConfigFile) to config file readers. The Python config file reading will handle both .ini and .json files. The object construction strategy is slightly different in Python from the C++ reader as you need to avoid objects prematurely becoming the children of other objects when setting parameters. Port binding also needs to be strictly in the same port-index order as the original instantiation.
2014-10-16config: Add a --without-python option to build processAndrew Bardsley
Add the ability to build libgem5 without embedded Python or the ability to configure with Python. This is a prelude to a patch to allow config.ini files to be loaded into libgem5 using only C++ which would make embedding gem5 within other simulation systems easier. This adds a few registration interfaces to things which cross between Python and C++. Namely: stats dumping and SimObject resolving
2014-08-10config: Add SubSystem container for simobjectsGeoffrey Blake
This patch adds the SubSystem container for grouping simobjects together in logical subsystems to facilitate building a larger system from constituent parts. The container is simply a non-abstract empty simobject to hold the components that will be connected as its children. In simulation the object does not participate, its only use is during configuration of the system.
2014-07-23cpu: `Minor' in-order CPU modelAndrew Bardsley
This patch contains a new CPU model named `Minor'. Minor models a four stage in-order execution pipeline (fetch lines, decompose into macroops, decompose macroops into microops, execute). The model was developed to support the ARM ISA but should be fixable to support all the remaining gem5 ISAs. It currently also works for Alpha, and regressions are included for ARM and Alpha (including Linux boot). Documentation for the model can be found in src/doc/inside-minor.doxygen and its internal operations can be visualised using the Minorview tool utils/minorview.py. Minor was designed to be fairly simple and not to engage in a lot of instruction annotation. As such, it currently has very few gathered stats and may lack other gem5 features. Minor is faster than the o3 model. Sample results: Benchmark | Stat host_seconds (s) ---------------+--------v--------v-------- (on ARM, opt) | simple | o3 | minor | timing | timing | timing ---------------+--------+--------+-------- 10.linux-boot | 169 | 1883 | 1075 10.mcf | 117 | 967 | 491 20.parser | 668 | 6315 | 3146 30.eon | 542 | 3413 | 2414 40.perlbmk | 2339 | 20905 | 11532 50.vortex | 122 | 1094 | 588 60.bzip2 | 2045 | 18061 | 9662 70.twolf | 207 | 2736 | 1036
2014-06-30power: Add basic DVFS support for gem5Stephan Diestelhorst
Adds DVFS capabilities to gem5, by allowing users to specify lists for frequencies and voltages in SrcClockDomains and VoltageDomains respectively. A separate component, DVFSHandler, provides a small interface to change operating points of the associated domains. Clock domains will be linked to voltage domains and thus allow separate clock, but shared voltage lines. Currently all the valid performance-level updates are performed with a fixed transition latency as specified for the domain. Config file example: ... vd = VoltageDomain(voltage = ['1V','0.95V','0.90V','0.85V']) tsys.cluster1.clk_domain.clock = ['1GHz','700MHz','400MHz','230MHz'] tsys.cluster2.clk_domain.clock = ['1GHz','700MHz','400MHz','230MHz'] tsys.cluster1.clk_domain.domain_id = 0 tsys.cluster2.clk_domain.domain_id = 1 tsys.cluster1.clk_domain.voltage_domain = vd tsys.cluster2.clk_domain.voltage_domain = vd tsys.dvfs_handler.domains = [tsys.cluster1.clk_domain, tsys.cluster2.clk_domain] tsys.dvfs_handler.enable = True
2013-11-25sim: simulate with multiple threads and event queuesSteve Reinhardt ext:(%2C%20Nilay%20Vaish%20%3Cnilay%40cs.wisc.edu%3E%2C%20Ali%20Saidi%20%3CAli.Saidi%40ARM.com%3E)
This patch adds support for simulating with multiple threads, each of which operates on an event queue. Each sim object specifies which eventq is would like to be on. A custom barrier implementation is being added using which eventqs synchronize. The patch was tested in two different configurations: 1. ruby_network_test.py: in this simulation L1 cache controllers receive requests from the cpu. The requests are replied to immediately without any communication taking place with any other level. 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server system which are connected by an ethernet link. We still lack the ability to communicate using message buffers or ports. But other things like simulation start and end, synchronizing after every quantum are working. Committed by: Nilay Vaish
2013-09-04arch: Resurrect the NOISA build target and rename it NULLAndreas Hansson
This patch makes it possible to once again build gem5 without any ISA. The main purpose is to enable work around the interconnect and memory system without having to build any CPU models or device models. The regress script is updated to include the NULL ISA target. Currently no regressions make use of it, but all the testers could (and perhaps should) transition to it. --HG-- rename : build_opts/NOISA => build_opts/NULL rename : src/arch/noisa/SConsopts => src/arch/null/SConsopts rename : src/arch/noisa/cpu_dummy.hh => src/arch/null/cpu_dummy.hh rename : src/cpu/intr_control.cc => src/cpu/intr_control_noisa.cc
2013-08-19power: Add voltage domains to the clock domainsAkash Bagdia
This patch adds the notion of voltage domains, and groups clock domains that operate under the same voltage (i.e. power supply) into domains. Each clock domain is required to be associated with a voltage domain, and the latter requires the voltage to be explicitly set. A voltage domain is an independently controllable voltage supply being provided to section of the design. Thus, if you wish to perform dynamic voltage scaling on a CPU, its clock domain should be associated with a separate voltage domain. The current implementation of the voltage domain does not take into consideration cases where there are derived voltage domains running at ratio of native voltage domains, as with the case where there can be on-chip buck/boost (charge pumps) voltage regulation logic. The regression and configuration scripts are updated with a generic voltage domain for the system, and one for the CPUs.
2013-06-27sim: Add the notion of clock domains to all ClockedObjectsAkash Bagdia
This patch adds the notion of source- and derived-clock domains to the ClockedObjects. As such, all clock information is moved to the clock domain, and the ClockedObjects are grouped into domains. The clock domains are either source domains, with a specific clock period, or derived domains that have a parent domain and a divider (potentially chained). For piece of logic that runs at a derived clock (a ratio of the clock its parent is running at) the necessary derived clock domain is created from its corresponding parent clock domain. For now, the derived clock domain only supports a divider, thus ensuring a lower speed compared to its parent. Multiplier functionality implies a PLL logic that has not been modelled yet (create a separate clock instead). The clock domains should be used as a mechanism to provide a controllable clock source that affects clock for every clocked object lying beneath it. The clock of the domain can (in a future patch) be controlled by a handler responsible for dynamic frequency scaling of the respective clock domains. All the config scripts have been retro-fitted with clock domains. For the System a default SrcClockDomain is created. For CPUs that run at a different speed than the system, there is a seperate clock domain created. This domain incorporates the CPU and the associated caches. As before, Ruby runs under its own clock domain. The clock period of all domains are pre-computed, such that no virtual functions or multiplications are needed when calling clockPeriod. Instead, the clock period is pre-computed when any changes occur. For this to be possible, each clock domain tracks its children.
2013-06-03sim: Add debug output when executing pseudo-instructionsAndreas Sandberg
2012-11-02sim: Move the draining interface into a separate base classAndreas Sandberg
This patch moves the draining interface from SimObject to a separate class that can be used by any object needing draining. However, objects not visible to the Python code (i.e., objects not deriving from SimObject) still depend on their parents informing them when to drain. This patch also gets rid of the CountedDrainEvent (which isn't really an event) and replaces it with a DrainManager.
2012-08-21Clock: Move the clock and related functions to ClockedObjectAndreas Hansson
This patch moves the clock of the CPU, bus, and numerous devices to the new class ClockedObject, that sits in between the SimObject and MemObject in the class hierarchy. Although there are currently a fair amount of MemObjects that do not make use of the clock, they potentially should do so, e.g. the caches should at some point have the same clock as the CPU, potentially with a 1:n ratio. This patch does not introduce any new clock objects or object hierarchies (clusters, clock domains etc), but is still a step in the direction of having a more structured approach clock domains. The most contentious part of this patch is the serialisation of clocks that some of the modules (but not all) did previously. This serialisation should not be needed as the clock is set through the parameters even when restoring from the checkpoint. In other words, the state is "stored" in the Python code that creates the modules. The nextCycle methods are also simplified and the clock phase parameter of the CPU is removed (this could be part of a clock object once they are introduced).
2012-08-15O3,ARM: fix some problems with drain/switchout functionality and add Drain ↵Anthony Gutierrez
DPRINTFs This patch fixes some problems with the drain/switchout functionality for the O3 cpu and for the ARM ISA and adds some useful debug print statements. This is an incremental fix as there are still a few bugs/mem leaks with the switchout code. Particularly when switching from an O3CPU to a TimingSimpleCPU. However, when switching from O3 to O3 cores with the ARM ISA I haven't encountered any more assertion failures; now the kernel will typically panic inside of simulation.
2011-11-02SE/FS: Get rid of FULL_SYSTEM in sim.Gabe Black
2011-10-30SE/FS: Compile in system events in SE mode.Gabe Black
2011-10-30SE/FS: Build syscall_emul.cc in FS mode.Gabe Black
2011-10-30SE/FS: Build the base process class in FS.Gabe Black
2011-06-02scons: rename TraceFlags to DebugFlagsNathan Binkert
2011-04-15scons: make a flexible system for guarding source filesNathan Binkert
This is similar to guards on mercurial queues and they're used for selecting which files are compiled into some given object. We already do something similar, but it's mostly hard coded for the m5 binary and the m5 library and I'd like to make it more flexible to better support the unittests
2011-02-06m5: added work completed monitoring supportBrad Beckmann
2011-01-19Time: Add a mechanism to prevent M5 from running faster than real time.Gabe Black
M5 skips over any simulated time where it doesn't have any work to do. When the simulation is active, the time skipped is short and the work done at any point in time is relatively substantial. If the time between events is long and/or the work to do at each event is small, it's possible for simulated time to pass faster than real time. When running a benchmark that can be good because it means the simulation will finish sooner in real time. When interacting with the real world through, for instance, a serial terminal or bridge to a real network, this can be a problem. Human or network response time could be greatly exagerated from the perspective of the simulation and make simulated events happen "too soon" from an external perspective. This change adds the capability to force the simulation to run no faster than real time. It does so by scheduling a periodic event that checks to see if its simulated period is shorter than its real period. If it is, it stalls the simulation until they're equal. This is called time syncing. A future change could add pseudo instructions which turn time syncing on and off from within the simulation. That would allow time syncing to be used for the interactive parts of a session but then turned off when running a benchmark using the m5 utility program inside a script. Time syncing would probably not happen anyway while running a benchmark because there would be plenty of work for M5 to do, but the event overhead could be avoided.
2010-11-19SCons: Support building without an ISAAli Saidi
2010-11-08ARM: Add checkpointing supportAli Saidi
2010-07-05sim: fold StartupCallback into SimObjectSteve Reinhardt
There used to be a reason to have StartupCallback be a separate object, but not any more. Now it's just confusing.
2009-05-04scons: re-work the *Source functions to take more information.Nathan Binkert
Start by turning all of the *Source functions into classes so we can do more calculations and more easily collect the data we need. Add parameters to the new classes for indicating what sorts of flags the objects should be compiled with so we can allow certain files to be compiled without Werror for example.
2009-01-19python: Rework how things are importedNathan Binkert
2008-12-17Make Alpha pseudo-insts available from SE mode.Steve Reinhardt
2008-10-10TLB: Make all tlbs derive from a common base class in both python and C++.Gabe Black
2008-08-03libm5: Create a libm5 static library for embedding m5.Nathan Binkert
This should allow m5 to be more easily embedded into other simulators. The m5 binary adds a simple main function which then calls into the m5 libarary to start the simulation. In order to make this work correctly, it was necessary embed python code directly into the library instead of the zipfile hack. This is because you can't just append the zipfile to the end of a library the way you can a binary. As a result, Python files that are part of the m5 simulator are now compile, marshalled, compressed, and then inserted into the library's data section with a certain symbol name. Additionally, a new Importer was needed to allow python to get at the embedded python code. Small additional changes include: - Get rid of the PYTHONHOME stuff since I don't think anyone ever used it, and it just confuses things. Easy enough to add back if I'm wrong. - Create a few new functions that are key to initializing and running the simulator: initSignals, initM5Python, m5Main. The original code for creating libm5 was inspired by a patch Michael Adler, though the code here was done by me.
2008-06-15add compile flags to m5Nathan Binkert
2007-10-31Traceflags: Add SCons function to created a traceflag instead of having one ↵Ali Saidi
file with them all. --HG-- extra : convert_revision : 427f6bd8f050861ace3bc0d354a1afa5fc8319e6
2007-08-27Address Translation: Make the Generic TLB only compile in SE mode.Gabe Black
--HG-- extra : convert_revision : 7eb9a78480174f754f51f75983ee5a1b31280bd3
2007-08-26Address Translation: Make SE mode use an actual TLB/MMU for translation like FS.Gabe Black
--HG-- extra : convert_revision : a04a30df0b6246e877a1cea35420dbac94b506b1
2007-08-01Arguments: Get rid of duplicate code for the Arguments class in each ↵Ali Saidi
architecture. Move the argument files to src/sim and add a utility.cc file with a function getArguments() that returns the given argument in the architecture specific fashion. getArguments() was getArg() is the architecture specific Argument class and has had all magic numbers replaced with meaningful constants. Also add a function to the Argument class for testing if an argument is NULL. --HG-- rename : src/arch/alpha/arguments.cc => src/sim/arguments.cc rename : src/arch/alpha/arguments.hh => src/sim/arguments.hh extra : convert_revision : 8b93667bafaa03b52aadb64d669adfe835266b8e
2007-07-28Turn the instruction tracing code into pluggable sim objects.Gabe Black
These need to be refined a little still and given parameters. --HG-- extra : convert_revision : 9a8f5a7bd9dacbebbbd2c235cd890c49a81040d7
2007-07-23Major changes to how SimObjects are created and initialized. Almost allNathan Binkert
creation and initialization now happens in python. Parameter objects are generated and initialized by python. The .ini file is now solely for debugging purposes and is not used in construction of the objects in any way. --HG-- extra : convert_revision : 7e722873e417cb3d696f2e34c35ff488b7bff4ed
2007-05-27Move SimObject python files alongside the C++ and fixNathan Binkert
the SConscript files so that only the objects that are actually available in a given build are compiled in. Remove a bunch of files that aren't used anymore. --HG-- rename : src/python/m5/objects/AlphaTLB.py => src/arch/alpha/AlphaTLB.py rename : src/python/m5/objects/SparcTLB.py => src/arch/sparc/SparcTLB.py rename : src/python/m5/objects/BaseCPU.py => src/cpu/BaseCPU.py rename : src/python/m5/objects/FuncUnit.py => src/cpu/FuncUnit.py rename : src/python/m5/objects/IntrControl.py => src/cpu/IntrControl.py rename : src/python/m5/objects/MemTest.py => src/cpu/memtest/MemTest.py rename : src/python/m5/objects/FUPool.py => src/cpu/o3/FUPool.py rename : src/python/m5/objects/FuncUnitConfig.py => src/cpu/o3/FuncUnitConfig.py rename : src/python/m5/objects/O3CPU.py => src/cpu/o3/O3CPU.py rename : src/python/m5/objects/OzoneCPU.py => src/cpu/ozone/OzoneCPU.py rename : src/python/m5/objects/SimpleOzoneCPU.py => src/cpu/ozone/SimpleOzoneCPU.py rename : src/python/m5/objects/BadDevice.py => src/dev/BadDevice.py rename : src/python/m5/objects/Device.py => src/dev/Device.py rename : src/python/m5/objects/DiskImage.py => src/dev/DiskImage.py rename : src/python/m5/objects/Ethernet.py => src/dev/Ethernet.py rename : src/python/m5/objects/Ide.py => src/dev/Ide.py rename : src/python/m5/objects/Pci.py => src/dev/Pci.py rename : src/python/m5/objects/Platform.py => src/dev/Platform.py rename : src/python/m5/objects/SimConsole.py => src/dev/SimConsole.py rename : src/python/m5/objects/SimpleDisk.py => src/dev/SimpleDisk.py rename : src/python/m5/objects/Uart.py => src/dev/Uart.py rename : src/python/m5/objects/AlphaConsole.py => src/dev/alpha/AlphaConsole.py rename : src/python/m5/objects/Tsunami.py => src/dev/alpha/Tsunami.py rename : src/python/m5/objects/T1000.py => src/dev/sparc/T1000.py rename : src/python/m5/objects/Bridge.py => src/mem/Bridge.py rename : src/python/m5/objects/Bus.py => src/mem/Bus.py rename : src/python/m5/objects/MemObject.py => src/mem/MemObject.py rename : src/python/m5/objects/PhysicalMemory.py => src/mem/PhysicalMemory.py rename : src/python/m5/objects/BaseCache.py => src/mem/cache/BaseCache.py rename : src/python/m5/objects/CoherenceProtocol.py => src/mem/cache/coherence/CoherenceProtocol.py rename : src/python/m5/objects/Repl.py => src/mem/cache/tags/Repl.py rename : src/python/m5/objects/Process.py => src/sim/Process.py rename : src/python/m5/objects/Root.py => src/sim/Root.py rename : src/python/m5/objects/System.py => src/sim/System.py extra : convert_revision : 173f8764bafa8ef899198438fa5573874e407321
2007-03-10Rework the way SCons recurses into subdirectories, making itNathan Binkert
automatic. The point is that now a subdirectory can be added to the build process just by creating a SConscript file in it. The process has two passes. On the first pass, all subdirs of the root of the tree are searched for SConsopts files. These files contain any command line options that ought to be added for a particular subdirectory. On the second pass, all subdirs of the src directory are searched for SConscript files. These files describe how to build any given subdirectory. I have added a Source() function. Any file (relative to the directory in which the SConscript resides) passed to that function is added to the build. Clean up everything to take advantage of Source(). function is added to the list of files to be built. --HG-- extra : convert_revision : 103f6b490d2eb224436688c89cdc015211c4fd30