sanchayanmaity/gem5
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
gem5/configs/ruby/MI_example.py

194 lines
8.4 KiB
Python
Raw Normal View History

ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
# Copyright (c) 2006-2007 The Regents of The University of Michigan
# Copyright (c) 2009 Advanced Micro Devices, Inc.
# 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: Brad Beckmann
Config: Import math in MI_example.py
2011-03-28 17:49:36 +02:00
import math
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
import m5
from m5.objects import *
from m5.defines import buildEnv
ruby: changes how Topologies are created Instead of just passing a list of controllers to the makeTopology function in src/mem/ruby/network/topologies/<Topo>.py we pass in a function pointer which knows how to make the topology, possibly with some extra state set in the configs/ruby/<protocol>.py file. Thus, we can move all of the files from network/topologies to configs/topologies. A new class BaseTopology is added which all topologies in configs/topologies must inheirit from and follow its API. --HG-- rename : src/mem/ruby/network/topologies/Crossbar.py => configs/topologies/Crossbar.py rename : src/mem/ruby/network/topologies/Mesh.py => configs/topologies/Mesh.py rename : src/mem/ruby/network/topologies/MeshDirCorners.py => configs/topologies/MeshDirCorners.py rename : src/mem/ruby/network/topologies/Pt2Pt.py => configs/topologies/Pt2Pt.py rename : src/mem/ruby/network/topologies/Torus.py => configs/topologies/Torus.py
2012-07-11 07:51:53 +02:00
from Ruby import create_topology
x86 isa: This patch attempts an implementation at mwait. Mwait works as follows: 1. A cpu monitors an address of interest (monitor instruction) 2. A cpu calls mwait - this loads the cache line into that cpu's cache. 3. The cpu goes to sleep. 4. When another processor requests write permission for the line, it is evicted from the sleeping cpu's cache. This eviction is forwarded to the sleeping cpu, which then wakes up. Committed by: Nilay Vaish <nilay@cs.wisc.edu>
2014-11-06 12:42:22 +01:00
from Ruby import send_evicts
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
#
ruby: Remove the RubyCache/CacheMemory latency The RubyCache (CacheMemory) latency parameter is only used for top-level caches instantiated for Ruby coherence protocols. However, the top-level cache hit latency is assessed by the Sequencer as accesses flow through to the cache hierarchy. Further, protocol state machines should be enforcing these cache hit latencies, but RubyCaches do not expose their latency to any existng state machines through the SLICC/C++ interface. Thus, the RubyCache latency parameter is superfluous for all caches. This is confusing for users. As a step toward pushing L0/L1 cache hit latency into the top-level cache controllers, move their latencies out of the RubyCache declarations and over to their Sequencers. Eventually, these Sequencer parameters should be exposed as parameters to the top-level cache controllers, which should assess the latency. NOTE: Assessing these latencies in the cache controllers will require modifying each to eliminate instantaneous Ruby hit callbacks in transitions that finish accesses, which is likely a large undertaking.
2015-08-14 07:19:37 +02:00
# Declare caches used by the protocol
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
#
ruby: Remove the RubyCache/CacheMemory latency The RubyCache (CacheMemory) latency parameter is only used for top-level caches instantiated for Ruby coherence protocols. However, the top-level cache hit latency is assessed by the Sequencer as accesses flow through to the cache hierarchy. Further, protocol state machines should be enforcing these cache hit latencies, but RubyCaches do not expose their latency to any existng state machines through the SLICC/C++ interface. Thus, the RubyCache latency parameter is superfluous for all caches. This is confusing for users. As a step toward pushing L0/L1 cache hit latency into the top-level cache controllers, move their latencies out of the RubyCache declarations and over to their Sequencers. Eventually, these Sequencer parameters should be exposed as parameters to the top-level cache controllers, which should assess the latency. NOTE: Assessing these latencies in the cache controllers will require modifying each to eliminate instantaneous Ruby hit callbacks in transitions that finish accesses, which is likely a large undertaking.
2015-08-14 07:19:37 +02:00
class Cache(RubyCache): pass
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
config: reorganized how ruby specifies command-line options
2010-08-20 20:44:09 +02:00
def define_options(parser):
return
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
def create_system(options, full_system, system, dma_ports, ruby_system):
ruby: remove extra whitespace and correct misspelled words
2015-07-10 23:05:23 +02:00
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
if buildEnv['PROTOCOL'] != 'MI_example':
panic("This script requires the MI_example protocol to be built.")
cpu_sequencers = []
ruby: remove extra whitespace and correct misspelled words
2015-07-10 23:05:23 +02:00
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
#
# The ruby network creation expects the list of nodes in the system to be
# consistent with the NetDest list. Therefore the l1 controller nodes must be
# listed before the directory nodes and directory nodes before dma nodes, etc.
#
l1_cntrl_nodes = []
dir_cntrl_nodes = []
dma_cntrl_nodes = []
#
# Must create the individual controllers before the network to ensure the
# controller constructors are called before the network constructor
#
ruby: fixed cache index setting
2011-03-25 18:13:50 +01:00
block_size_bits = int(math.log(options.cacheline_size, 2))
network: convert links & switches to first class C++ SimObjects This patch converts links and switches from second class simobjects that were virtually ignored by the networks (both simple and Garnet) to first class simobjects that directly correspond to c++ ojbects manipulated by the topology and network classes. This is especially true for Garnet, where the links and switches directly correspond to specific C++ objects. By making this change, many aspects of the Topology class were simplified. --HG-- rename : src/mem/ruby/network/Network.cc => src/mem/ruby/network/BasicLink.cc rename : src/mem/ruby/network/Network.hh => src/mem/ruby/network/BasicLink.hh rename : src/mem/ruby/network/Network.cc => src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.cc rename : src/mem/ruby/network/Network.hh => src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.hh rename : src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.py => src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.py rename : src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.py => src/mem/ruby/network/garnet/fixed-pipeline/GarnetRouter_d.py rename : src/mem/ruby/network/Network.cc => src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.cc rename : src/mem/ruby/network/Network.hh => src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.hh rename : src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.py => src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.py rename : src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.py => src/mem/ruby/network/garnet/flexible-pipeline/GarnetRouter.py
2011-04-29 02:18:14 +02:00
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
for i in xrange(options.num_cpus):
#
# First create the Ruby objects associated with this cpu
# Only one cache exists for this protocol, so by default use the L1D
# config parameters.
#
cache = Cache(size = options.l1d_size,
ruby: fixed cache index setting
2011-03-25 18:13:50 +01:00
assoc = options.l1d_assoc,
start_index_bit = block_size_bits)
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
#
# Only one unified L1 cache exists. Can cache instructions and data.
#
config: tweak ruby configs to clean up hierarchy Re-enabling implicit parenting (see previous patch) causes current Ruby config scripts to create some strange hierarchies and generate several warnings. This patch makes three general changes to address these issues. 1. The order of object creation in the ruby config files makes the L1 caches children of the sequencer rather than the controller; these config ciles are rewritten to assign the L1 caches to the controller first. 2. The assignment of the sequencer list to system.ruby.cpu_ruby_ports causes the sequencers to be children of system.ruby, generating warnings because they are already parented to their respective controllers. Changing this attribute to _cpu_ruby_ports fixes this because the leading underscore means this is now treated as a plain Python attribute rather than a child assignment. As a result, the configuration hierarchy changes such that, e.g., system.ruby.cpu_ruby_ports0 becomes system.l1_cntrl0.sequencer. 3. In the topology classes, the routers become children of some random internal link node rather than direct children of the topology. The topology classes are rewritten to assign the routers to the topology object first.
2011-05-23 23:29:23 +02:00
l1_cntrl = L1Cache_Controller(version = i,
Ruby: Add support for functional accesses This patch rpovides functional access support in Ruby. Currently only the M5Port of RubyPort supports functional accesses. The support for functional through the PioPort will be added as a separate patch.
2011-07-01 02:49:26 +02:00
cacheMemory = cache,
x86 isa: This patch attempts an implementation at mwait. Mwait works as follows: 1. A cpu monitors an address of interest (monitor instruction) 2. A cpu calls mwait - this loads the cache line into that cpu's cache. 3. The cpu goes to sleep. 4. When another processor requests write permission for the line, it is evicted from the sleeping cpu's cache. This eviction is forwarded to the sleeping cpu, which then wakes up. Committed by: Nilay Vaish <nilay@cs.wisc.edu>
2014-11-06 12:42:22 +01:00
send_evictions = send_evicts(options),
ruby: add option for number of transitions per cycle The number of transitions per cycle that a controller can carry out is a proxy for the number of ports that a controller has. This value is currently 32 which is way too high. The patch introduces an option for the number of ports and uses this option in the protocol files to set the number of transitions. The default value is being set to 4. None of the se regressions change. Ruby stats for the fs regression change and are being updated.
2013-08-20 18:32:31 +02:00
transitions_per_cycle = options.ports,
ruby: Fixes clock domains in configuration files This patch fixes scripts related to ruby by adding the ruby clock domain. Now the L1 controllers and the Sequencer shares the cpu clock domain, while the rest of the components use the ruby clock domain. Before this patch, running simulations with the cpu clock set at 2GHz or 1GHz will output the same time results and could distort power measurements. Committed by: Nilay Vaish <nilay@cs.wisc.edu>
2014-09-01 23:55:30 +02:00
clk_domain=system.cpu[i].clk_domain,
Ruby: Add support for functional accesses This patch rpovides functional access support in Ruby. Currently only the M5Port of RubyPort supports functional accesses. The support for functional through the PioPort will be added as a separate patch.
2011-07-01 02:49:26 +02:00
ruby_system = ruby_system)
config: tweak ruby configs to clean up hierarchy Re-enabling implicit parenting (see previous patch) causes current Ruby config scripts to create some strange hierarchies and generate several warnings. This patch makes three general changes to address these issues. 1. The order of object creation in the ruby config files makes the L1 caches children of the sequencer rather than the controller; these config ciles are rewritten to assign the L1 caches to the controller first. 2. The assignment of the sequencer list to system.ruby.cpu_ruby_ports causes the sequencers to be children of system.ruby, generating warnings because they are already parented to their respective controllers. Changing this attribute to _cpu_ruby_ports fixes this because the leading underscore means this is now treated as a plain Python attribute rather than a child assignment. As a result, the configuration hierarchy changes such that, e.g., system.ruby.cpu_ruby_ports0 becomes system.l1_cntrl0.sequencer. 3. In the topology classes, the routers become children of some random internal link node rather than direct children of the topology. The topology classes are rewritten to assign the routers to the topology object first.
2011-05-23 23:29:23 +02:00
ruby: Python config files now sets a unique id for each sequencer
2010-03-22 05:22:20 +01:00
cpu_seq = RubySequencer(version = i,
icache = cache,
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
dcache = cache,
ruby: Fixes clock domains in configuration files This patch fixes scripts related to ruby by adding the ruby clock domain. Now the L1 controllers and the Sequencer shares the cpu clock domain, while the rest of the components use the ruby clock domain. Before this patch, running simulations with the cpu clock set at 2GHz or 1GHz will output the same time results and could distort power measurements. Committed by: Nilay Vaish <nilay@cs.wisc.edu>
2014-09-01 23:55:30 +02:00
clk_domain=system.cpu[i].clk_domain,
Ruby: Add support for functional accesses This patch rpovides functional access support in Ruby. Currently only the M5Port of RubyPort supports functional accesses. The support for functional through the PioPort will be added as a separate patch.
2011-07-01 02:49:26 +02:00
ruby_system = ruby_system)
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
config: tweak ruby configs to clean up hierarchy Re-enabling implicit parenting (see previous patch) causes current Ruby config scripts to create some strange hierarchies and generate several warnings. This patch makes three general changes to address these issues. 1. The order of object creation in the ruby config files makes the L1 caches children of the sequencer rather than the controller; these config ciles are rewritten to assign the L1 caches to the controller first. 2. The assignment of the sequencer list to system.ruby.cpu_ruby_ports causes the sequencers to be children of system.ruby, generating warnings because they are already parented to their respective controllers. Changing this attribute to _cpu_ruby_ports fixes this because the leading underscore means this is now treated as a plain Python attribute rather than a child assignment. As a result, the configuration hierarchy changes such that, e.g., system.ruby.cpu_ruby_ports0 becomes system.l1_cntrl0.sequencer. 3. In the topology classes, the routers become children of some random internal link node rather than direct children of the topology. The topology classes are rewritten to assign the routers to the topology object first.
2011-05-23 23:29:23 +02:00
l1_cntrl.sequencer = cpu_seq
config: move ruby objects under ruby_system in obj hierarchy This patch moves the contollers to be children of the ruby_system instead of 'system' under the python object hierarchy. This is so that these objects can inherit some of the ruby_system's parameter values without resorting to calling a global system pointer during run-time. Committed by: Nilay Vaish <nilay@cs.wisc.edu>
2013-01-14 17:05:14 +01:00
exec("ruby_system.l1_cntrl%d = l1_cntrl" % i)
config: ruby: remove piobus from protocols This patch removes the piobus from the protocol config files. The ports are now connected to the piobus in the Ruby.py file.
2014-03-17 23:40:15 +01:00
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
# Add controllers and sequencers to the appropriate lists
cpu_sequencers.append(cpu_seq)
l1_cntrl_nodes.append(l1_cntrl)
ruby: message buffers: significant changes This patch is the final patch in a series of patches. The aim of the series is to make ruby more configurable than it was. More specifically, the connections between controllers are not at all possible (unless one is ready to make significant changes to the coherence protocol). Moreover the buffers themselves are magically connected to the network inside the slicc code. These connections are not part of the configuration file. This patch makes changes so that these connections will now be made in the python configuration files associated with the protocols. This requires each state machine to expose the message buffers it uses for input and output. So, the patch makes these buffers configurable members of the machines. The patch drops the slicc code that usd to connect these buffers to the network. Now these buffers are exposed to the python configuration system as Master and Slave ports. In the configuration files, any master port can be connected any slave port. The file pyobject.cc has been modified to take care of allocating the actual message buffer. This is inline with how other port connections work.
2014-09-01 23:55:47 +02:00
# Connect the L1 controllers and the network
ruby: Protocol changes for SimObject MessageBuffers
2015-08-14 07:19:45 +02:00
l1_cntrl.mandatoryQueue = MessageBuffer()
l1_cntrl.requestFromCache = MessageBuffer(ordered = True)
l1_cntrl.requestFromCache.master = ruby_system.network.slave
l1_cntrl.responseFromCache = MessageBuffer(ordered = True)
l1_cntrl.responseFromCache.master = ruby_system.network.slave
l1_cntrl.forwardToCache = MessageBuffer(ordered = True)
l1_cntrl.forwardToCache.slave = ruby_system.network.master
l1_cntrl.responseToCache = MessageBuffer(ordered = True)
l1_cntrl.responseToCache.slave = ruby_system.network.master
ruby: message buffers: significant changes This patch is the final patch in a series of patches. The aim of the series is to make ruby more configurable than it was. More specifically, the connections between controllers are not at all possible (unless one is ready to make significant changes to the coherence protocol). Moreover the buffers themselves are magically connected to the network inside the slicc code. These connections are not part of the configuration file. This patch makes changes so that these connections will now be made in the python configuration files associated with the protocols. This requires each state machine to expose the message buffers it uses for input and output. So, the patch makes these buffers configurable members of the machines. The patch drops the slicc code that usd to connect these buffers to the network. Now these buffers are exposed to the python configuration system as Master and Slave ports. In the configuration files, any master port can be connected any slave port. The file pyobject.cc has been modified to take care of allocating the actual message buffer. This is inline with how other port connections work.
2014-09-01 23:55:47 +02:00
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
phys_mem_size = sum(map(lambda r: r.size(), system.mem_ranges))
ruby: check for compatibility between mem size and num dirs The configuration scripts provided for ruby assume that the available physical memory is equally distributed amongst the directory controllers. But there is no check to ensure this assumption has been adhered to. This patch adds the required check.
2013-06-29 04:36:11 +02:00
assert(phys_mem_size % options.num_dirs == 0)
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
mem_module_size = phys_mem_size / options.num_dirs
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
# Run each of the ruby memory controllers at a ratio of the frequency of
# the ruby system.
# clk_divider value is a fix to pass regression.
ruby_system.memctrl_clk_domain = DerivedClockDomain(
clk_domain=ruby_system.clk_domain,
clk_divider=3)
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
for i in xrange(options.num_dirs):
dir_size = MemorySize('0B')
dir_size.value = mem_module_size
dir_cntrl = Directory_Controller(version = i,
ruby: interface with classic memory controller This patch is the final in the series. The whole series and this patch in particular were written with the aim of interfacing ruby's directory controller with the memory controller in the classic memory system. This is being done since ruby's memory controller has not being kept up to date with the changes going on in DRAMs. Classic's memory controller is more up to date and supports multiple different types of DRAM. This also brings classic and ruby ever more close. The patch also changes ruby's memory controller to expose the same interface.
2014-11-06 12:42:21 +01:00
directory = RubyDirectoryMemory(
version = i, size = dir_size),
ruby: add option for number of transitions per cycle The number of transitions per cycle that a controller can carry out is a proxy for the number of ports that a controller has. This value is currently 32 which is way too high. The patch introduces an option for the number of ports and uses this option in the protocol files to set the number of transitions. The default value is being set to 4. None of the se regressions change. Ruby stats for the fs regression change and are being updated.
2013-08-20 18:32:31 +02:00
transitions_per_cycle = options.ports,
Ruby: Add support for functional accesses This patch rpovides functional access support in Ruby. Currently only the M5Port of RubyPort supports functional accesses. The support for functional through the PioPort will be added as a separate patch.
2011-07-01 02:49:26 +02:00
ruby_system = ruby_system)
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
config: move ruby objects under ruby_system in obj hierarchy This patch moves the contollers to be children of the ruby_system instead of 'system' under the python object hierarchy. This is so that these objects can inherit some of the ruby_system's parameter values without resorting to calling a global system pointer during run-time. Committed by: Nilay Vaish <nilay@cs.wisc.edu>
2013-01-14 17:05:14 +01:00
exec("ruby_system.dir_cntrl%d = dir_cntrl" % i)
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
dir_cntrl_nodes.append(dir_cntrl)
ruby: message buffers: significant changes This patch is the final patch in a series of patches. The aim of the series is to make ruby more configurable than it was. More specifically, the connections between controllers are not at all possible (unless one is ready to make significant changes to the coherence protocol). Moreover the buffers themselves are magically connected to the network inside the slicc code. These connections are not part of the configuration file. This patch makes changes so that these connections will now be made in the python configuration files associated with the protocols. This requires each state machine to expose the message buffers it uses for input and output. So, the patch makes these buffers configurable members of the machines. The patch drops the slicc code that usd to connect these buffers to the network. Now these buffers are exposed to the python configuration system as Master and Slave ports. In the configuration files, any master port can be connected any slave port. The file pyobject.cc has been modified to take care of allocating the actual message buffer. This is inline with how other port connections work.
2014-09-01 23:55:47 +02:00
# Connect the directory controllers and the network
ruby: Protocol changes for SimObject MessageBuffers
2015-08-14 07:19:45 +02:00
dir_cntrl.requestToDir = MessageBuffer(ordered = True)
dir_cntrl.requestToDir.slave = ruby_system.network.master
dir_cntrl.dmaRequestToDir = MessageBuffer(ordered = True)
dir_cntrl.dmaRequestToDir.slave = ruby_system.network.master
ruby: message buffers: significant changes This patch is the final patch in a series of patches. The aim of the series is to make ruby more configurable than it was. More specifically, the connections between controllers are not at all possible (unless one is ready to make significant changes to the coherence protocol). Moreover the buffers themselves are magically connected to the network inside the slicc code. These connections are not part of the configuration file. This patch makes changes so that these connections will now be made in the python configuration files associated with the protocols. This requires each state machine to expose the message buffers it uses for input and output. So, the patch makes these buffers configurable members of the machines. The patch drops the slicc code that usd to connect these buffers to the network. Now these buffers are exposed to the python configuration system as Master and Slave ports. In the configuration files, any master port can be connected any slave port. The file pyobject.cc has been modified to take care of allocating the actual message buffer. This is inline with how other port connections work.
2014-09-01 23:55:47 +02:00
ruby: Protocol changes for SimObject MessageBuffers
2015-08-14 07:19:45 +02:00
dir_cntrl.responseFromDir = MessageBuffer()
dir_cntrl.responseFromDir.master = ruby_system.network.slave
dir_cntrl.dmaResponseFromDir = MessageBuffer(ordered = True)
dir_cntrl.dmaResponseFromDir.master = ruby_system.network.slave
dir_cntrl.forwardFromDir = MessageBuffer()
dir_cntrl.forwardFromDir.master = ruby_system.network.slave
dir_cntrl.responseFromMemory = MessageBuffer()
ruby: message buffers: significant changes This patch is the final patch in a series of patches. The aim of the series is to make ruby more configurable than it was. More specifically, the connections between controllers are not at all possible (unless one is ready to make significant changes to the coherence protocol). Moreover the buffers themselves are magically connected to the network inside the slicc code. These connections are not part of the configuration file. This patch makes changes so that these connections will now be made in the python configuration files associated with the protocols. This requires each state machine to expose the message buffers it uses for input and output. So, the patch makes these buffers configurable members of the machines. The patch drops the slicc code that usd to connect these buffers to the network. Now these buffers are exposed to the python configuration system as Master and Slave ports. In the configuration files, any master port can be connected any slave port. The file pyobject.cc has been modified to take care of allocating the actual message buffer. This is inline with how other port connections work.
2014-09-01 23:55:47 +02:00
Config: corrects the way Ruby attaches to the DMA ports With recent changes to the memory system, a port cannot be assigned a peer port twice. While making use of the Ruby memory system in FS mode, DMA ports were assigned peer twice, once for the classic memory system and once for the Ruby memory system. This patch removes this double assignment of peer ports.
2012-04-05 18:09:19 +02:00
for i, dma_port in enumerate(dma_ports):
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
#
# Create the Ruby objects associated with the dma controller
#
dma_seq = DMASequencer(version = i,
Ruby: Fix instantiations of DMA controller and sequencer The patch on Ruby functional accesses made changes to the process of instantiating controllers and sequencers. The DMA controller and sequencer was not updated, hence this patch.
2011-07-26 19:20:22 +02:00
ruby_system = ruby_system)
ruby: remove extra whitespace and correct misspelled words
2015-07-10 23:05:23 +02:00
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
dma_cntrl = DMA_Controller(version = i,
Ruby: Fix instantiations of DMA controller and sequencer The patch on Ruby functional accesses made changes to the process of instantiating controllers and sequencers. The DMA controller and sequencer was not updated, hence this patch.
2011-07-26 19:20:22 +02:00
dma_sequencer = dma_seq,
ruby: add option for number of transitions per cycle The number of transitions per cycle that a controller can carry out is a proxy for the number of ports that a controller has. This value is currently 32 which is way too high. The patch introduces an option for the number of ports and uses this option in the protocol files to set the number of transitions. The default value is being set to 4. None of the se regressions change. Ruby stats for the fs regression change and are being updated.
2013-08-20 18:32:31 +02:00
transitions_per_cycle = options.ports,
Ruby: Fix instantiations of DMA controller and sequencer The patch on Ruby functional accesses made changes to the process of instantiating controllers and sequencers. The DMA controller and sequencer was not updated, hence this patch.
2011-07-26 19:20:22 +02:00
ruby_system = ruby_system)
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
config: move ruby objects under ruby_system in obj hierarchy This patch moves the contollers to be children of the ruby_system instead of 'system' under the python object hierarchy. This is so that these objects can inherit some of the ruby_system's parameter values without resorting to calling a global system pointer during run-time. Committed by: Nilay Vaish <nilay@cs.wisc.edu>
2013-01-14 17:05:14 +01:00
exec("ruby_system.dma_cntrl%d = dma_cntrl" % i)
exec("ruby_system.dma_cntrl%d.dma_sequencer.slave = dma_port" % i)
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
dma_cntrl_nodes.append(dma_cntrl)
network: convert links & switches to first class C++ SimObjects This patch converts links and switches from second class simobjects that were virtually ignored by the networks (both simple and Garnet) to first class simobjects that directly correspond to c++ ojbects manipulated by the topology and network classes. This is especially true for Garnet, where the links and switches directly correspond to specific C++ objects. By making this change, many aspects of the Topology class were simplified. --HG-- rename : src/mem/ruby/network/Network.cc => src/mem/ruby/network/BasicLink.cc rename : src/mem/ruby/network/Network.hh => src/mem/ruby/network/BasicLink.hh rename : src/mem/ruby/network/Network.cc => src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.cc rename : src/mem/ruby/network/Network.hh => src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.hh rename : src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.py => src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.py rename : src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.py => src/mem/ruby/network/garnet/fixed-pipeline/GarnetRouter_d.py rename : src/mem/ruby/network/Network.cc => src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.cc rename : src/mem/ruby/network/Network.hh => src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.hh rename : src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.py => src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.py rename : src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.py => src/mem/ruby/network/garnet/flexible-pipeline/GarnetRouter.py
2011-04-29 02:18:14 +02:00
ruby: message buffers: significant changes This patch is the final patch in a series of patches. The aim of the series is to make ruby more configurable than it was. More specifically, the connections between controllers are not at all possible (unless one is ready to make significant changes to the coherence protocol). Moreover the buffers themselves are magically connected to the network inside the slicc code. These connections are not part of the configuration file. This patch makes changes so that these connections will now be made in the python configuration files associated with the protocols. This requires each state machine to expose the message buffers it uses for input and output. So, the patch makes these buffers configurable members of the machines. The patch drops the slicc code that usd to connect these buffers to the network. Now these buffers are exposed to the python configuration system as Master and Slave ports. In the configuration files, any master port can be connected any slave port. The file pyobject.cc has been modified to take care of allocating the actual message buffer. This is inline with how other port connections work.
2014-09-01 23:55:47 +02:00
# Connect the directory controllers and the network
ruby: Protocol changes for SimObject MessageBuffers
2015-08-14 07:19:45 +02:00
dma_cntrl.mandatoryQueue = MessageBuffer()
dma_cntrl.requestToDir = MessageBuffer()
dma_cntrl.requestToDir.master = ruby_system.network.slave
dma_cntrl.responseFromDir = MessageBuffer(ordered = True)
dma_cntrl.responseFromDir.slave = ruby_system.network.master
ruby: MI_example updates to use the new config system
2010-01-30 05:29:24 +01:00
ruby: message buffers: significant changes This patch is the final patch in a series of patches. The aim of the series is to make ruby more configurable than it was. More specifically, the connections between controllers are not at all possible (unless one is ready to make significant changes to the coherence protocol). Moreover the buffers themselves are magically connected to the network inside the slicc code. These connections are not part of the configuration file. This patch makes changes so that these connections will now be made in the python configuration files associated with the protocols. This requires each state machine to expose the message buffers it uses for input and output. So, the patch makes these buffers configurable members of the machines. The patch drops the slicc code that usd to connect these buffers to the network. Now these buffers are exposed to the python configuration system as Master and Slave ports. In the configuration files, any master port can be connected any slave port. The file pyobject.cc has been modified to take care of allocating the actual message buffer. This is inline with how other port connections work.
2014-09-01 23:55:47 +02:00
all_cntrls = l1_cntrl_nodes + dir_cntrl_nodes + dma_cntrl_nodes
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
# Create the io controller and the sequencer
if full_system:
io_seq = DMASequencer(version=len(dma_ports), ruby_system=ruby_system)
ruby_system._io_port = io_seq
io_controller = DMA_Controller(version = len(dma_ports),
dma_sequencer = io_seq,
ruby_system = ruby_system)
ruby_system.io_controller = io_controller
# Connect the dma controller to the network
ruby: Protocol changes for SimObject MessageBuffers
2015-08-14 07:19:45 +02:00
io_controller.mandatoryQueue = MessageBuffer()
io_controller.requestToDir = MessageBuffer()
io_controller.requestToDir.master = ruby_system.network.slave
io_controller.responseFromDir = MessageBuffer(ordered = True)
io_controller.responseFromDir.slave = ruby_system.network.master
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
all_cntrls = all_cntrls + [io_controller]
ruby: message buffers: significant changes This patch is the final patch in a series of patches. The aim of the series is to make ruby more configurable than it was. More specifically, the connections between controllers are not at all possible (unless one is ready to make significant changes to the coherence protocol). Moreover the buffers themselves are magically connected to the network inside the slicc code. These connections are not part of the configuration file. This patch makes changes so that these connections will now be made in the python configuration files associated with the protocols. This requires each state machine to expose the message buffers it uses for input and output. So, the patch makes these buffers configurable members of the machines. The patch drops the slicc code that usd to connect these buffers to the network. Now these buffers are exposed to the python configuration system as Master and Slave ports. In the configuration files, any master port can be connected any slave port. The file pyobject.cc has been modified to take care of allocating the actual message buffer. This is inline with how other port connections work.
2014-09-01 23:55:47 +02:00
topology = create_topology(all_cntrls, options)
ruby: changes how Topologies are created Instead of just passing a list of controllers to the makeTopology function in src/mem/ruby/network/topologies/<Topo>.py we pass in a function pointer which knows how to make the topology, possibly with some extra state set in the configs/ruby/<protocol>.py file. Thus, we can move all of the files from network/topologies to configs/topologies. A new class BaseTopology is added which all topologies in configs/topologies must inheirit from and follow its API. --HG-- rename : src/mem/ruby/network/topologies/Crossbar.py => configs/topologies/Crossbar.py rename : src/mem/ruby/network/topologies/Mesh.py => configs/topologies/Mesh.py rename : src/mem/ruby/network/topologies/MeshDirCorners.py => configs/topologies/MeshDirCorners.py rename : src/mem/ruby/network/topologies/Pt2Pt.py => configs/topologies/Pt2Pt.py rename : src/mem/ruby/network/topologies/Torus.py => configs/topologies/Torus.py
2012-07-11 07:51:53 +02:00
return (cpu_sequencers, dir_cntrl_nodes, topology)
Reference in a new issue Copy permalink