gem5/src/mem/XBar.py

163 lines
6.7 KiB
Python
Raw Normal View History

# Copyright (c) 2012, 2015 ARM Limited
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
# All rights reserved.
#
# The license below extends only to copyright in the software and shall
# not be construed as granting a license to any other intellectual
# property including but not limited to intellectual property relating
# to a hardware implementation of the functionality of the software
# licensed hereunder. You may use the software subject to the license
# terms below provided that you ensure that this notice is replicated
# unmodified and in its entirety in all distributions of the software,
# modified or unmodified, in source code or in binary form.
#
# Copyright (c) 2005-2008 The Regents of The University of Michigan
Move SimObject python files alongside the C++ and fix 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-05-28 04:21:17 +02:00
# 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: Nathan Binkert
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
# Andreas Hansson
Move SimObject python files alongside the C++ and fix 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-05-28 04:21:17 +02:00
from MemObject import MemObject
from System import System
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
from m5.params import *
from m5.proxy import *
from m5.SimObject import SimObject
Move SimObject python files alongside the C++ and fix 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-05-28 04:21:17 +02:00
class BaseXBar(MemObject):
type = 'BaseXBar'
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
abstract = True
cxx_header = "mem/xbar.hh"
slave = VectorSlavePort("Vector port for connecting masters")
master = VectorMasterPort("Vector port for connecting slaves")
# Latencies governing the time taken for the variuos paths a
# packet has through the crossbar. Note that the crossbar itself
# does not add the latency due to assumptions in the coherency
# mechanism. Instead the latency is annotated on the packet and
# left to the neighbouring modules.
#
# A request incurs the frontend latency, possibly snoop filter
# lookup latency, and forward latency. A response incurs the
# response latency. Frontend latency encompasses arbitration and
# deciding what to do when a request arrives. the forward latency
# is the latency involved once a decision is made to forward the
# request. The response latency, is similar to the forward
# latency, but for responses rather than requests.
frontend_latency = Param.Cycles("Frontend latency")
forward_latency = Param.Cycles("Forward latency")
response_latency = Param.Cycles("Response latency")
# Width governing the throughput of the crossbar
width = Param.Unsigned("Datapath width per port (bytes)")
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
# The default port can be left unconnected, or be used to connect
# a default slave port
default = MasterPort("Port for connecting an optional default slave")
# The default port can be used unconditionally, or based on
# address range, in which case it may overlap with other
# ports. The default range is always checked first, thus creating
# a two-level hierarchical lookup. This is useful e.g. for the PCI
# xbar configuration.
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
use_default_range = Param.Bool(False, "Perform address mapping for " \
"the default port")
class NoncoherentXBar(BaseXBar):
type = 'NoncoherentXBar'
cxx_header = "mem/noncoherent_xbar.hh"
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
class CoherentXBar(BaseXBar):
type = 'CoherentXBar'
cxx_header = "mem/coherent_xbar.hh"
# The coherent crossbar additionally has snoop responses that are
# forwarded after a specific latency.
snoop_response_latency = Param.Cycles("Snoop response latency")
# An optional snoop filter
snoop_filter = Param.SnoopFilter(NULL, "Selected snoop filter")
system = Param.System(Parent.any, "System that the crossbar belongs to.")
class SnoopFilter(SimObject):
type = 'SnoopFilter'
cxx_header = "mem/snoop_filter.hh"
# Lookup latency of the snoop filter, added to requests that pass
# through a coherent crossbar.
lookup_latency = Param.Cycles(1, "Lookup latency")
system = Param.System(Parent.any, "System that the crossbar belongs to.")
# Sanity check on max capacity to track, adjust if needed.
max_capacity = Param.MemorySize('8MB', "Maximum capacity of snoop filter")
# We use a coherent crossbar to connect multiple masters to the L2
# caches. Normally this crossbar would be part of the cache itself.
class L2XBar(CoherentXBar):
# 256-bit crossbar by default
width = 32
# Assume that most of this is covered by the cache latencies, with
# no more than a single pipeline stage for any packet.
frontend_latency = 1
forward_latency = 0
response_latency = 1
snoop_response_latency = 1
# Use a snoop-filter by default, and set the latency to zero as
# the lookup is assumed to overlap with the frontend latency of
# the crossbar
snoop_filter = SnoopFilter(lookup_latency = 0)
# One of the key coherent crossbar instances is the system
# interconnect, tying together the CPU clusters, GPUs, and any I/O
# coherent masters, and DRAM controllers.
class SystemXBar(CoherentXBar):
# 128-bit crossbar by default
width = 16
# A handful pipeline stages for each portion of the latency
# contributions.
frontend_latency = 3
forward_latency = 4
response_latency = 2
snoop_response_latency = 4
# In addition to the system interconnect, we typically also have one
# or more on-chip I/O crossbars. Note that at some point we might want
# to also define an off-chip I/O crossbar such as PCIe.
class IOXBar(NoncoherentXBar):
# 128-bit crossbar by default
width = 16
# Assume a simpler datapath than a coherent crossbar, incuring
# less pipeline stages for decision making and forwarding of
# requests.
frontend_latency = 2
forward_latency = 1
response_latency = 2