mem: Add crossbar latencies
This patch introduces latencies in crossbar that were neglected
before. In particular, it adds three parameters in crossbar model:
front_end_latency, forward_latency, and response_latency. Along with
these parameters, three corresponding members are added:
frontEndLatency, forwardLatency, and responseLatency. The coherent
crossbar has an additional snoop_response_latency.
The latency of the request path through the xbar is set as
--> frontEndLatency + forwardLatency
In case the snoop filter is enabled, the request path latency is charged
also by look-up latency of the snoop filter.
--> frontEndLatency + SF(lookupLatency) + forwardLatency.
The latency of the response path through the xbar is set instead as
--> responseLatency.
In case of snoop response, if the response is treated as a normal response
the latency associated is again
--> responseLatency;
If instead it is forwarded as snoop response we add an additional variable
+ snoopResponseLatency
and the latency associated is
--> snoopResponseLatency;
Furthermore, this patch lets the crossbar progress on the next clock
edge after an unused retry, changing the time the crossbar considers
itself busy after sending a retry that was not acted upon.
2015-03-02 10:00:46 +01:00
|
|
|
# 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.
|
|
|
|
#
|
2008-02-26 08:20:08 +01:00
|
|
|
# Copyright (c) 2005-2008 The Regents of The University of Michigan
|
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
|
2007-05-28 04:21:17 +02:00
|
|
|
|
|
|
|
from MemObject import MemObject
|
2013-02-15 23:40:09 +01:00
|
|
|
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 *
|
2013-02-15 23:40:09 +01:00
|
|
|
from m5.proxy import *
|
2014-09-20 23:18:26 +02:00
|
|
|
from m5.SimObject import SimObject
|
2007-05-28 04:21:17 +02:00
|
|
|
|
2014-09-20 23:18:32 +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
|
2014-09-20 23:18:32 +02:00
|
|
|
cxx_header = "mem/xbar.hh"
|
mem: Add crossbar latencies
This patch introduces latencies in crossbar that were neglected
before. In particular, it adds three parameters in crossbar model:
front_end_latency, forward_latency, and response_latency. Along with
these parameters, three corresponding members are added:
frontEndLatency, forwardLatency, and responseLatency. The coherent
crossbar has an additional snoop_response_latency.
The latency of the request path through the xbar is set as
--> frontEndLatency + forwardLatency
In case the snoop filter is enabled, the request path latency is charged
also by look-up latency of the snoop filter.
--> frontEndLatency + SF(lookupLatency) + forwardLatency.
The latency of the response path through the xbar is set instead as
--> responseLatency.
In case of snoop response, if the response is treated as a normal response
the latency associated is again
--> responseLatency;
If instead it is forwarded as snoop response we add an additional variable
+ snoopResponseLatency
and the latency associated is
--> snoopResponseLatency;
Furthermore, this patch lets the crossbar progress on the next clock
edge after an unused retry, changing the time the crossbar considers
itself busy after sending a retry that was not acted upon.
2015-03-02 10:00:46 +01:00
|
|
|
|
|
|
|
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.
|
2015-03-02 10:00:47 +01:00
|
|
|
frontend_latency = Param.Cycles("Frontend latency")
|
|
|
|
forward_latency = Param.Cycles("Forward latency")
|
|
|
|
response_latency = Param.Cycles("Response latency")
|
mem: Add crossbar latencies
This patch introduces latencies in crossbar that were neglected
before. In particular, it adds three parameters in crossbar model:
front_end_latency, forward_latency, and response_latency. Along with
these parameters, three corresponding members are added:
frontEndLatency, forwardLatency, and responseLatency. The coherent
crossbar has an additional snoop_response_latency.
The latency of the request path through the xbar is set as
--> frontEndLatency + forwardLatency
In case the snoop filter is enabled, the request path latency is charged
also by look-up latency of the snoop filter.
--> frontEndLatency + SF(lookupLatency) + forwardLatency.
The latency of the response path through the xbar is set instead as
--> responseLatency.
In case of snoop response, if the response is treated as a normal response
the latency associated is again
--> responseLatency;
If instead it is forwarded as snoop response we add an additional variable
+ snoopResponseLatency
and the latency associated is
--> snoopResponseLatency;
Furthermore, this patch lets the crossbar progress on the next clock
edge after an unused retry, changing the time the crossbar considers
itself busy after sending a retry that was not acted upon.
2015-03-02 10:00:46 +01:00
|
|
|
|
|
|
|
# Width governing the throughput of the crossbar
|
2015-03-02 10:00:47 +01:00
|
|
|
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
|
2014-09-20 23:18:32 +02:00
|
|
|
# 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")
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
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
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
class CoherentXBar(BaseXBar):
|
|
|
|
type = 'CoherentXBar'
|
|
|
|
cxx_header = "mem/coherent_xbar.hh"
|
2013-02-15 23:40:09 +01:00
|
|
|
|
mem: Add crossbar latencies
This patch introduces latencies in crossbar that were neglected
before. In particular, it adds three parameters in crossbar model:
front_end_latency, forward_latency, and response_latency. Along with
these parameters, three corresponding members are added:
frontEndLatency, forwardLatency, and responseLatency. The coherent
crossbar has an additional snoop_response_latency.
The latency of the request path through the xbar is set as
--> frontEndLatency + forwardLatency
In case the snoop filter is enabled, the request path latency is charged
also by look-up latency of the snoop filter.
--> frontEndLatency + SF(lookupLatency) + forwardLatency.
The latency of the response path through the xbar is set instead as
--> responseLatency.
In case of snoop response, if the response is treated as a normal response
the latency associated is again
--> responseLatency;
If instead it is forwarded as snoop response we add an additional variable
+ snoopResponseLatency
and the latency associated is
--> snoopResponseLatency;
Furthermore, this patch lets the crossbar progress on the next clock
edge after an unused retry, changing the time the crossbar considers
itself busy after sending a retry that was not acted upon.
2015-03-02 10:00:46 +01:00
|
|
|
# The coherent crossbar additionally has snoop responses that are
|
|
|
|
# forwarded after a specific latency.
|
2015-03-02 10:00:47 +01:00
|
|
|
snoop_response_latency = Param.Cycles("Snoop response latency")
|
mem: Add crossbar latencies
This patch introduces latencies in crossbar that were neglected
before. In particular, it adds three parameters in crossbar model:
front_end_latency, forward_latency, and response_latency. Along with
these parameters, three corresponding members are added:
frontEndLatency, forwardLatency, and responseLatency. The coherent
crossbar has an additional snoop_response_latency.
The latency of the request path through the xbar is set as
--> frontEndLatency + forwardLatency
In case the snoop filter is enabled, the request path latency is charged
also by look-up latency of the snoop filter.
--> frontEndLatency + SF(lookupLatency) + forwardLatency.
The latency of the response path through the xbar is set instead as
--> responseLatency.
In case of snoop response, if the response is treated as a normal response
the latency associated is again
--> responseLatency;
If instead it is forwarded as snoop response we add an additional variable
+ snoopResponseLatency
and the latency associated is
--> snoopResponseLatency;
Furthermore, this patch lets the crossbar progress on the next clock
edge after an unused retry, changing the time the crossbar considers
itself busy after sending a retry that was not acted upon.
2015-03-02 10:00:46 +01:00
|
|
|
|
|
|
|
# An optional snoop filter
|
|
|
|
snoop_filter = Param.SnoopFilter(NULL, "Selected snoop filter")
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
system = Param.System(Parent.any, "System that the crossbar belongs to.")
|
2014-09-20 23:18:26 +02:00
|
|
|
|
|
|
|
class SnoopFilter(SimObject):
|
|
|
|
type = 'SnoopFilter'
|
|
|
|
cxx_header = "mem/snoop_filter.hh"
|
mem: Add crossbar latencies
This patch introduces latencies in crossbar that were neglected
before. In particular, it adds three parameters in crossbar model:
front_end_latency, forward_latency, and response_latency. Along with
these parameters, three corresponding members are added:
frontEndLatency, forwardLatency, and responseLatency. The coherent
crossbar has an additional snoop_response_latency.
The latency of the request path through the xbar is set as
--> frontEndLatency + forwardLatency
In case the snoop filter is enabled, the request path latency is charged
also by look-up latency of the snoop filter.
--> frontEndLatency + SF(lookupLatency) + forwardLatency.
The latency of the response path through the xbar is set instead as
--> responseLatency.
In case of snoop response, if the response is treated as a normal response
the latency associated is again
--> responseLatency;
If instead it is forwarded as snoop response we add an additional variable
+ snoopResponseLatency
and the latency associated is
--> snoopResponseLatency;
Furthermore, this patch lets the crossbar progress on the next clock
edge after an unused retry, changing the time the crossbar considers
itself busy after sending a retry that was not acted upon.
2015-03-02 10:00:46 +01:00
|
|
|
|
|
|
|
# Lookup latency of the snoop filter, added to requests that pass
|
|
|
|
# through a coherent crossbar.
|
|
|
|
lookup_latency = Param.Cycles(1, "Lookup latency")
|
2014-09-20 23:18:26 +02:00
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
system = Param.System(Parent.any, "System that the crossbar belongs to.")
|
2015-03-02 10:00:47 +01:00
|
|
|
|
2015-09-25 13:26:57 +02:00
|
|
|
# Sanity check on max capacity to track, adjust if needed.
|
|
|
|
max_capacity = Param.MemorySize('8MB', "Maximum capacity of snoop filter")
|
|
|
|
|
2015-03-02 10:00:47 +01:00
|
|
|
# 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
|
|
|
|
|
2015-09-25 13:26:57 +02:00
|
|
|
# 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)
|
|
|
|
|
2015-03-02 10:00:47 +01:00
|
|
|
# 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
|