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
|
|
|
/*
|
2016-08-12 15:11:45 +02:00
|
|
|
* Copyright (c) 2011-2016 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) 2006 The Regents of The University of Michigan
|
|
|
|
* 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: Ali Saidi
|
|
|
|
* Andreas Hansson
|
|
|
|
* William Wang
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @file
|
2014-09-20 23:18:32 +02:00
|
|
|
* Definition of a crossbar object.
|
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
|
|
|
*/
|
|
|
|
|
|
|
|
#include "base/misc.hh"
|
|
|
|
#include "base/trace.hh"
|
2014-09-20 23:18:32 +02:00
|
|
|
#include "debug/AddrRanges.hh"
|
|
|
|
#include "debug/CoherentXBar.hh"
|
|
|
|
#include "mem/coherent_xbar.hh"
|
2013-02-15 23:40:09 +01:00
|
|
|
#include "sim/system.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
|
|
|
CoherentXBar::CoherentXBar(const CoherentXBarParams *p)
|
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
|
|
|
: BaseXBar(p), system(p->system), snoopFilter(p->snoop_filter),
|
2016-02-10 10:08:25 +01:00
|
|
|
snoopResponseLatency(p->snoop_response_latency),
|
|
|
|
pointOfCoherency(p->point_of_coherency)
|
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
|
|
|
{
|
|
|
|
// create the ports based on the size of the master and slave
|
|
|
|
// vector ports, and the presence of the default port, the ports
|
|
|
|
// are enumerated starting from zero
|
|
|
|
for (int i = 0; i < p->port_master_connection_count; ++i) {
|
2012-07-09 18:35:39 +02:00
|
|
|
std::string portName = csprintf("%s.master[%d]", name(), i);
|
2014-09-20 23:18:32 +02:00
|
|
|
MasterPort* bp = new CoherentXBarMasterPort(portName, *this, i);
|
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
|
|
|
masterPorts.push_back(bp);
|
2013-05-30 18:54:01 +02:00
|
|
|
reqLayers.push_back(new ReqLayer(*bp, *this,
|
|
|
|
csprintf(".reqLayer%d", i)));
|
2015-03-02 10:00:35 +01:00
|
|
|
snoopLayers.push_back(new SnoopRespLayer(*bp, *this,
|
|
|
|
csprintf(".snoopLayer%d", i)));
|
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
|
|
|
}
|
|
|
|
|
|
|
|
// see if we have a default slave device connected and if so add
|
|
|
|
// our corresponding master port
|
|
|
|
if (p->port_default_connection_count) {
|
|
|
|
defaultPortID = masterPorts.size();
|
2012-07-09 18:35:39 +02:00
|
|
|
std::string portName = name() + ".default";
|
2014-09-20 23:18:32 +02:00
|
|
|
MasterPort* bp = new CoherentXBarMasterPort(portName, *this,
|
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
|
|
|
defaultPortID);
|
|
|
|
masterPorts.push_back(bp);
|
2013-05-30 18:54:01 +02:00
|
|
|
reqLayers.push_back(new ReqLayer(*bp, *this, csprintf(".reqLayer%d",
|
|
|
|
defaultPortID)));
|
2015-03-02 10:00:35 +01:00
|
|
|
snoopLayers.push_back(new SnoopRespLayer(*bp, *this,
|
|
|
|
csprintf(".snoopLayer%d",
|
|
|
|
defaultPortID)));
|
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
|
|
|
}
|
|
|
|
|
|
|
|
// create the slave ports, once again starting at zero
|
|
|
|
for (int i = 0; i < p->port_slave_connection_count; ++i) {
|
2012-07-09 18:35:39 +02:00
|
|
|
std::string portName = csprintf("%s.slave[%d]", name(), i);
|
2015-07-03 16:14:44 +02:00
|
|
|
QueuedSlavePort* bp = new CoherentXBarSlavePort(portName, *this, i);
|
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
|
|
|
slavePorts.push_back(bp);
|
2013-05-30 18:54:01 +02:00
|
|
|
respLayers.push_back(new RespLayer(*bp, *this,
|
|
|
|
csprintf(".respLayer%d", i)));
|
2013-05-30 18:54:02 +02:00
|
|
|
snoopRespPorts.push_back(new SnoopRespPort(*bp, *this));
|
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
|
|
|
}
|
|
|
|
|
|
|
|
clearPortCache();
|
|
|
|
}
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::~CoherentXBar()
|
2013-05-30 18:54:01 +02:00
|
|
|
{
|
2014-09-20 23:18:32 +02:00
|
|
|
for (auto l: reqLayers)
|
|
|
|
delete l;
|
|
|
|
for (auto l: respLayers)
|
|
|
|
delete l;
|
|
|
|
for (auto l: snoopLayers)
|
|
|
|
delete l;
|
|
|
|
for (auto p: snoopRespPorts)
|
|
|
|
delete p;
|
2013-05-30 18:54:01 +02:00
|
|
|
}
|
|
|
|
|
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
|
|
|
void
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::init()
|
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
|
|
|
BaseXBar::init();
|
2012-10-11 12:38:43 +02:00
|
|
|
|
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
|
|
|
// iterate over our slave ports and determine which of our
|
|
|
|
// neighbouring master ports are snooping and add them as snoopers
|
2014-09-20 23:18:32 +02:00
|
|
|
for (const auto& p: slavePorts) {
|
2012-07-09 18:35:32 +02:00
|
|
|
// check if the connected master port is snooping
|
2014-09-20 23:18:32 +02:00
|
|
|
if (p->isSnooping()) {
|
|
|
|
DPRINTF(AddrRanges, "Adding snooping master %s\n",
|
|
|
|
p->getMasterPort().name());
|
|
|
|
snoopPorts.push_back(p);
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (snoopPorts.empty())
|
2014-09-20 23:18:32 +02:00
|
|
|
warn("CoherentXBar %s has no snooping ports attached!\n", name());
|
2015-09-25 13:26:57 +02:00
|
|
|
|
|
|
|
// inform the snoop filter about the slave ports so it can create
|
|
|
|
// its own internal representation
|
|
|
|
if (snoopFilter)
|
|
|
|
snoopFilter->setSlavePorts(slavePorts);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::recvTimingReq(PacketPtr pkt, PortID slave_port_id)
|
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
|
|
|
{
|
|
|
|
// determine the source port based on the id
|
|
|
|
SlavePort *src_port = slavePorts[slave_port_id];
|
|
|
|
|
Bus: Replace tickNextIdle and inRetry with a state variable
This patch adds a state enum and member variable in the bus, tracking
the bus state, thus eliminating the need for tickNextIdle and inRetry,
and fixing an issue that allowed the bus to be occupied by multiple
packets at once (hopefully it also makes it easier to understand the
code).
The bus, in its current form, uses tickNextIdle and inRetry to keep
track of the state of the bus. However, it only updates tickNextIdle
_after_ forwarding a packet using sendTiming, and the result is that
the bus is still seen as idle, and a module that receives the packet
and starts transmitting new packets in zero time will still see the
bus as idle (and this is done by a number of DMA devices). The issue
can also be seen in isOccupied where the bus calls reschedule on an
event instead of schedule.
This patch addresses the problem by marking the bus as _not_ idle
already by the time we conclude that the bus is not occupied and we
will deal with the packet.
As a result of not allowing multiple packets to occupy the bus, some
regressions have slight changes in their statistics. A separate patch
updates these accordingly.
Further ahead, a follow-on patch will introduce a separate state
variable for request/responses/snoop responses, and thus implement a
split request/response bus with separate flow control for the
different message types (even further ahead it will introduce a
multi-layer bus).
2012-07-09 18:35:35 +02:00
|
|
|
// remember if the packet is an express snoop
|
|
|
|
bool is_express_snoop = pkt->isExpressSnoop();
|
2015-12-31 15:32:58 +01:00
|
|
|
bool cache_responding = pkt->cacheResponding();
|
2015-01-22 11:01:14 +01:00
|
|
|
// for normal requests, going downstream, the express snoop flag
|
2015-12-31 15:32:58 +01:00
|
|
|
// and the cache responding flag should always be the same
|
|
|
|
assert(is_express_snoop == cache_responding);
|
Bus: Replace tickNextIdle and inRetry with a state variable
This patch adds a state enum and member variable in the bus, tracking
the bus state, thus eliminating the need for tickNextIdle and inRetry,
and fixing an issue that allowed the bus to be occupied by multiple
packets at once (hopefully it also makes it easier to understand the
code).
The bus, in its current form, uses tickNextIdle and inRetry to keep
track of the state of the bus. However, it only updates tickNextIdle
_after_ forwarding a packet using sendTiming, and the result is that
the bus is still seen as idle, and a module that receives the packet
and starts transmitting new packets in zero time will still see the
bus as idle (and this is done by a number of DMA devices). The issue
can also be seen in isOccupied where the bus calls reschedule on an
event instead of schedule.
This patch addresses the problem by marking the bus as _not_ idle
already by the time we conclude that the bus is not occupied and we
will deal with the packet.
As a result of not allowing multiple packets to occupy the bus, some
regressions have slight changes in their statistics. A separate patch
updates these accordingly.
Further ahead, a follow-on patch will introduce a separate state
variable for request/responses/snoop responses, and thus implement a
split request/response bus with separate flow control for the
different message types (even further ahead it will introduce a
multi-layer bus).
2012-07-09 18:35:35 +02:00
|
|
|
|
2013-03-26 19:46:47 +01:00
|
|
|
// determine the destination based on the address
|
2013-05-30 18:53:58 +02:00
|
|
|
PortID master_port_id = findPort(pkt->getAddr());
|
2013-03-26 19:46:47 +01:00
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
// test if the crossbar should be considered occupied for the current
|
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
|
|
|
// port, and exclude express snoops from the check
|
2013-05-30 18:54:01 +02:00
|
|
|
if (!is_express_snoop && !reqLayers[master_port_id]->tryTiming(src_port)) {
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "recvTimingReq: src %s %s 0x%x BUSY\n",
|
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
|
|
|
src_port->name(), pkt->cmdString(), pkt->getAddr());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "recvTimingReq: src %s %s expr %d 0x%x\n",
|
Bus: Replace tickNextIdle and inRetry with a state variable
This patch adds a state enum and member variable in the bus, tracking
the bus state, thus eliminating the need for tickNextIdle and inRetry,
and fixing an issue that allowed the bus to be occupied by multiple
packets at once (hopefully it also makes it easier to understand the
code).
The bus, in its current form, uses tickNextIdle and inRetry to keep
track of the state of the bus. However, it only updates tickNextIdle
_after_ forwarding a packet using sendTiming, and the result is that
the bus is still seen as idle, and a module that receives the packet
and starts transmitting new packets in zero time will still see the
bus as idle (and this is done by a number of DMA devices). The issue
can also be seen in isOccupied where the bus calls reschedule on an
event instead of schedule.
This patch addresses the problem by marking the bus as _not_ idle
already by the time we conclude that the bus is not occupied and we
will deal with the packet.
As a result of not allowing multiple packets to occupy the bus, some
regressions have slight changes in their statistics. A separate patch
updates these accordingly.
Further ahead, a follow-on patch will introduce a separate state
variable for request/responses/snoop responses, and thus implement a
split request/response bus with separate flow control for the
different message types (even further ahead it will introduce a
multi-layer bus).
2012-07-09 18:35:35 +02:00
|
|
|
src_port->name(), pkt->cmdString(), is_express_snoop,
|
|
|
|
pkt->getAddr());
|
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
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
// store size and command as they might be modified when
|
|
|
|
// forwarding the packet
|
|
|
|
unsigned int pkt_size = pkt->hasData() ? pkt->getSize() : 0;
|
|
|
|
unsigned int pkt_cmd = pkt->cmdToIndex();
|
|
|
|
|
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
|
|
|
// store the old header delay so we can restore it if needed
|
|
|
|
Tick old_header_delay = pkt->headerDelay;
|
|
|
|
|
|
|
|
// a request sees the frontend and forward latency
|
|
|
|
Tick xbar_delay = (frontendLatency + forwardLatency) * clockPeriod();
|
|
|
|
|
|
|
|
// set the packet header and payload delay
|
|
|
|
calcPacketTiming(pkt, xbar_delay);
|
|
|
|
|
|
|
|
// determine how long to be crossbar layer is busy
|
|
|
|
Tick packetFinishTime = clockEdge(Cycles(1)) + pkt->payloadDelay;
|
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
|
|
|
|
2015-05-05 09:22:29 +02:00
|
|
|
if (!system->bypassCaches()) {
|
2015-09-25 13:13:54 +02:00
|
|
|
assert(pkt->snoopDelay == 0);
|
|
|
|
|
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 packet is a memory-mapped request and should be
|
|
|
|
// broadcasted to our snoopers but the source
|
2014-09-20 23:18:29 +02:00
|
|
|
if (snoopFilter) {
|
|
|
|
// check with the snoop filter where to forward this packet
|
|
|
|
auto sf_res = snoopFilter->lookupRequest(pkt, *src_port);
|
2015-09-25 12:45:52 +02:00
|
|
|
// the time required by a packet to be delivered through
|
|
|
|
// the xbar has to be charged also with to lookup latency
|
|
|
|
// of the snoop filter
|
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
|
|
|
pkt->headerDelay += sf_res.second * clockPeriod();
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "recvTimingReq: src %s %s 0x%x"\
|
2014-09-20 23:18:29 +02:00
|
|
|
" SF size: %i lat: %i\n", src_port->name(),
|
|
|
|
pkt->cmdString(), pkt->getAddr(), sf_res.first.size(),
|
|
|
|
sf_res.second);
|
2015-11-06 09:26:40 +01:00
|
|
|
|
mem: Add an option to perform clean writebacks from caches
This patch adds the necessary commands and cache functionality to
allow clean writebacks. This functionality is crucial, especially when
having exclusive (victim) caches. For example, if read-only L1
instruction caches are not sending clean writebacks, there will never
be any spills from the L1 to the L2. At the moment the cache model
defaults to not sending clean writebacks, and this should possibly be
re-evaluated.
The implementation of clean writebacks relies on a new packet command
WritebackClean, which acts much like a Writeback (renamed
WritebackDirty), and also much like a CleanEvict. On eviction of a
clean block the cache either sends a clean evict, or a clean
writeback, and if any copies are still cached upstream the clean
evict/writeback is dropped. Similarly, if a clean evict/writeback
reaches a cache where there are outstanding MSHRs for the block, the
packet is dropped. In the typical case though, the clean writeback
allocates a block in the downstream cache, and marks it writable if
the evicted block was writable.
The patch changes the O3_ARM_v7a L1 cache configuration and the
default L1 caches in config/common/Caches.py
2015-11-06 09:26:43 +01:00
|
|
|
if (pkt->isEviction()) {
|
2015-11-06 09:26:40 +01:00
|
|
|
// for block-evicting packets, i.e. writebacks and
|
|
|
|
// clean evictions, there is no need to snoop up, as
|
|
|
|
// all we do is determine if the block is cached or
|
|
|
|
// not, instead just set it here based on the snoop
|
|
|
|
// filter result
|
|
|
|
if (!sf_res.first.empty())
|
|
|
|
pkt->setBlockCached();
|
|
|
|
} else {
|
|
|
|
forwardTiming(pkt, slave_port_id, sf_res.first);
|
|
|
|
}
|
2014-09-20 23:18:29 +02:00
|
|
|
} else {
|
|
|
|
forwardTiming(pkt, slave_port_id);
|
|
|
|
}
|
2015-09-25 13:13:54 +02:00
|
|
|
|
|
|
|
// add the snoop delay to our header delay, and then reset it
|
|
|
|
pkt->headerDelay += pkt->snoopDelay;
|
|
|
|
pkt->snoopDelay = 0;
|
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
|
|
|
}
|
|
|
|
|
2016-02-10 10:08:25 +01:00
|
|
|
// set up a sensible starting point
|
|
|
|
bool success = true;
|
2015-07-03 16:14:37 +02:00
|
|
|
|
2015-12-31 15:32:58 +01:00
|
|
|
// remember if the packet will generate a snoop response by
|
|
|
|
// checking if a cache set the cacheResponding flag during the
|
|
|
|
// snooping above
|
|
|
|
const bool expect_snoop_resp = !cache_responding && pkt->cacheResponding();
|
2016-02-10 10:08:25 +01:00
|
|
|
bool expect_response = pkt->needsResponse() && !pkt->cacheResponding();
|
|
|
|
|
|
|
|
const bool sink_packet = sinkPacket(pkt);
|
|
|
|
|
|
|
|
// in certain cases the crossbar is responsible for responding
|
|
|
|
bool respond_directly = false;
|
2016-06-20 16:11:18 +02:00
|
|
|
// store the original address as an address mapper could possibly
|
|
|
|
// modify the address upon a sendTimingRequest
|
|
|
|
const Addr addr(pkt->getAddr());
|
2016-02-10 10:08:25 +01:00
|
|
|
if (sink_packet) {
|
|
|
|
DPRINTF(CoherentXBar, "Not forwarding %s to %#llx\n",
|
|
|
|
pkt->cmdString(), pkt->getAddr());
|
|
|
|
} else {
|
|
|
|
// determine if we are forwarding the packet, or responding to
|
|
|
|
// it
|
|
|
|
if (!pointOfCoherency || pkt->isRead() || pkt->isWrite()) {
|
|
|
|
// if we are passing on, rather than sinking, a packet to
|
|
|
|
// which an upstream cache has committed to responding,
|
|
|
|
// the line was needs writable, and the responding only
|
|
|
|
// had an Owned copy, so we need to immidiately let the
|
|
|
|
// downstream caches know, bypass any flow control
|
|
|
|
if (pkt->cacheResponding()) {
|
|
|
|
pkt->setExpressSnoop();
|
|
|
|
}
|
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
|
|
|
|
2016-02-10 10:08:25 +01:00
|
|
|
// since it is a normal request, attempt to send the packet
|
|
|
|
success = masterPorts[master_port_id]->sendTimingReq(pkt);
|
|
|
|
} else {
|
|
|
|
// no need to forward, turn this packet around and respond
|
|
|
|
// directly
|
|
|
|
assert(pkt->needsResponse());
|
|
|
|
|
|
|
|
respond_directly = true;
|
|
|
|
assert(!expect_snoop_resp);
|
|
|
|
expect_response = false;
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
|
2015-05-05 09:22:29 +02:00
|
|
|
if (snoopFilter && !system->bypassCaches()) {
|
2014-09-20 23:18:29 +02:00
|
|
|
// Let the snoop filter know about the success of the send operation
|
2016-08-12 15:11:45 +02:00
|
|
|
snoopFilter->finishRequest(!success, addr, pkt->isSecure());
|
2014-09-20 23:18:29 +02:00
|
|
|
}
|
|
|
|
|
2015-01-22 11:01:14 +01:00
|
|
|
// check if we were successful in sending the packet onwards
|
|
|
|
if (!success) {
|
2015-12-31 15:32:58 +01:00
|
|
|
// express snoops should never be forced to retry
|
2015-01-22 11:01:14 +01:00
|
|
|
assert(!is_express_snoop);
|
Bus: Replace tickNextIdle and inRetry with a state variable
This patch adds a state enum and member variable in the bus, tracking
the bus state, thus eliminating the need for tickNextIdle and inRetry,
and fixing an issue that allowed the bus to be occupied by multiple
packets at once (hopefully it also makes it easier to understand the
code).
The bus, in its current form, uses tickNextIdle and inRetry to keep
track of the state of the bus. However, it only updates tickNextIdle
_after_ forwarding a packet using sendTiming, and the result is that
the bus is still seen as idle, and a module that receives the packet
and starts transmitting new packets in zero time will still see the
bus as idle (and this is done by a number of DMA devices). The issue
can also be seen in isOccupied where the bus calls reschedule on an
event instead of schedule.
This patch addresses the problem by marking the bus as _not_ idle
already by the time we conclude that the bus is not occupied and we
will deal with the packet.
As a result of not allowing multiple packets to occupy the bus, some
regressions have slight changes in their statistics. A separate patch
updates these accordingly.
Further ahead, a follow-on patch will introduce a separate state
variable for request/responses/snoop responses, and thus implement a
split request/response bus with separate flow control for the
different message types (even further ahead it will introduce a
multi-layer bus).
2012-07-09 18:35:35 +02: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
|
|
|
// restore the header delay
|
|
|
|
pkt->headerDelay = old_header_delay;
|
Bus: Replace tickNextIdle and inRetry with a state variable
This patch adds a state enum and member variable in the bus, tracking
the bus state, thus eliminating the need for tickNextIdle and inRetry,
and fixing an issue that allowed the bus to be occupied by multiple
packets at once (hopefully it also makes it easier to understand the
code).
The bus, in its current form, uses tickNextIdle and inRetry to keep
track of the state of the bus. However, it only updates tickNextIdle
_after_ forwarding a packet using sendTiming, and the result is that
the bus is still seen as idle, and a module that receives the packet
and starts transmitting new packets in zero time will still see the
bus as idle (and this is done by a number of DMA devices). The issue
can also be seen in isOccupied where the bus calls reschedule on an
event instead of schedule.
This patch addresses the problem by marking the bus as _not_ idle
already by the time we conclude that the bus is not occupied and we
will deal with the packet.
As a result of not allowing multiple packets to occupy the bus, some
regressions have slight changes in their statistics. A separate patch
updates these accordingly.
Further ahead, a follow-on patch will introduce a separate state
variable for request/responses/snoop responses, and thus implement a
split request/response bus with separate flow control for the
different message types (even further ahead it will introduce a
multi-layer bus).
2012-07-09 18:35:35 +02:00
|
|
|
|
2015-01-22 11:01:14 +01:00
|
|
|
DPRINTF(CoherentXBar, "recvTimingReq: src %s %s 0x%x RETRY\n",
|
|
|
|
src_port->name(), pkt->cmdString(), pkt->getAddr());
|
2013-02-19 11:56:06 +01:00
|
|
|
|
2015-01-22 11:01:14 +01:00
|
|
|
// update the layer state and schedule an idle event
|
|
|
|
reqLayers[master_port_id]->failedTiming(src_port,
|
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
|
|
|
clockEdge(Cycles(1)));
|
2015-01-22 11:01:14 +01:00
|
|
|
} else {
|
|
|
|
// express snoops currently bypass the crossbar state entirely
|
|
|
|
if (!is_express_snoop) {
|
|
|
|
// if this particular request will generate a snoop
|
|
|
|
// response
|
|
|
|
if (expect_snoop_resp) {
|
|
|
|
// we should never have an exsiting request outstanding
|
|
|
|
assert(outstandingSnoop.find(pkt->req) ==
|
|
|
|
outstandingSnoop.end());
|
|
|
|
outstandingSnoop.insert(pkt->req);
|
|
|
|
|
|
|
|
// basic sanity check on the outstanding snoops
|
|
|
|
panic_if(outstandingSnoop.size() > 512,
|
|
|
|
"Outstanding snoop requests exceeded 512\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
// remember where to route the normal response to
|
|
|
|
if (expect_response || expect_snoop_resp) {
|
|
|
|
assert(routeTo.find(pkt->req) == routeTo.end());
|
|
|
|
routeTo[pkt->req] = slave_port_id;
|
|
|
|
|
|
|
|
panic_if(routeTo.size() > 512,
|
|
|
|
"Routing table exceeds 512 packets\n");
|
|
|
|
}
|
Bus: Replace tickNextIdle and inRetry with a state variable
This patch adds a state enum and member variable in the bus, tracking
the bus state, thus eliminating the need for tickNextIdle and inRetry,
and fixing an issue that allowed the bus to be occupied by multiple
packets at once (hopefully it also makes it easier to understand the
code).
The bus, in its current form, uses tickNextIdle and inRetry to keep
track of the state of the bus. However, it only updates tickNextIdle
_after_ forwarding a packet using sendTiming, and the result is that
the bus is still seen as idle, and a module that receives the packet
and starts transmitting new packets in zero time will still see the
bus as idle (and this is done by a number of DMA devices). The issue
can also be seen in isOccupied where the bus calls reschedule on an
event instead of schedule.
This patch addresses the problem by marking the bus as _not_ idle
already by the time we conclude that the bus is not occupied and we
will deal with the packet.
As a result of not allowing multiple packets to occupy the bus, some
regressions have slight changes in their statistics. A separate patch
updates these accordingly.
Further ahead, a follow-on patch will introduce a separate state
variable for request/responses/snoop responses, and thus implement a
split request/response bus with separate flow control for the
different message types (even further ahead it will introduce a
multi-layer bus).
2012-07-09 18:35:35 +02:00
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
// update the layer state and schedule an idle event
|
2013-05-30 18:54:01 +02:00
|
|
|
reqLayers[master_port_id]->succeededTiming(packetFinishTime);
|
Bus: Replace tickNextIdle and inRetry with a state variable
This patch adds a state enum and member variable in the bus, tracking
the bus state, thus eliminating the need for tickNextIdle and inRetry,
and fixing an issue that allowed the bus to be occupied by multiple
packets at once (hopefully it also makes it easier to understand the
code).
The bus, in its current form, uses tickNextIdle and inRetry to keep
track of the state of the bus. However, it only updates tickNextIdle
_after_ forwarding a packet using sendTiming, and the result is that
the bus is still seen as idle, and a module that receives the packet
and starts transmitting new packets in zero time will still see the
bus as idle (and this is done by a number of DMA devices). The issue
can also be seen in isOccupied where the bus calls reschedule on an
event instead of schedule.
This patch addresses the problem by marking the bus as _not_ idle
already by the time we conclude that the bus is not occupied and we
will deal with the packet.
As a result of not allowing multiple packets to occupy the bus, some
regressions have slight changes in their statistics. A separate patch
updates these accordingly.
Further ahead, a follow-on patch will introduce a separate state
variable for request/responses/snoop responses, and thus implement a
split request/response bus with separate flow control for the
different message types (even further ahead it will introduce a
multi-layer bus).
2012-07-09 18:35:35 +02:00
|
|
|
}
|
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
|
|
|
|
2015-01-22 11:01:14 +01:00
|
|
|
// stats updates only consider packets that were successfully sent
|
2013-05-30 18:53:58 +02:00
|
|
|
pktCount[slave_port_id][master_port_id]++;
|
2014-09-20 23:18:32 +02:00
|
|
|
pktSize[slave_port_id][master_port_id] += pkt_size;
|
2013-05-30 18:53:58 +02:00
|
|
|
transDist[pkt_cmd]++;
|
2015-01-22 11:01:14 +01:00
|
|
|
|
2016-07-21 18:19:14 +02:00
|
|
|
if (is_express_snoop) {
|
2015-01-22 11:01:14 +01:00
|
|
|
snoops++;
|
2016-07-21 18:19:14 +02:00
|
|
|
snoopTraffic += pkt_size;
|
|
|
|
}
|
2013-05-30 18:53:58 +02:00
|
|
|
}
|
|
|
|
|
2016-02-10 10:08:25 +01:00
|
|
|
if (sink_packet)
|
|
|
|
// queue the packet for deletion
|
|
|
|
pendingDelete.reset(pkt);
|
|
|
|
|
|
|
|
if (respond_directly) {
|
|
|
|
assert(pkt->needsResponse());
|
|
|
|
assert(success);
|
|
|
|
|
|
|
|
pkt->makeResponse();
|
|
|
|
|
|
|
|
if (snoopFilter && !system->bypassCaches()) {
|
|
|
|
// let the snoop filter inspect the response and update its state
|
|
|
|
snoopFilter->updateResponse(pkt, *slavePorts[slave_port_id]);
|
|
|
|
}
|
|
|
|
|
|
|
|
Tick response_time = clockEdge() + pkt->headerDelay;
|
|
|
|
pkt->headerDelay = 0;
|
|
|
|
|
|
|
|
slavePorts[slave_port_id]->schedTimingResp(pkt, response_time);
|
|
|
|
}
|
|
|
|
|
Bus: Replace tickNextIdle and inRetry with a state variable
This patch adds a state enum and member variable in the bus, tracking
the bus state, thus eliminating the need for tickNextIdle and inRetry,
and fixing an issue that allowed the bus to be occupied by multiple
packets at once (hopefully it also makes it easier to understand the
code).
The bus, in its current form, uses tickNextIdle and inRetry to keep
track of the state of the bus. However, it only updates tickNextIdle
_after_ forwarding a packet using sendTiming, and the result is that
the bus is still seen as idle, and a module that receives the packet
and starts transmitting new packets in zero time will still see the
bus as idle (and this is done by a number of DMA devices). The issue
can also be seen in isOccupied where the bus calls reschedule on an
event instead of schedule.
This patch addresses the problem by marking the bus as _not_ idle
already by the time we conclude that the bus is not occupied and we
will deal with the packet.
As a result of not allowing multiple packets to occupy the bus, some
regressions have slight changes in their statistics. A separate patch
updates these accordingly.
Further ahead, a follow-on patch will introduce a separate state
variable for request/responses/snoop responses, and thus implement a
split request/response bus with separate flow control for the
different message types (even further ahead it will introduce a
multi-layer bus).
2012-07-09 18:35:35 +02:00
|
|
|
return success;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::recvTimingResp(PacketPtr pkt, PortID master_port_id)
|
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
|
|
|
{
|
|
|
|
// determine the source port based on the id
|
|
|
|
MasterPort *src_port = masterPorts[master_port_id];
|
|
|
|
|
2015-01-22 11:01:14 +01:00
|
|
|
// determine the destination
|
|
|
|
const auto route_lookup = routeTo.find(pkt->req);
|
|
|
|
assert(route_lookup != routeTo.end());
|
|
|
|
const PortID slave_port_id = route_lookup->second;
|
2014-12-02 12:07:56 +01:00
|
|
|
assert(slave_port_id != InvalidPortID);
|
|
|
|
assert(slave_port_id < respLayers.size());
|
2013-05-30 18:53:59 +02:00
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
// test if the crossbar should be considered occupied for the
|
|
|
|
// current port
|
2013-05-30 18:54:01 +02:00
|
|
|
if (!respLayers[slave_port_id]->tryTiming(src_port)) {
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "recvTimingResp: src %s %s 0x%x BUSY\n",
|
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
|
|
|
src_port->name(), pkt->cmdString(), pkt->getAddr());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "recvTimingResp: src %s %s 0x%x\n",
|
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
|
|
|
src_port->name(), pkt->cmdString(), pkt->getAddr());
|
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
// store size and command as they might be modified when
|
|
|
|
// forwarding the packet
|
|
|
|
unsigned int pkt_size = pkt->hasData() ? pkt->getSize() : 0;
|
|
|
|
unsigned int pkt_cmd = pkt->cmdToIndex();
|
|
|
|
|
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
|
|
|
// a response sees the response latency
|
|
|
|
Tick xbar_delay = responseLatency * clockPeriod();
|
|
|
|
|
|
|
|
// set the packet header and payload delay
|
|
|
|
calcPacketTiming(pkt, xbar_delay);
|
|
|
|
|
|
|
|
// determine how long to be crossbar layer is busy
|
|
|
|
Tick packetFinishTime = clockEdge(Cycles(1)) + pkt->payloadDelay;
|
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
|
|
|
|
2015-05-05 09:22:29 +02:00
|
|
|
if (snoopFilter && !system->bypassCaches()) {
|
2014-09-20 23:18:29 +02:00
|
|
|
// let the snoop filter inspect the response and update its state
|
|
|
|
snoopFilter->updateResponse(pkt, *slavePorts[slave_port_id]);
|
|
|
|
}
|
|
|
|
|
2015-07-03 16:14:44 +02:00
|
|
|
// send the packet through the destination slave port and pay for
|
|
|
|
// any outstanding header delay
|
|
|
|
Tick latency = pkt->headerDelay;
|
|
|
|
pkt->headerDelay = 0;
|
|
|
|
slavePorts[slave_port_id]->schedTimingResp(pkt, curTick() + latency);
|
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
|
|
|
|
2015-01-22 11:01:14 +01:00
|
|
|
// remove the request from the routing table
|
|
|
|
routeTo.erase(route_lookup);
|
|
|
|
|
2013-05-30 18:54:01 +02:00
|
|
|
respLayers[slave_port_id]->succeededTiming(packetFinishTime);
|
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
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
// stats updates
|
|
|
|
pktCount[slave_port_id][master_port_id]++;
|
2014-09-20 23:18:32 +02:00
|
|
|
pktSize[slave_port_id][master_port_id] += pkt_size;
|
2013-05-30 18:53:58 +02:00
|
|
|
transDist[pkt_cmd]++;
|
|
|
|
|
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
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::recvTimingSnoopReq(PacketPtr pkt, PortID master_port_id)
|
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
|
|
|
DPRINTF(CoherentXBar, "recvTimingSnoopReq: src %s %s 0x%x\n",
|
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
|
|
|
masterPorts[master_port_id]->name(), pkt->cmdString(),
|
|
|
|
pkt->getAddr());
|
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
// update stats here as we know the forwarding will succeed
|
2016-07-21 18:19:14 +02:00
|
|
|
unsigned int pkt_size = pkt->hasData() ? pkt->getSize() : 0;
|
2013-05-30 18:53:58 +02:00
|
|
|
transDist[pkt->cmdToIndex()]++;
|
2014-09-20 23:18:32 +02:00
|
|
|
snoops++;
|
2016-07-21 18:19:14 +02:00
|
|
|
snoopTraffic += pkt_size;
|
2013-05-30 18:53:58 +02:00
|
|
|
|
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
|
|
|
// we should only see express snoops from caches
|
|
|
|
assert(pkt->isExpressSnoop());
|
|
|
|
|
2015-09-25 13:13:54 +02:00
|
|
|
// set the packet header and payload delay, for now use forward latency
|
|
|
|
// @todo Assess the choice of latency further
|
|
|
|
calcPacketTiming(pkt, forwardLatency * clockPeriod());
|
|
|
|
|
2015-12-31 15:32:58 +01:00
|
|
|
// remember if a cache has already committed to responding so we
|
|
|
|
// can see if it changes during the snooping
|
|
|
|
const bool cache_responding = pkt->cacheResponding();
|
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
|
|
|
|
2015-09-25 13:13:54 +02:00
|
|
|
assert(pkt->snoopDelay == 0);
|
|
|
|
|
2014-09-20 23:18:29 +02:00
|
|
|
if (snoopFilter) {
|
|
|
|
// let the Snoop Filter work its magic and guide probing
|
|
|
|
auto sf_res = snoopFilter->lookupSnoop(pkt);
|
2015-09-25 12:45:52 +02:00
|
|
|
// the time required by a packet to be delivered through
|
|
|
|
// the xbar has to be charged also with to lookup latency
|
|
|
|
// of the snoop filter
|
|
|
|
pkt->headerDelay += sf_res.second * clockPeriod();
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "recvTimingSnoopReq: src %s %s 0x%x"\
|
2014-09-20 23:18:29 +02:00
|
|
|
" SF size: %i lat: %i\n", masterPorts[master_port_id]->name(),
|
|
|
|
pkt->cmdString(), pkt->getAddr(), sf_res.first.size(),
|
|
|
|
sf_res.second);
|
|
|
|
|
|
|
|
// forward to all snoopers
|
|
|
|
forwardTiming(pkt, InvalidPortID, sf_res.first);
|
|
|
|
} else {
|
|
|
|
forwardTiming(pkt, InvalidPortID);
|
|
|
|
}
|
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
|
|
|
|
2015-09-25 13:13:54 +02:00
|
|
|
// add the snoop delay to our header delay, and then reset it
|
|
|
|
pkt->headerDelay += pkt->snoopDelay;
|
|
|
|
pkt->snoopDelay = 0;
|
|
|
|
|
2015-01-22 11:01:14 +01:00
|
|
|
// if we can expect a response, remember how to route it
|
2015-12-31 15:32:58 +01:00
|
|
|
if (!cache_responding && pkt->cacheResponding()) {
|
2015-01-22 11:01:14 +01:00
|
|
|
assert(routeTo.find(pkt->req) == routeTo.end());
|
|
|
|
routeTo[pkt->req] = master_port_id;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// a snoop request came from a connected slave device (one of
|
|
|
|
// our master ports), and if it is not coming from the slave
|
|
|
|
// device responsible for the address range something is
|
|
|
|
// wrong, hence there is nothing further to do as the packet
|
|
|
|
// would be going back to where it came from
|
|
|
|
assert(master_port_id == findPort(pkt->getAddr()));
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::recvTimingSnoopResp(PacketPtr pkt, PortID slave_port_id)
|
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
|
|
|
{
|
|
|
|
// determine the source port based on the id
|
|
|
|
SlavePort* src_port = slavePorts[slave_port_id];
|
|
|
|
|
2015-01-22 11:01:14 +01:00
|
|
|
// get the destination
|
|
|
|
const auto route_lookup = routeTo.find(pkt->req);
|
|
|
|
assert(route_lookup != routeTo.end());
|
|
|
|
const PortID dest_port_id = route_lookup->second;
|
2014-12-02 12:07:56 +01:00
|
|
|
assert(dest_port_id != InvalidPortID);
|
2013-05-30 18:54:00 +02:00
|
|
|
|
|
|
|
// determine if the response is from a snoop request we
|
|
|
|
// created as the result of a normal request (in which case it
|
2015-01-22 11:01:14 +01:00
|
|
|
// should be in the outstandingSnoop), or if we merely forwarded
|
2013-05-30 18:54:00 +02:00
|
|
|
// someone else's snoop request
|
2015-01-22 11:01:14 +01:00
|
|
|
const bool forwardAsSnoop = outstandingSnoop.find(pkt->req) ==
|
|
|
|
outstandingSnoop.end();
|
2013-05-30 18:54:00 +02:00
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
// test if the crossbar should be considered occupied for the
|
|
|
|
// current port, note that the check is bypassed if the response
|
|
|
|
// is being passed on as a normal response since this is occupying
|
|
|
|
// the response layer rather than the snoop response layer
|
2013-05-30 18:54:01 +02:00
|
|
|
if (forwardAsSnoop) {
|
2014-12-02 12:07:56 +01:00
|
|
|
assert(dest_port_id < snoopLayers.size());
|
2013-05-30 18:54:01 +02:00
|
|
|
if (!snoopLayers[dest_port_id]->tryTiming(src_port)) {
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "recvTimingSnoopResp: src %s %s 0x%x BUSY\n",
|
2013-05-30 18:54:01 +02:00
|
|
|
src_port->name(), pkt->cmdString(), pkt->getAddr());
|
|
|
|
return false;
|
|
|
|
}
|
2013-05-30 18:54:02 +02:00
|
|
|
} else {
|
|
|
|
// get the master port that mirrors this slave port internally
|
|
|
|
MasterPort* snoop_port = snoopRespPorts[slave_port_id];
|
2014-12-02 12:07:56 +01:00
|
|
|
assert(dest_port_id < respLayers.size());
|
2013-05-30 18:54:02 +02:00
|
|
|
if (!respLayers[dest_port_id]->tryTiming(snoop_port)) {
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "recvTimingSnoopResp: src %s %s 0x%x BUSY\n",
|
2013-05-30 18:54:02 +02:00
|
|
|
snoop_port->name(), pkt->cmdString(), pkt->getAddr());
|
|
|
|
return false;
|
|
|
|
}
|
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
|
|
|
DPRINTF(CoherentXBar, "recvTimingSnoopResp: src %s %s 0x%x\n",
|
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
|
|
|
src_port->name(), pkt->cmdString(), pkt->getAddr());
|
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
// store size and command as they might be modified when
|
|
|
|
// forwarding the packet
|
|
|
|
unsigned int pkt_size = pkt->hasData() ? pkt->getSize() : 0;
|
|
|
|
unsigned int pkt_cmd = pkt->cmdToIndex();
|
|
|
|
|
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
|
|
|
// responses are never express snoops
|
|
|
|
assert(!pkt->isExpressSnoop());
|
|
|
|
|
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
|
|
|
// a snoop response sees the snoop response latency, and if it is
|
|
|
|
// forwarded as a normal response, the response latency
|
|
|
|
Tick xbar_delay =
|
|
|
|
(forwardAsSnoop ? snoopResponseLatency : responseLatency) *
|
|
|
|
clockPeriod();
|
|
|
|
|
|
|
|
// set the packet header and payload delay
|
|
|
|
calcPacketTiming(pkt, xbar_delay);
|
|
|
|
|
|
|
|
// determine how long to be crossbar layer is busy
|
|
|
|
Tick packetFinishTime = clockEdge(Cycles(1)) + pkt->payloadDelay;
|
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
|
|
|
|
2013-05-30 18:54:00 +02:00
|
|
|
// forward it either as a snoop response or a normal response
|
|
|
|
if (forwardAsSnoop) {
|
|
|
|
// this is a snoop response to a snoop request we forwarded,
|
|
|
|
// e.g. coming from the L1 and going to the L2, and it should
|
|
|
|
// be forwarded as a snoop response
|
2014-09-20 23:18:29 +02:00
|
|
|
|
|
|
|
if (snoopFilter) {
|
|
|
|
// update the probe filter so that it can properly track the line
|
|
|
|
snoopFilter->updateSnoopForward(pkt, *slavePorts[slave_port_id],
|
|
|
|
*masterPorts[dest_port_id]);
|
|
|
|
}
|
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
bool success M5_VAR_USED =
|
|
|
|
masterPorts[dest_port_id]->sendTimingSnoopResp(pkt);
|
|
|
|
pktCount[slave_port_id][dest_port_id]++;
|
2014-09-20 23:18:32 +02:00
|
|
|
pktSize[slave_port_id][dest_port_id] += pkt_size;
|
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
|
|
|
assert(success);
|
2013-05-30 18:54:00 +02:00
|
|
|
|
2013-05-30 18:54:01 +02:00
|
|
|
snoopLayers[dest_port_id]->succeededTiming(packetFinishTime);
|
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
|
|
|
} else {
|
|
|
|
// we got a snoop response on one of our slave ports,
|
2014-09-20 23:18:32 +02:00
|
|
|
// i.e. from a coherent master connected to the crossbar, and
|
|
|
|
// since we created the snoop request as part of recvTiming,
|
|
|
|
// this should now be a normal response again
|
2015-01-22 11:01:14 +01:00
|
|
|
outstandingSnoop.erase(pkt->req);
|
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
|
|
|
|
2015-01-22 11:01:14 +01:00
|
|
|
// this is a snoop response from a coherent master, hence it
|
|
|
|
// should never go back to where the snoop response came from,
|
|
|
|
// but instead to where the original request came from
|
2013-05-30 18:53:58 +02:00
|
|
|
assert(slave_port_id != dest_port_id);
|
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:29 +02:00
|
|
|
if (snoopFilter) {
|
|
|
|
// update the probe filter so that it can properly track the line
|
|
|
|
snoopFilter->updateSnoopResponse(pkt, *slavePorts[slave_port_id],
|
|
|
|
*slavePorts[dest_port_id]);
|
|
|
|
}
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "recvTimingSnoopResp: src %s %s 0x%x"\
|
2014-09-20 23:18:29 +02:00
|
|
|
" FWD RESP\n", src_port->name(), pkt->cmdString(),
|
|
|
|
pkt->getAddr());
|
|
|
|
|
2013-05-30 18:54:00 +02:00
|
|
|
// as a normal response, it should go back to a master through
|
2015-07-03 16:14:44 +02:00
|
|
|
// one of our slave ports, we also pay for any outstanding
|
|
|
|
// header latency
|
|
|
|
Tick latency = pkt->headerDelay;
|
|
|
|
pkt->headerDelay = 0;
|
|
|
|
slavePorts[dest_port_id]->schedTimingResp(pkt, curTick() + latency);
|
2013-05-30 18:54:02 +02:00
|
|
|
|
|
|
|
respLayers[dest_port_id]->succeededTiming(packetFinishTime);
|
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
|
|
|
}
|
|
|
|
|
2015-01-22 11:01:14 +01:00
|
|
|
// remove the request from the routing table
|
|
|
|
routeTo.erase(route_lookup);
|
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
// stats updates
|
|
|
|
transDist[pkt_cmd]++;
|
2014-09-20 23:18:32 +02:00
|
|
|
snoops++;
|
2016-07-21 18:19:14 +02:00
|
|
|
snoopTraffic += pkt_size;
|
2013-05-30 18:53:58 +02:00
|
|
|
|
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
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::forwardTiming(PacketPtr pkt, PortID exclude_slave_port_id,
|
2015-07-03 16:14:44 +02:00
|
|
|
const std::vector<QueuedSlavePort*>& dests)
|
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
|
|
|
DPRINTF(CoherentXBar, "%s for %s address %x size %d\n", __func__,
|
2013-04-22 19:20:33 +02:00
|
|
|
pkt->cmdString(), pkt->getAddr(), pkt->getSize());
|
|
|
|
|
2013-02-15 23:40:09 +01:00
|
|
|
// snoops should only happen if the system isn't bypassing caches
|
|
|
|
assert(!system->bypassCaches());
|
|
|
|
|
2014-04-24 14:28:47 +02:00
|
|
|
unsigned fanout = 0;
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
for (const auto& p: dests) {
|
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
|
|
|
// we could have gotten this request from a snooping master
|
|
|
|
// (corresponding to our own slave port that is also in
|
|
|
|
// snoopPorts) and should not send it back to where it came
|
|
|
|
// from
|
|
|
|
if (exclude_slave_port_id == InvalidPortID ||
|
|
|
|
p->getId() != exclude_slave_port_id) {
|
|
|
|
// cache is not allowed to refuse snoop
|
|
|
|
p->sendTimingSnoopReq(pkt);
|
2014-04-24 14:28:47 +02:00
|
|
|
fanout++;
|
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-04-24 14:28:47 +02:00
|
|
|
|
|
|
|
// Stats for fanout of this forward operation
|
|
|
|
snoopFanout.sample(fanout);
|
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
|
|
|
}
|
|
|
|
|
2012-07-09 18:35:36 +02:00
|
|
|
void
|
2015-03-02 10:00:35 +01:00
|
|
|
CoherentXBar::recvReqRetry(PortID master_port_id)
|
2012-07-09 18:35:36 +02:00
|
|
|
{
|
2012-07-09 18:35:37 +02:00
|
|
|
// responses and snoop responses never block on forwarding them,
|
|
|
|
// so the retry will always be coming from a port to which we
|
|
|
|
// tried to forward a request
|
2013-05-30 18:54:01 +02:00
|
|
|
reqLayers[master_port_id]->recvRetry();
|
2012-07-09 18:35:36 +02:00
|
|
|
}
|
|
|
|
|
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
|
|
|
Tick
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::recvAtomic(PacketPtr pkt, PortID slave_port_id)
|
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
|
|
|
DPRINTF(CoherentXBar, "recvAtomic: packet src %s addr 0x%x cmd %s\n",
|
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
|
|
|
slavePorts[slave_port_id]->name(), pkt->getAddr(),
|
|
|
|
pkt->cmdString());
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
unsigned int pkt_size = pkt->hasData() ? pkt->getSize() : 0;
|
|
|
|
unsigned int pkt_cmd = pkt->cmdToIndex();
|
2013-05-30 18:53:58 +02:00
|
|
|
|
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
|
|
|
MemCmd snoop_response_cmd = MemCmd::InvalidCmd;
|
|
|
|
Tick snoop_response_latency = 0;
|
|
|
|
|
2015-05-05 09:22:29 +02:00
|
|
|
if (!system->bypassCaches()) {
|
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
|
|
|
// forward to all snoopers but the source
|
2014-09-20 23:18:29 +02:00
|
|
|
std::pair<MemCmd, Tick> snoop_result;
|
|
|
|
if (snoopFilter) {
|
|
|
|
// check with the snoop filter where to forward this packet
|
|
|
|
auto sf_res =
|
|
|
|
snoopFilter->lookupRequest(pkt, *slavePorts[slave_port_id]);
|
|
|
|
snoop_response_latency += sf_res.second * clockPeriod();
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "%s: src %s %s 0x%x"\
|
2014-09-20 23:18:29 +02:00
|
|
|
" SF size: %i lat: %i\n", __func__,
|
|
|
|
slavePorts[slave_port_id]->name(), pkt->cmdString(),
|
|
|
|
pkt->getAddr(), sf_res.first.size(), sf_res.second);
|
2015-09-25 13:26:57 +02:00
|
|
|
|
|
|
|
// let the snoop filter know about the success of the send
|
|
|
|
// operation, and do it even before sending it onwards to
|
|
|
|
// avoid situations where atomic upward snoops sneak in
|
|
|
|
// between and change the filter state
|
2016-08-12 15:11:45 +02:00
|
|
|
snoopFilter->finishRequest(false, pkt->getAddr(), pkt->isSecure());
|
2015-09-25 13:26:57 +02:00
|
|
|
|
2014-09-20 23:18:29 +02:00
|
|
|
snoop_result = forwardAtomic(pkt, slave_port_id, InvalidPortID,
|
|
|
|
sf_res.first);
|
|
|
|
} else {
|
|
|
|
snoop_result = forwardAtomic(pkt, slave_port_id);
|
|
|
|
}
|
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
|
|
|
snoop_response_cmd = snoop_result.first;
|
2014-09-20 23:18:29 +02:00
|
|
|
snoop_response_latency += snoop_result.second;
|
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
|
|
|
}
|
|
|
|
|
2016-02-10 10:08:25 +01:00
|
|
|
// set up a sensible default value
|
|
|
|
Tick response_latency = 0;
|
|
|
|
|
|
|
|
const bool sink_packet = sinkPacket(pkt);
|
2015-09-25 13:26:57 +02:00
|
|
|
|
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
|
|
|
// even if we had a snoop response, we must continue and also
|
|
|
|
// perform the actual request at the destination
|
2014-09-20 23:18:32 +02:00
|
|
|
PortID master_port_id = findPort(pkt->getAddr());
|
|
|
|
|
2016-02-10 10:08:25 +01:00
|
|
|
if (sink_packet) {
|
|
|
|
DPRINTF(CoherentXBar, "Not forwarding %s to %#llx\n",
|
|
|
|
pkt->cmdString(), pkt->getAddr());
|
|
|
|
} else {
|
|
|
|
if (!pointOfCoherency || pkt->isRead() || pkt->isWrite()) {
|
|
|
|
// forward the request to the appropriate destination
|
|
|
|
response_latency = masterPorts[master_port_id]->sendAtomic(pkt);
|
|
|
|
} else {
|
|
|
|
// if it does not need a response we sink the packet above
|
|
|
|
assert(pkt->needsResponse());
|
|
|
|
|
|
|
|
pkt->makeResponse();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
// stats updates for the request
|
|
|
|
pktCount[slave_port_id][master_port_id]++;
|
|
|
|
pktSize[slave_port_id][master_port_id] += pkt_size;
|
|
|
|
transDist[pkt_cmd]++;
|
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
|
|
|
|
|
|
|
|
2015-09-25 13:26:57 +02:00
|
|
|
// if lower levels have replied, tell the snoop filter
|
|
|
|
if (!system->bypassCaches() && snoopFilter && pkt->isResponse()) {
|
2014-09-20 23:18:29 +02:00
|
|
|
snoopFilter->updateResponse(pkt, *slavePorts[slave_port_id]);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// if we got a response from a snooper, restore it here
|
|
|
|
if (snoop_response_cmd != MemCmd::InvalidCmd) {
|
|
|
|
// no one else should have responded
|
|
|
|
assert(!pkt->isResponse());
|
|
|
|
pkt->cmd = snoop_response_cmd;
|
|
|
|
response_latency = snoop_response_latency;
|
|
|
|
}
|
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
// add the response data
|
2014-09-20 23:18:32 +02:00
|
|
|
if (pkt->isResponse()) {
|
|
|
|
pkt_size = pkt->hasData() ? pkt->getSize() : 0;
|
|
|
|
pkt_cmd = pkt->cmdToIndex();
|
|
|
|
|
|
|
|
// stats updates
|
|
|
|
pktCount[slave_port_id][master_port_id]++;
|
|
|
|
pktSize[slave_port_id][master_port_id] += pkt_size;
|
|
|
|
transDist[pkt_cmd]++;
|
|
|
|
}
|
2013-05-30 18:53:58 +02:00
|
|
|
|
2015-02-11 16:23:47 +01:00
|
|
|
// @todo: Not setting header time
|
|
|
|
pkt->payloadDelay = response_latency;
|
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
|
|
|
return response_latency;
|
|
|
|
}
|
|
|
|
|
|
|
|
Tick
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::recvAtomicSnoop(PacketPtr pkt, PortID master_port_id)
|
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
|
|
|
DPRINTF(CoherentXBar, "recvAtomicSnoop: packet src %s addr 0x%x cmd %s\n",
|
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
|
|
|
masterPorts[master_port_id]->name(), pkt->getAddr(),
|
|
|
|
pkt->cmdString());
|
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
// add the request snoop data
|
2016-07-21 18:19:14 +02:00
|
|
|
unsigned int pkt_size = pkt->hasData() ? pkt->getSize() : 0;
|
2014-09-20 23:18:32 +02:00
|
|
|
snoops++;
|
2016-07-21 18:19:14 +02:00
|
|
|
snoopTraffic += pkt_size;
|
2013-05-30 18:53:58 +02:00
|
|
|
|
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
|
|
|
// forward to all snoopers
|
2014-09-20 23:18:29 +02:00
|
|
|
std::pair<MemCmd, Tick> snoop_result;
|
|
|
|
Tick snoop_response_latency = 0;
|
|
|
|
if (snoopFilter) {
|
|
|
|
auto sf_res = snoopFilter->lookupSnoop(pkt);
|
|
|
|
snoop_response_latency += sf_res.second * clockPeriod();
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar, "%s: src %s %s 0x%x SF size: %i lat: %i\n",
|
2014-09-20 23:18:29 +02:00
|
|
|
__func__, masterPorts[master_port_id]->name(), pkt->cmdString(),
|
|
|
|
pkt->getAddr(), sf_res.first.size(), sf_res.second);
|
|
|
|
snoop_result = forwardAtomic(pkt, InvalidPortID, master_port_id,
|
|
|
|
sf_res.first);
|
|
|
|
} else {
|
|
|
|
snoop_result = forwardAtomic(pkt, InvalidPortID);
|
|
|
|
}
|
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
|
|
|
MemCmd snoop_response_cmd = snoop_result.first;
|
2014-09-20 23:18:29 +02:00
|
|
|
snoop_response_latency += snoop_result.second;
|
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
|
|
|
|
|
|
|
if (snoop_response_cmd != MemCmd::InvalidCmd)
|
|
|
|
pkt->cmd = snoop_response_cmd;
|
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
// add the response snoop data
|
2014-04-24 14:28:47 +02:00
|
|
|
if (pkt->isResponse()) {
|
2014-09-20 23:18:32 +02:00
|
|
|
snoops++;
|
2014-04-24 14:28:47 +02:00
|
|
|
}
|
2013-05-30 18:53:58 +02:00
|
|
|
|
2015-02-11 16:23:47 +01:00
|
|
|
// @todo: Not setting header time
|
|
|
|
pkt->payloadDelay = snoop_response_latency;
|
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
|
|
|
return snoop_response_latency;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::pair<MemCmd, Tick>
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::forwardAtomic(PacketPtr pkt, PortID exclude_slave_port_id,
|
2014-09-20 23:18:29 +02:00
|
|
|
PortID source_master_port_id,
|
2015-07-03 16:14:44 +02:00
|
|
|
const std::vector<QueuedSlavePort*>& dests)
|
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 packet may be changed on snoops, record the original
|
|
|
|
// command to enable us to restore it between snoops so that
|
|
|
|
// additional snoops can take place properly
|
|
|
|
MemCmd orig_cmd = pkt->cmd;
|
|
|
|
MemCmd snoop_response_cmd = MemCmd::InvalidCmd;
|
|
|
|
Tick snoop_response_latency = 0;
|
|
|
|
|
2013-02-15 23:40:09 +01:00
|
|
|
// snoops should only happen if the system isn't bypassing caches
|
|
|
|
assert(!system->bypassCaches());
|
|
|
|
|
2014-04-24 14:28:47 +02:00
|
|
|
unsigned fanout = 0;
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
for (const auto& p: dests) {
|
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
|
|
|
// we could have gotten this request from a snooping master
|
|
|
|
// (corresponding to our own slave port that is also in
|
|
|
|
// snoopPorts) and should not send it back to where it came
|
|
|
|
// from
|
2014-09-20 23:18:29 +02:00
|
|
|
if (exclude_slave_port_id != InvalidPortID &&
|
|
|
|
p->getId() == exclude_slave_port_id)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Tick latency = p->sendAtomicSnoop(pkt);
|
|
|
|
fanout++;
|
|
|
|
|
|
|
|
// in contrast to a functional access, we have to keep on
|
|
|
|
// going as all snoopers must be updated even if we get a
|
|
|
|
// response
|
|
|
|
if (!pkt->isResponse())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// response from snoop agent
|
|
|
|
assert(pkt->cmd != orig_cmd);
|
2015-12-31 15:32:58 +01:00
|
|
|
assert(pkt->cacheResponding());
|
2014-09-20 23:18:29 +02:00
|
|
|
// should only happen once
|
|
|
|
assert(snoop_response_cmd == MemCmd::InvalidCmd);
|
|
|
|
// save response state
|
|
|
|
snoop_response_cmd = pkt->cmd;
|
|
|
|
snoop_response_latency = latency;
|
|
|
|
|
|
|
|
if (snoopFilter) {
|
|
|
|
// Handle responses by the snoopers and differentiate between
|
|
|
|
// responses to requests from above and snoops from below
|
|
|
|
if (source_master_port_id != InvalidPortID) {
|
|
|
|
// Getting a response for a snoop from below
|
|
|
|
assert(exclude_slave_port_id == InvalidPortID);
|
|
|
|
snoopFilter->updateSnoopForward(pkt, *p,
|
|
|
|
*masterPorts[source_master_port_id]);
|
|
|
|
} else {
|
|
|
|
// Getting a response for a request from above
|
|
|
|
assert(source_master_port_id == InvalidPortID);
|
|
|
|
snoopFilter->updateSnoopResponse(pkt, *p,
|
|
|
|
*slavePorts[exclude_slave_port_id]);
|
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:29 +02:00
|
|
|
// restore original packet state for remaining snoopers
|
|
|
|
pkt->cmd = orig_cmd;
|
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-04-24 14:28:47 +02:00
|
|
|
// Stats for fanout
|
|
|
|
snoopFanout.sample(fanout);
|
|
|
|
|
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 packet is restored as part of the loop and any potential
|
|
|
|
// snoop response is part of the returned pair
|
|
|
|
return std::make_pair(snoop_response_cmd, snoop_response_latency);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::recvFunctional(PacketPtr pkt, PortID slave_port_id)
|
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
|
|
|
{
|
|
|
|
if (!pkt->isPrint()) {
|
|
|
|
// don't do DPRINTFs on PrintReq as it clutters up the output
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar,
|
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
|
|
|
"recvFunctional: packet src %s addr 0x%x cmd %s\n",
|
|
|
|
slavePorts[slave_port_id]->name(), pkt->getAddr(),
|
|
|
|
pkt->cmdString());
|
|
|
|
}
|
|
|
|
|
2015-05-05 09:22:29 +02:00
|
|
|
if (!system->bypassCaches()) {
|
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
|
|
|
// forward to all snoopers but the source
|
|
|
|
forwardFunctional(pkt, slave_port_id);
|
|
|
|
}
|
|
|
|
|
|
|
|
// there is no need to continue if the snooping has found what we
|
|
|
|
// were looking for and the packet is already a response
|
|
|
|
if (!pkt->isResponse()) {
|
2015-07-03 16:14:44 +02:00
|
|
|
// since our slave ports are queued ports we need to check them as well
|
|
|
|
for (const auto& p : slavePorts) {
|
|
|
|
// if we find a response that has the data, then the
|
|
|
|
// downstream caches/memories may be out of date, so simply stop
|
|
|
|
// here
|
|
|
|
if (p->checkFunctional(pkt)) {
|
|
|
|
if (pkt->needsResponse())
|
|
|
|
pkt->makeResponse();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
PortID dest_id = findPort(pkt->getAddr());
|
|
|
|
|
|
|
|
masterPorts[dest_id]->sendFunctional(pkt);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::recvFunctionalSnoop(PacketPtr pkt, PortID master_port_id)
|
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
|
|
|
{
|
|
|
|
if (!pkt->isPrint()) {
|
|
|
|
// don't do DPRINTFs on PrintReq as it clutters up the output
|
2014-09-20 23:18:32 +02:00
|
|
|
DPRINTF(CoherentXBar,
|
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
|
|
|
"recvFunctionalSnoop: packet src %s addr 0x%x cmd %s\n",
|
|
|
|
masterPorts[master_port_id]->name(), pkt->getAddr(),
|
|
|
|
pkt->cmdString());
|
|
|
|
}
|
|
|
|
|
2015-11-06 09:26:09 +01:00
|
|
|
for (const auto& p : slavePorts) {
|
|
|
|
if (p->checkFunctional(pkt)) {
|
|
|
|
if (pkt->needsResponse())
|
|
|
|
pkt->makeResponse();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// forward to all snoopers
|
|
|
|
forwardFunctional(pkt, InvalidPortID);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::forwardFunctional(PacketPtr pkt, PortID exclude_slave_port_id)
|
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
|
|
|
{
|
2013-02-15 23:40:09 +01:00
|
|
|
// snoops should only happen if the system isn't bypassing caches
|
|
|
|
assert(!system->bypassCaches());
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
for (const auto& p: snoopPorts) {
|
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
|
|
|
// we could have gotten this request from a snooping master
|
|
|
|
// (corresponding to our own slave port that is also in
|
|
|
|
// snoopPorts) and should not send it back to where it came
|
|
|
|
// from
|
|
|
|
if (exclude_slave_port_id == InvalidPortID ||
|
|
|
|
p->getId() != exclude_slave_port_id)
|
|
|
|
p->sendFunctionalSnoop(pkt);
|
|
|
|
|
|
|
|
// if we get a response we are done
|
|
|
|
if (pkt->isResponse()) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-02-10 10:08:25 +01:00
|
|
|
bool
|
|
|
|
CoherentXBar::sinkPacket(const PacketPtr pkt) const
|
|
|
|
{
|
|
|
|
// we can sink the packet if:
|
|
|
|
// 1) the crossbar is the point of coherency, and a cache is
|
|
|
|
// responding after being snooped
|
|
|
|
// 2) the crossbar is the point of coherency, and the packet is a
|
|
|
|
// coherency packet (not a read or a write) that does not
|
|
|
|
// require a response
|
|
|
|
// 3) this is a clean evict or clean writeback, but the packet is
|
|
|
|
// found in a cache above this crossbar
|
|
|
|
// 4) a cache is responding after being snooped, and the packet
|
|
|
|
// either does not need the block to be writable, or the cache
|
|
|
|
// that has promised to respond (setting the cache responding
|
|
|
|
// flag) is providing writable and thus had a Modified block,
|
|
|
|
// and no further action is needed
|
|
|
|
return (pointOfCoherency && pkt->cacheResponding()) ||
|
|
|
|
(pointOfCoherency && !(pkt->isRead() || pkt->isWrite()) &&
|
|
|
|
!pkt->needsResponse()) ||
|
|
|
|
(pkt->isCleanEviction() && pkt->isBlockCached()) ||
|
|
|
|
(pkt->cacheResponding() &&
|
|
|
|
(!pkt->needsWritable() || pkt->responderHadWritable()));
|
|
|
|
}
|
|
|
|
|
2013-05-30 18:53:58 +02:00
|
|
|
void
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar::regStats()
|
2013-05-30 18:53:58 +02:00
|
|
|
{
|
2014-09-20 23:18:32 +02:00
|
|
|
// register the stats of the base class and our layers
|
|
|
|
BaseXBar::regStats();
|
|
|
|
for (auto l: reqLayers)
|
|
|
|
l->regStats();
|
|
|
|
for (auto l: respLayers)
|
|
|
|
l->regStats();
|
|
|
|
for (auto l: snoopLayers)
|
|
|
|
l->regStats();
|
|
|
|
|
|
|
|
snoops
|
|
|
|
.name(name() + ".snoops")
|
2014-04-24 14:28:47 +02:00
|
|
|
.desc("Total snoops (count)")
|
|
|
|
;
|
|
|
|
|
2016-07-21 18:19:14 +02:00
|
|
|
snoopTraffic
|
|
|
|
.name(name() + ".snoopTraffic")
|
|
|
|
.desc("Total snoop traffic (bytes)")
|
|
|
|
;
|
|
|
|
|
2014-04-24 14:28:47 +02:00
|
|
|
snoopFanout
|
|
|
|
.init(0, snoopPorts.size(), 1)
|
|
|
|
.name(name() + ".snoop_fanout")
|
|
|
|
.desc("Request fanout histogram")
|
|
|
|
;
|
2013-05-30 18:53:58 +02:00
|
|
|
}
|
|
|
|
|
2014-09-20 23:18:32 +02:00
|
|
|
CoherentXBar *
|
|
|
|
CoherentXBarParams::create()
|
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
|
|
|
return new CoherentXBar(this);
|
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
|
|
|
}
|