sanchayanmaity/gem5
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
gem5/tests/configs/pc-simple-timing-ruby.py

93 lines
4 KiB
Python
Raw Permalink Normal View History

Regression: Add a test for x86 timing full system ruby simulation
2012-04-26 05:43:36 +02:00
# Copyright (c) 2012 Mark D. Hill and David A. Wood
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met: redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer;
# redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution;
# neither the name of the copyright holders nor the names of its
# contributors may be used to endorse or promote products derived from
# this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# Authors: Nilay Vaish
import m5, os, optparse, sys
from m5.objects import *
ruby: Fix regressions and make Ruby configs Python packages This patch moves the addition of network options into the Ruby module to avoid the regressions all having to add it explicitly. Doing this exposes an issue in our current config system though, namely the fact that addtoPath is relative to the Python script being executed. Since both example and regression scripts use the Ruby module we would end up with two different (relative) paths being added. Instead we take a first step at turning the config modules into Python packages, simply by adding a __init__.py in the configs/ruby, configs/topologies and configs/network subdirectories. As a result, we can now add the top-level configs directory to the Python search path, and then use the package names in the various modules. The example scripts are also updated, and the messy path-deducing variations in the scripts are unified.
2016-10-13 09:17:19 +02:00
m5.util.addToPath('../configs/')
config: Make configs/common a Python package Continue along the same line as the recent patch that made the Ruby-related config scripts Python packages and make also the configs/common directory a package. All affected config scripts are updated (hopefully). Note that this change makes it apparent that the current organisation and naming of the config directory and its subdirectories is rather chaotic. We mix scripts that are directly invoked with scripts that merely contain convenience functions. While it is not addressed in this patch we should follow up with a re-organisation of the config structure, and renaming of some of the packages.
2016-10-14 16:37:38 +02:00
from common.Benchmarks import SysConfig
from common import FSConfig
ruby: Fix regressions and make Ruby configs Python packages This patch moves the addition of network options into the Ruby module to avoid the regressions all having to add it explicitly. Doing this exposes an issue in our current config system though, namely the fact that addtoPath is relative to the Python script being executed. Since both example and regression scripts use the Ruby module we would end up with two different (relative) paths being added. Instead we take a first step at turning the config modules into Python packages, simply by adding a __init__.py in the configs/ruby, configs/topologies and configs/network subdirectories. As a result, we can now add the top-level configs directory to the Python search path, and then use the package names in the various modules. The example scripts are also updated, and the messy path-deducing variations in the scripts are unified.
2016-10-13 09:17:19 +02:00
from ruby import Ruby
config: Make configs/common a Python package Continue along the same line as the recent patch that made the Ruby-related config scripts Python packages and make also the configs/common directory a package. All affected config scripts are updated (hopefully). Note that this change makes it apparent that the current organisation and naming of the config directory and its subdirectories is rather chaotic. We mix scripts that are directly invoked with scripts that merely contain convenience functions. While it is not addressed in this patch we should follow up with a re-organisation of the config structure, and renaming of some of the packages.
2016-10-14 16:37:38 +02:00
from common import Options
Regression: Add a test for x86 timing full system ruby simulation
2012-04-26 05:43:36 +02:00
# Add the ruby specific and protocol specific options
parser = optparse.OptionParser()
Options.addCommonOptions(parser)
Ruby.define_options(parser)
(options, args) = parser.parse_args()
# Set the default cache size and associativity to be very small to encourage
# races between requests and writebacks.
options.l1d_size="32kB"
options.l1i_size="32kB"
options.l2_size="4MB"
options.l1d_assoc=2
options.l1i_assoc=2
options.l2_assoc=2
options.num_cpus = 2
#the system
mdesc = SysConfig(disk = 'linux-x86.img')
config: Move the memory instantiation outside FSConfig This patch moves the instantiation of the memory controller outside FSConfig and instead relies on the mem_ranges to pass the information to the caller (e.g. fs.py or one of the regression scripts). The main motivation for this change is to expose the structural composition of the memory system and allow more tuning and configuration without adding a large number of options to the makeSystem functions. The patch updates the relevant example scripts to maintain the current functionality. As the order that ports are connected to the memory bus changes (in certain regresisons), some bus stats are shuffled around. For example, what used to be layer 0 is now layer 1. Going forward, options will be added to support the addition of multi-channel memory controllers.
2013-08-19 09:52:27 +02:00
system = FSConfig.makeLinuxX86System('timing', options.num_cpus,
regressions: update a couple of configs The configs for pc-simple-timing-ruby, t1000-simple-atomic had not been updated correctly in the patch 6e6cefc1db1f.
2013-07-02 17:10:58 +02:00
mdesc=mdesc, Ruby=True)
power: Add voltage domains to the clock domains 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-08-19 09:52:28 +02:00
# Dummy voltage domain for all our clock domains
system.voltage_domain = VoltageDomain(voltage = options.sys_voltage)
sim: Add the notion of clock domains to all ClockedObjects 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-27 11:49:49 +02:00
Regression: Add a test for x86 timing full system ruby simulation
2012-04-26 05:43:36 +02:00
system.kernel = FSConfig.binary('x86_64-vmlinux-2.6.22.9.smp')
power: Add voltage domains to the clock domains 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-08-19 09:52:28 +02:00
system.clk_domain = SrcClockDomain(clock = '1GHz',
voltage_domain = system.voltage_domain)
system.cpu_clk_domain = SrcClockDomain(clock = '2GHz',
voltage_domain = system.voltage_domain)
regressions: update a couple of configs The configs for pc-simple-timing-ruby, t1000-simple-atomic had not been updated correctly in the patch 6e6cefc1db1f.
2013-07-02 17:10:58 +02:00
system.cpu = [TimingSimpleCPU(cpu_id=i, clk_domain = system.cpu_clk_domain)
for i in xrange(options.num_cpus)]
sim: Add the notion of clock domains to all ClockedObjects 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-27 11:49:49 +02:00
ruby: single physical memory in fs mode Both ruby and the system used to maintain memory copies. With the changes carried for programmed io accesses, only one single memory is required for fs simulations. This patch sets the copy of memory that used to reside with the system to null, so that no space is allocated, but address checks can still be carried out. All the memory accesses now source and sink values to the memory maintained by ruby.
2014-11-06 12:41:44 +01:00
Ruby.create_system(options, True, system, system.iobus, system._dma_ports)
Regression: Add a test for x86 timing full system ruby simulation
2012-04-26 05:43:36 +02:00
sim: Add the notion of clock domains to all ClockedObjects 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-27 11:49:49 +02:00
# Create a seperate clock domain for Ruby
power: Add voltage domains to the clock domains 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-08-19 09:52:28 +02:00
system.ruby.clk_domain = SrcClockDomain(clock = options.ruby_clock,
voltage_domain = system.voltage_domain)
sim: Add the notion of clock domains to all ClockedObjects 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-27 11:49:49 +02:00
ruby: single physical memory in fs mode Both ruby and the system used to maintain memory copies. With the changes carried for programmed io accesses, only one single memory is required for fs simulations. This patch sets the copy of memory that used to reside with the system to null, so that no space is allocated, but address checks can still be carried out. All the memory accesses now source and sink values to the memory maintained by ruby.
2014-11-06 12:41:44 +01:00
# Connect the ruby io port to the PIO bus,
# assuming that there is just one such port.
system.iobus.master = system.ruby._io_port.slave
Regression: Add a test for x86 timing full system ruby simulation
2012-04-26 05:43:36 +02:00
for (i, cpu) in enumerate(system.cpu):
# create the interrupt controller
cpu.createInterruptController()
# Tie the cpu ports to the correct ruby system ports
config: ruby: rename _cpu_ruby_ports to _cpu_ports
2014-03-20 15:14:14 +01:00
cpu.icache_port = system.ruby._cpu_ports[i].slave
cpu.dcache_port = system.ruby._cpu_ports[i].slave
cpu.itb.walker.port = system.ruby._cpu_ports[i].slave
cpu.dtb.walker.port = system.ruby._cpu_ports[i].slave
ruby: single physical memory in fs mode Both ruby and the system used to maintain memory copies. With the changes carried for programmed io accesses, only one single memory is required for fs simulations. This patch sets the copy of memory that used to reside with the system to null, so that no space is allocated, but address checks can still be carried out. All the memory accesses now source and sink values to the memory maintained by ruby.
2014-11-06 12:41:44 +01:00
isa,cpu: Add support for FS SMT Interrupts Adds per-thread interrupt controllers and thread/context logic so that interrupts properly get routed in SMT systems.
2015-09-30 18:14:19 +02:00
cpu.interrupts[0].pio = system.ruby._cpu_ports[i].master
cpu.interrupts[0].int_master = system.ruby._cpu_ports[i].slave
cpu.interrupts[0].int_slave = system.ruby._cpu_ports[i].master
Regression: Add a test for x86 timing full system ruby simulation
2012-04-26 05:43:36 +02:00
root = Root(full_system = True, system = system)
m5.ticks.setGlobalFrequency('1THz')
Reference in a new issue Copy permalink