2006-03-26 00:31:20 +01:00
|
|
|
/*
|
2012-02-09 19:06:27 +01:00
|
|
|
* Copyright (c) 2011-2012 ARM Limited
|
2012-01-17 19:55:09 +01: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.
|
|
|
|
*
|
2006-03-26 00:31:20 +01:00
|
|
|
* 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.
|
2006-06-01 01:26:56 +02:00
|
|
|
*
|
|
|
|
* Authors: Ali Saidi
|
2012-01-17 19:55:09 +01:00
|
|
|
* Andreas Hansson
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
* William Wang
|
2006-03-26 00:31:20 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
2006-08-15 01:25:07 +02:00
|
|
|
* @file
|
|
|
|
* Definition of a bus object.
|
2006-03-26 00:31:20 +01:00
|
|
|
*/
|
|
|
|
|
2006-07-06 20:41:01 +02:00
|
|
|
#include "base/misc.hh"
|
2006-04-12 01:35:30 +02:00
|
|
|
#include "base/trace.hh"
|
2011-04-15 19:44:32 +02:00
|
|
|
#include "debug/Bus.hh"
|
|
|
|
#include "debug/BusAddrRanges.hh"
|
2006-04-12 01:35:30 +02:00
|
|
|
#include "mem/bus.hh"
|
2006-03-26 00:31:20 +01:00
|
|
|
|
2010-08-17 14:06:21 +02:00
|
|
|
Bus::Bus(const BusParams *p)
|
2012-03-22 11:37:21 +01:00
|
|
|
: MemObject(p), clock(p->clock),
|
2010-08-17 14:06:21 +02:00
|
|
|
headerCycles(p->header_cycles), width(p->width), tickNextIdle(0),
|
2012-03-22 11:37:21 +01:00
|
|
|
drainEvent(NULL), busIdleEvent(this), inRetry(false),
|
2012-02-24 17:40:29 +01:00
|
|
|
defaultPortId(INVALID_PORT_ID), useDefaultRange(p->use_default_range),
|
|
|
|
defaultBlockSize(p->block_size),
|
2010-08-17 14:06:21 +02:00
|
|
|
cachedBlockSize(0), cachedBlockSizeValid(false)
|
|
|
|
{
|
|
|
|
//width, clock period, and header cycles must be positive
|
|
|
|
if (width <= 0)
|
|
|
|
fatal("Bus width must be positive\n");
|
|
|
|
if (clock <= 0)
|
|
|
|
fatal("Bus clock period must be positive\n");
|
|
|
|
if (headerCycles <= 0)
|
|
|
|
fatal("Number of header cycles must be positive\n");
|
2012-02-24 17:43:53 +01:00
|
|
|
|
|
|
|
// create the ports based on the size of the master and slave
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// vector ports, and the presence of the default port, the ports
|
|
|
|
// are enumerated starting from zero
|
2012-02-24 17:43:53 +01:00
|
|
|
for (int i = 0; i < p->port_master_connection_count; ++i) {
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
std::string portName = csprintf("%s-p%d", name(), i);
|
|
|
|
BusMasterPort* bp = new BusMasterPort(portName, this, i);
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
masterPorts.push_back(bp);
|
2012-02-24 17:43:53 +01:00
|
|
|
}
|
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// see if we have a default slave device connected and if so add
|
|
|
|
// our corresponding master port
|
2012-02-24 17:43:53 +01:00
|
|
|
if (p->port_default_connection_count) {
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
defaultPortId = masterPorts.size();
|
2012-02-24 17:43:53 +01:00
|
|
|
std::string portName = csprintf("%s-default", name());
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
BusMasterPort* bp = new BusMasterPort(portName, this, defaultPortId);
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
masterPorts.push_back(bp);
|
2012-03-22 11:37:21 +01:00
|
|
|
}
|
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// create the slave ports, once again starting at zero
|
2012-03-22 11:37:21 +01:00
|
|
|
for (int i = 0; i < p->port_slave_connection_count; ++i) {
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
std::string portName = csprintf("%s-p%d", name(), i);
|
|
|
|
BusSlavePort* bp = new BusSlavePort(portName, this, i);
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
slavePorts.push_back(bp);
|
2012-02-24 17:43:53 +01:00
|
|
|
}
|
|
|
|
|
2010-08-17 14:06:21 +02:00
|
|
|
clearPortCache();
|
|
|
|
}
|
|
|
|
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
MasterPort &
|
|
|
|
Bus::getMasterPort(const std::string &if_name, int idx)
|
2006-05-26 19:48:35 +02:00
|
|
|
{
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
if (if_name == "master" && idx < masterPorts.size()) {
|
|
|
|
// the master port index translates directly to the vector position
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
return *masterPorts[idx];
|
2012-02-24 17:43:53 +01:00
|
|
|
} else if (if_name == "default") {
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
return *masterPorts[defaultPortId];
|
2012-01-17 19:55:09 +01:00
|
|
|
} else {
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
return MemObject::getMasterPort(if_name, idx);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
SlavePort &
|
|
|
|
Bus::getSlavePort(const std::string &if_name, int idx)
|
|
|
|
{
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
if (if_name == "slave" && idx < slavePorts.size()) {
|
|
|
|
// the slave port index translates directly to the vector position
|
|
|
|
return *slavePorts[idx];
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
} else {
|
|
|
|
return MemObject::getSlavePort(if_name, idx);
|
2006-11-02 21:20:37 +01:00
|
|
|
}
|
2006-05-26 19:48:35 +02:00
|
|
|
}
|
|
|
|
|
2006-04-28 21:37:48 +02:00
|
|
|
void
|
|
|
|
Bus::init()
|
|
|
|
{
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
std::vector<BusSlavePort*>::iterator p;
|
|
|
|
|
|
|
|
// iterate over our slave ports and determine which of our
|
|
|
|
// neighbouring master ports are snooping and add them as snoopers
|
|
|
|
for (p = slavePorts.begin(); p != slavePorts.end(); ++p) {
|
|
|
|
if ((*p)->getMasterPort().isSnooping()) {
|
|
|
|
DPRINTF(BusAddrRanges, "Adding snooping neighbour %s\n",
|
|
|
|
(*p)->getMasterPort().name());
|
|
|
|
snoopPorts.push_back(*p);
|
2012-01-17 19:55:09 +01:00
|
|
|
}
|
|
|
|
}
|
2006-04-28 21:37:48 +02:00
|
|
|
}
|
|
|
|
|
2008-10-09 13:58:24 +02:00
|
|
|
Tick
|
|
|
|
Bus::calcPacketTiming(PacketPtr pkt)
|
2006-03-26 00:31:20 +01:00
|
|
|
{
|
2012-03-22 11:37:21 +01:00
|
|
|
// determine the current time rounded to the closest following
|
|
|
|
// clock edge
|
|
|
|
Tick now = curTick();
|
|
|
|
if (now % clock != 0) {
|
|
|
|
now = ((now / clock) + 1) * clock;
|
2007-06-20 20:54:17 +02:00
|
|
|
}
|
2006-10-10 05:24:21 +02:00
|
|
|
|
2012-03-22 11:37:21 +01:00
|
|
|
Tick headerTime = now + headerCycles * clock;
|
2008-02-26 08:20:08 +01:00
|
|
|
|
2006-10-10 05:24:21 +02:00
|
|
|
// The packet will be sent. Figure out how long it occupies the bus, and
|
|
|
|
// how much of that time is for the first "word", aka bus width.
|
2006-10-10 00:12:45 +02:00
|
|
|
int numCycles = 0;
|
2008-02-26 08:20:08 +01:00
|
|
|
if (pkt->hasData()) {
|
2006-10-10 00:12:45 +02:00
|
|
|
// If a packet has data, it needs ceil(size/width) cycles to send it
|
2008-02-26 08:20:08 +01:00
|
|
|
int dataSize = pkt->getSize();
|
|
|
|
numCycles += dataSize/width;
|
|
|
|
if (dataSize % width)
|
2006-10-10 00:12:45 +02:00
|
|
|
numCycles++;
|
|
|
|
}
|
|
|
|
|
2006-10-10 05:24:21 +02:00
|
|
|
// The first word will be delivered after the current tick, the delivery
|
|
|
|
// of the address if any, and one bus cycle to deliver the data
|
2008-02-26 08:20:08 +01:00
|
|
|
pkt->firstWordTime = headerTime + clock;
|
|
|
|
|
|
|
|
pkt->finishTime = headerTime + numCycles * clock;
|
2008-03-17 08:07:38 +01:00
|
|
|
|
|
|
|
return headerTime;
|
2008-02-26 08:20:08 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void Bus::occupyBus(Tick until)
|
|
|
|
{
|
2008-03-17 08:07:38 +01:00
|
|
|
if (until == 0) {
|
|
|
|
// shortcut for express snoop packets
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-02-26 08:20:08 +01:00
|
|
|
tickNextIdle = until;
|
2012-03-22 11:37:21 +01:00
|
|
|
reschedule(busIdleEvent, tickNextIdle, true);
|
2006-10-10 05:24:21 +02:00
|
|
|
|
|
|
|
DPRINTF(Bus, "The bus is now occupied from tick %d to %d\n",
|
2011-01-08 06:50:29 +01:00
|
|
|
curTick(), tickNextIdle);
|
2006-10-11 05:28:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
Bus::isOccupied(PacketPtr pkt, Port* port)
|
2006-10-11 05:28:33 +02:00
|
|
|
{
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// first we see if the next idle tick is in the future, next the
|
|
|
|
// bus is considered occupied if there are ports on the retry list
|
|
|
|
// and we are not in a retry with the current port
|
|
|
|
if (tickNextIdle > curTick() ||
|
|
|
|
(!retryList.empty() && !(inRetry && port == retryList.front()))) {
|
|
|
|
addToRetryList(port);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2006-10-11 05:28:33 +02:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
bool
|
|
|
|
Bus::recvTiming(PacketPtr pkt)
|
|
|
|
{
|
|
|
|
// get the source id
|
2012-03-22 11:37:21 +01:00
|
|
|
Packet::NodeID src_id = pkt->getSrc();
|
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// determine the source port based on the id and direction
|
|
|
|
Port *src_port = NULL;
|
|
|
|
if (pkt->isRequest())
|
|
|
|
src_port = slavePorts[src_id];
|
|
|
|
else
|
|
|
|
src_port = masterPorts[src_id];
|
|
|
|
|
|
|
|
// test if the bus should be considered occupied for the current
|
|
|
|
// packet, and exclude express snoops from the check
|
|
|
|
if (!pkt->isExpressSnoop() && isOccupied(pkt, src_port)) {
|
2007-09-17 01:46:38 +02:00
|
|
|
DPRINTF(Bus, "recvTiming: src %d dst %d %s 0x%x BUSY\n",
|
2012-03-22 11:37:21 +01:00
|
|
|
src_id, pkt->getDest(), pkt->cmdString(), pkt->getAddr());
|
2006-10-11 05:28:33 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2007-09-17 01:46:38 +02:00
|
|
|
DPRINTF(Bus, "recvTiming: src %d dst %d %s 0x%x\n",
|
2012-03-22 11:37:21 +01:00
|
|
|
src_id, pkt->getDest(), pkt->cmdString(), pkt->getAddr());
|
2007-09-17 01:46:38 +02:00
|
|
|
|
2008-03-17 08:07:38 +01:00
|
|
|
Tick headerFinishTime = pkt->isExpressSnoop() ? 0 : calcPacketTiming(pkt);
|
|
|
|
Tick packetFinishTime = pkt->isExpressSnoop() ? 0 : pkt->finishTime;
|
2007-07-25 07:37:41 +02:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// decide what to do based on the direction
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
if (pkt->isRequest()) {
|
2012-03-22 11:37:21 +01:00
|
|
|
// the packet is a memory-mapped request and should be broadcasted to
|
|
|
|
// our snoopers
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
assert(pkt->getDest() == Packet::Broadcast);
|
|
|
|
|
|
|
|
// forward to all snoopers but the source
|
|
|
|
forwardTiming(pkt, src_id);
|
|
|
|
|
|
|
|
// remember if we add an outstanding req so we can undo it if
|
|
|
|
// necessary, if the packet needs a response, we should add it
|
|
|
|
// as outstanding and express snoops never fail so there is
|
|
|
|
// not need to worry about them
|
|
|
|
bool add_outstanding = !pkt->isExpressSnoop() && pkt->needsResponse();
|
|
|
|
|
|
|
|
// keep track that we have an outstanding request packet
|
|
|
|
// matching this request, this is used by the coherency
|
|
|
|
// mechanism in determining what to do with snoop responses
|
|
|
|
// (in recvTimingSnoop)
|
|
|
|
if (add_outstanding) {
|
|
|
|
// we should never have an exsiting request outstanding
|
|
|
|
assert(outstandingReq.find(pkt->req) == outstandingReq.end());
|
|
|
|
outstandingReq.insert(pkt->req);
|
2006-10-11 05:28:33 +02:00
|
|
|
}
|
2012-03-22 11:37:21 +01:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// since it is a normal request, determine the destination
|
|
|
|
// based on the address and attempt to send the packet
|
|
|
|
bool success = masterPorts[findPort(pkt->getAddr())]->sendTiming(pkt);
|
2006-10-11 05:28:33 +02:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
if (!success) {
|
|
|
|
// inhibited packets should never be forced to retry
|
2009-10-04 03:07:39 +02:00
|
|
|
assert(!pkt->memInhibitAsserted());
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
|
|
|
|
// if it was added as outstanding and the send failed, then
|
|
|
|
// erase it again
|
|
|
|
if (add_outstanding)
|
|
|
|
outstandingReq.erase(pkt->req);
|
|
|
|
|
|
|
|
DPRINTF(Bus, "recvTiming: src %d dst %d %s 0x%x RETRY\n",
|
2012-03-22 11:37:21 +01:00
|
|
|
src_id, pkt->getDest(), pkt->cmdString(), pkt->getAddr());
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
|
2007-07-25 07:37:41 +02:00
|
|
|
addToRetryList(src_port);
|
2008-03-17 08:07:38 +01:00
|
|
|
occupyBus(headerFinishTime);
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
|
2007-07-25 07:37:41 +02:00
|
|
|
return false;
|
2006-10-09 00:44:49 +02:00
|
|
|
}
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
} else {
|
|
|
|
// the packet is a normal response to a request that we should
|
|
|
|
// have seen passing through the bus
|
|
|
|
assert(outstandingReq.find(pkt->req) != outstandingReq.end());
|
|
|
|
|
|
|
|
// remove it as outstanding
|
|
|
|
outstandingReq.erase(pkt->req);
|
|
|
|
|
|
|
|
// send the packet to the destination through one of our slave
|
|
|
|
// ports, as determined by the destination field
|
|
|
|
bool success M5_VAR_USED = slavePorts[pkt->getDest()]->sendTiming(pkt);
|
|
|
|
|
|
|
|
// currently it is illegal to block responses... can lead to
|
|
|
|
// deadlock
|
|
|
|
assert(success);
|
2006-11-14 23:15:05 +01:00
|
|
|
}
|
2007-07-25 07:37:41 +02:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
succeededTiming(packetFinishTime);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
Bus::recvTimingSnoop(PacketPtr pkt)
|
|
|
|
{
|
|
|
|
// get the source id
|
|
|
|
Packet::NodeID src_id = pkt->getSrc();
|
|
|
|
|
|
|
|
if (pkt->isRequest()) {
|
|
|
|
DPRINTF(Bus, "recvTimingSnoop: src %d dst %d %s 0x%x\n",
|
|
|
|
src_id, pkt->getDest(), pkt->cmdString(), pkt->getAddr());
|
|
|
|
|
|
|
|
// the packet is an express snoop request and should be
|
|
|
|
// broadcasted to our snoopers
|
|
|
|
assert(pkt->getDest() == Packet::Broadcast);
|
|
|
|
assert(pkt->isExpressSnoop());
|
|
|
|
|
|
|
|
// forward to all snoopers
|
|
|
|
forwardTiming(pkt, INVALID_PORT_ID);
|
|
|
|
|
|
|
|
// 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(src_id == findPort(pkt->getAddr()));
|
|
|
|
|
|
|
|
// this is an express snoop and is never forced to retry
|
|
|
|
assert(!inRetry);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
} else {
|
|
|
|
// determine the source port based on the id
|
|
|
|
SlavePort* src_port = slavePorts[src_id];
|
2008-02-26 08:20:08 +01:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
if (isOccupied(pkt, src_port)) {
|
|
|
|
DPRINTF(Bus, "recvTimingSnoop: src %d dst %d %s 0x%x BUSY\n",
|
|
|
|
src_id, pkt->getDest(), pkt->cmdString(), pkt->getAddr());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
DPRINTF(Bus, "recvTimingSnoop: src %d dst %d %s 0x%x\n",
|
|
|
|
src_id, pkt->getDest(), pkt->cmdString(), pkt->getAddr());
|
|
|
|
|
|
|
|
// get the destination from the packet
|
|
|
|
Packet::NodeID dest = pkt->getDest();
|
|
|
|
|
|
|
|
// responses are never express snoops
|
|
|
|
assert(!pkt->isExpressSnoop());
|
|
|
|
|
|
|
|
calcPacketTiming(pkt);
|
|
|
|
Tick packetFinishTime = pkt->finishTime;
|
|
|
|
|
|
|
|
// determine if the response is from a snoop request we
|
|
|
|
// created as the result of a normal request (in which case it
|
|
|
|
// should be in the outstandingReq), or if we merely forwarded
|
|
|
|
// someone else's snoop request
|
|
|
|
if (outstandingReq.find(pkt->req) == outstandingReq.end()) {
|
|
|
|
// this is a snoop response to a snoop request we
|
|
|
|
// forwarded, e.g. coming from the L1 and going to the L2
|
|
|
|
// this should be forwarded as a snoop response
|
|
|
|
bool success M5_VAR_USED = masterPorts[dest]->sendTimingSnoop(pkt);
|
|
|
|
assert(success);
|
|
|
|
} else {
|
|
|
|
// we got a snoop response on one of our slave ports,
|
|
|
|
// i.e. from a coherent master connected to the bus, and
|
|
|
|
// since we created the snoop request as part of
|
|
|
|
// recvTiming, this should now be a normal response again
|
|
|
|
outstandingReq.erase(pkt->req);
|
|
|
|
|
|
|
|
// this is a snoop response from a coherent master, with a
|
|
|
|
// destination field set on its way through the bus as
|
|
|
|
// request, hence it should never go back to where the
|
|
|
|
// snoop response came from, but instead to where the
|
|
|
|
// original request came from
|
|
|
|
assert(src_id != dest);
|
|
|
|
|
|
|
|
// as a normal response, it should go back to a master
|
|
|
|
// through one of our slave ports
|
|
|
|
bool success M5_VAR_USED = slavePorts[dest]->sendTiming(pkt);
|
|
|
|
|
|
|
|
// currently it is illegal to block responses... can lead
|
|
|
|
// to deadlock
|
|
|
|
assert(success);
|
|
|
|
}
|
|
|
|
|
|
|
|
succeededTiming(packetFinishTime);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
Bus::succeededTiming(Tick busy_time)
|
|
|
|
{
|
|
|
|
// occupy the bus accordingly
|
|
|
|
occupyBus(busy_time);
|
|
|
|
|
|
|
|
// if a retrying port succeeded, also take it off the retry list
|
2007-07-25 07:37:41 +02:00
|
|
|
if (inRetry) {
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
DPRINTF(Bus, "Remove retry from list %s\n",
|
|
|
|
retryList.front()->name());
|
2007-07-25 07:37:41 +02:00
|
|
|
retryList.pop_front();
|
|
|
|
inRetry = false;
|
2006-05-31 00:57:42 +02:00
|
|
|
}
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
Bus::forwardTiming(PacketPtr pkt, int exclude_slave_port_id)
|
|
|
|
{
|
|
|
|
SnoopIter s_end = snoopPorts.end();
|
|
|
|
for (SnoopIter s_iter = snoopPorts.begin(); s_iter != s_end; s_iter++) {
|
|
|
|
BusSlavePort *p = *s_iter;
|
|
|
|
// 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 == INVALID_PORT_ID ||
|
|
|
|
p->getId() != exclude_slave_port_id) {
|
|
|
|
// cache is not allowed to refuse snoop
|
|
|
|
bool success M5_VAR_USED = p->sendTimingSnoop(pkt);
|
|
|
|
assert(success);
|
|
|
|
}
|
|
|
|
}
|
2006-03-26 00:31:20 +01:00
|
|
|
}
|
|
|
|
|
2006-05-31 00:57:42 +02:00
|
|
|
void
|
2012-03-22 11:37:21 +01:00
|
|
|
Bus::releaseBus()
|
2006-05-31 00:57:42 +02:00
|
|
|
{
|
2012-03-22 11:37:21 +01:00
|
|
|
// releasing the bus means we should now be idle
|
|
|
|
assert(curTick() >= tickNextIdle);
|
|
|
|
|
|
|
|
// bus is now idle, so if someone is waiting we can retry
|
|
|
|
if (!retryList.empty()) {
|
|
|
|
// note that we block (return false on recvTiming) both
|
|
|
|
// because the bus is busy and because the destination is
|
|
|
|
// busy, and in the latter case the bus may be released before
|
|
|
|
// we see a retry from the destination
|
|
|
|
retryWaiting();
|
2006-05-31 00:57:42 +02:00
|
|
|
}
|
2012-03-22 11:37:21 +01:00
|
|
|
|
2006-11-07 20:25:54 +01:00
|
|
|
//If we weren't able to drain before, we might be able to now.
|
2012-03-22 11:37:21 +01:00
|
|
|
if (drainEvent && retryList.empty() && curTick() >= tickNextIdle) {
|
2006-11-07 20:25:54 +01:00
|
|
|
drainEvent->process();
|
2006-11-09 17:33:44 +01:00
|
|
|
// Clear the drain event once we're done with it.
|
|
|
|
drainEvent = NULL;
|
|
|
|
}
|
2006-05-31 00:57:42 +02:00
|
|
|
}
|
|
|
|
|
2012-03-22 11:37:21 +01:00
|
|
|
void
|
|
|
|
Bus::retryWaiting()
|
|
|
|
{
|
|
|
|
// this should never be called with an empty retry list
|
|
|
|
assert(!retryList.empty());
|
|
|
|
|
|
|
|
// send a retry to the port at the head of the retry list
|
|
|
|
inRetry = true;
|
|
|
|
|
|
|
|
// note that we might have blocked on the receiving port being
|
|
|
|
// busy (rather than the bus itself) and now call retry before the
|
|
|
|
// destination called retry on the bus
|
|
|
|
retryList.front()->sendRetry();
|
|
|
|
|
|
|
|
// If inRetry is still true, sendTiming wasn't called in zero time
|
|
|
|
// (e.g. the cache does this)
|
|
|
|
if (inRetry) {
|
|
|
|
retryList.pop_front();
|
|
|
|
inRetry = false;
|
|
|
|
|
|
|
|
//Bring tickNextIdle up to the present
|
|
|
|
while (tickNextIdle < curTick())
|
|
|
|
tickNextIdle += clock;
|
|
|
|
|
|
|
|
//Burn a cycle for the missed grant.
|
|
|
|
tickNextIdle += clock;
|
|
|
|
|
|
|
|
reschedule(busIdleEvent, tickNextIdle, true);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
Bus::recvRetry(int id)
|
|
|
|
{
|
|
|
|
// we got a retry from a peer that we tried to send something to
|
|
|
|
// and failed, but we sent it on the account of someone else, and
|
|
|
|
// that source port should be on our retry list, however if the
|
|
|
|
// bus is released before this happens and the retry (from the bus
|
|
|
|
// point of view) is successful then this no longer holds and we
|
|
|
|
// could in fact have an empty retry list
|
|
|
|
if (retryList.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// if the bus isn't busy
|
|
|
|
if (curTick() >= tickNextIdle) {
|
|
|
|
// note that we do not care who told us to retry at the moment, we
|
|
|
|
// merely let the first one on the retry list go
|
|
|
|
retryWaiting();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-07-16 05:09:03 +02:00
|
|
|
int
|
|
|
|
Bus::findPort(Addr addr)
|
2006-03-26 00:31:20 +01:00
|
|
|
{
|
|
|
|
/* An interval tree would be a better way to do this. --ali. */
|
2010-08-17 14:06:21 +02:00
|
|
|
int dest_id;
|
2006-03-26 00:31:20 +01:00
|
|
|
|
2007-08-04 22:05:55 +02:00
|
|
|
dest_id = checkPortCache(addr);
|
2012-02-24 17:40:29 +01:00
|
|
|
if (dest_id != INVALID_PORT_ID)
|
2010-08-17 14:06:21 +02:00
|
|
|
return dest_id;
|
|
|
|
|
|
|
|
// Check normal port ranges
|
|
|
|
PortIter i = portMap.find(RangeSize(addr,1));
|
|
|
|
if (i != portMap.end()) {
|
|
|
|
dest_id = i->second;
|
|
|
|
updatePortCache(dest_id, i->first.start, i->first.end);
|
|
|
|
return dest_id;
|
2007-08-04 22:05:55 +02:00
|
|
|
}
|
2006-07-06 20:41:01 +02:00
|
|
|
|
|
|
|
// Check if this matches the default range
|
2010-08-17 14:06:21 +02:00
|
|
|
if (useDefaultRange) {
|
2007-08-10 22:14:01 +02:00
|
|
|
AddrRangeIter a_end = defaultRange.end();
|
|
|
|
for (AddrRangeIter i = defaultRange.begin(); i != a_end; i++) {
|
|
|
|
if (*i == addr) {
|
2006-08-28 18:55:13 +02:00
|
|
|
DPRINTF(Bus, " found addr %#llx on default\n", addr);
|
2012-01-17 19:55:09 +01:00
|
|
|
return defaultPortId;
|
2006-07-06 20:41:01 +02:00
|
|
|
}
|
|
|
|
}
|
2012-02-24 17:40:29 +01:00
|
|
|
} else if (defaultPortId != INVALID_PORT_ID) {
|
|
|
|
DPRINTF(Bus, "Unable to find destination for addr %#llx, "
|
|
|
|
"will use default port\n", addr);
|
|
|
|
return defaultPortId;
|
2006-07-06 20:41:01 +02:00
|
|
|
}
|
|
|
|
|
2012-02-24 17:40:29 +01:00
|
|
|
// we should use the range for the default port and it did not
|
|
|
|
// match, or the default port is not set
|
|
|
|
fatal("Unable to find destination for addr %#llx on bus %s\n", addr,
|
|
|
|
name());
|
2006-03-26 00:31:20 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
Tick
|
2006-10-20 09:10:12 +02:00
|
|
|
Bus::recvAtomic(PacketPtr pkt)
|
2006-03-26 00:31:20 +01:00
|
|
|
{
|
2006-05-26 20:17:33 +02:00
|
|
|
DPRINTF(Bus, "recvAtomic: packet src %d dest %d addr 0x%x cmd %s\n",
|
|
|
|
pkt->getSrc(), pkt->getDest(), pkt->getAddr(), pkt->cmdString());
|
2012-03-22 11:37:21 +01:00
|
|
|
|
|
|
|
// we should always see a request routed based on the address
|
2006-05-26 20:17:33 +02:00
|
|
|
assert(pkt->getDest() == Packet::Broadcast);
|
2007-06-30 19:16:18 +02:00
|
|
|
assert(pkt->isRequest());
|
2006-11-09 17:37:26 +01:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// forward to all snoopers but the source
|
|
|
|
std::pair<MemCmd, Tick> snoop_result = forwardAtomic(pkt, pkt->getSrc());
|
|
|
|
MemCmd snoop_response_cmd = snoop_result.first;
|
|
|
|
Tick snoop_response_latency = snoop_result.second;
|
2012-03-22 11:37:21 +01:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// even if we had a snoop response, we must continue and also
|
|
|
|
// perform the actual request at the destination
|
|
|
|
int dest_id = findPort(pkt->getAddr());
|
|
|
|
|
|
|
|
// forward the request to the appropriate destination
|
|
|
|
Tick response_latency = masterPorts[dest_id]->sendAtomic(pkt);
|
|
|
|
|
|
|
|
// 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;
|
|
|
|
}
|
|
|
|
|
|
|
|
pkt->finishTime = curTick() + response_latency;
|
|
|
|
return response_latency;
|
|
|
|
}
|
|
|
|
|
|
|
|
Tick
|
|
|
|
Bus::recvAtomicSnoop(PacketPtr pkt)
|
|
|
|
{
|
|
|
|
DPRINTF(Bus, "recvAtomicSnoop: packet src %d dest %d addr 0x%x cmd %s\n",
|
|
|
|
pkt->getSrc(), pkt->getDest(), pkt->getAddr(), pkt->cmdString());
|
|
|
|
|
|
|
|
// we should always see a request routed based on the address
|
|
|
|
assert(pkt->getDest() == Packet::Broadcast);
|
|
|
|
assert(pkt->isRequest());
|
|
|
|
|
|
|
|
// forward to all snoopers
|
|
|
|
std::pair<MemCmd, Tick> snoop_result = forwardAtomic(pkt, INVALID_PORT_ID);
|
|
|
|
MemCmd snoop_response_cmd = snoop_result.first;
|
|
|
|
Tick snoop_response_latency = snoop_result.second;
|
|
|
|
|
|
|
|
if (snoop_response_cmd != MemCmd::InvalidCmd)
|
|
|
|
pkt->cmd = snoop_response_cmd;
|
|
|
|
|
|
|
|
pkt->finishTime = curTick() + snoop_response_latency;
|
|
|
|
return snoop_response_latency;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::pair<MemCmd, Tick>
|
|
|
|
Bus::forwardAtomic(PacketPtr pkt, int exclude_slave_port_id)
|
|
|
|
{
|
|
|
|
// the packet may be changed on snoops, record the original source
|
|
|
|
// and command to enable us to restore it between snoops so that
|
|
|
|
// additional snoops can take place properly
|
|
|
|
Packet::NodeID orig_src_id = pkt->getSrc();
|
2007-06-18 02:27:53 +02:00
|
|
|
MemCmd orig_cmd = pkt->cmd;
|
2007-07-02 10:02:35 +02:00
|
|
|
MemCmd snoop_response_cmd = MemCmd::InvalidCmd;
|
|
|
|
Tick snoop_response_latency = 0;
|
2006-11-14 07:12:52 +01:00
|
|
|
|
2007-06-18 02:27:53 +02:00
|
|
|
SnoopIter s_end = snoopPorts.end();
|
|
|
|
for (SnoopIter s_iter = snoopPorts.begin(); s_iter != s_end; s_iter++) {
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
BusSlavePort *p = *s_iter;
|
2012-03-22 11:37:21 +01: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
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
if (exclude_slave_port_id == INVALID_PORT_ID ||
|
|
|
|
p->getId() != exclude_slave_port_id) {
|
|
|
|
Tick latency = p->sendAtomicSnoop(pkt);
|
2012-03-22 11:37:21 +01:00
|
|
|
// in contrast to a functional access, we have to keep on
|
|
|
|
// going as all snoopers must be updated even if we get a
|
|
|
|
// response
|
2007-06-30 19:16:18 +02:00
|
|
|
if (pkt->isResponse()) {
|
2007-06-18 02:27:53 +02:00
|
|
|
// response from snoop agent
|
|
|
|
assert(pkt->cmd != orig_cmd);
|
|
|
|
assert(pkt->memInhibitAsserted());
|
|
|
|
// should only happen once
|
2007-07-02 10:02:35 +02:00
|
|
|
assert(snoop_response_cmd == MemCmd::InvalidCmd);
|
2007-06-18 02:27:53 +02:00
|
|
|
// save response state
|
2007-07-02 10:02:35 +02:00
|
|
|
snoop_response_cmd = pkt->cmd;
|
|
|
|
snoop_response_latency = latency;
|
2007-06-18 02:27:53 +02:00
|
|
|
// restore original packet state for remaining snoopers
|
|
|
|
pkt->cmd = orig_cmd;
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
pkt->setSrc(orig_src_id);
|
2007-06-30 19:16:18 +02:00
|
|
|
pkt->setDest(Packet::Broadcast);
|
2007-06-18 02:27:53 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +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);
|
|
|
|
}
|
2007-07-16 05:09:03 +02:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
void
|
|
|
|
Bus::recvFunctional(PacketPtr pkt)
|
|
|
|
{
|
|
|
|
if (!pkt->isPrint()) {
|
|
|
|
// don't do DPRINTFs on PrintReq as it clutters up the output
|
|
|
|
DPRINTF(Bus,
|
|
|
|
"recvFunctional: packet src %d dest %d addr 0x%x cmd %s\n",
|
|
|
|
pkt->getSrc(), pkt->getDest(), pkt->getAddr(),
|
|
|
|
pkt->cmdString());
|
2007-07-16 05:09:03 +02:00
|
|
|
}
|
2007-06-18 02:27:53 +02:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// we should always see a request routed based on the address
|
|
|
|
assert(pkt->getDest() == Packet::Broadcast);
|
|
|
|
assert(pkt->isRequest());
|
2007-06-18 02:27:53 +02:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// forward to all snoopers but the source
|
|
|
|
forwardFunctional(pkt, pkt->getSrc());
|
|
|
|
|
|
|
|
// 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()) {
|
|
|
|
int dest_id = findPort(pkt->getAddr());
|
|
|
|
|
|
|
|
masterPorts[dest_id]->sendFunctional(pkt);
|
|
|
|
}
|
2006-03-26 00:31:20 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
Bus::recvFunctionalSnoop(PacketPtr pkt)
|
2006-03-26 00:31:20 +01:00
|
|
|
{
|
2012-01-10 01:08:20 +01:00
|
|
|
if (!pkt->isPrint()) {
|
|
|
|
// don't do DPRINTFs on PrintReq as it clutters up the output
|
|
|
|
DPRINTF(Bus,
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
"recvFunctionalSnoop: packet src %d dest %d addr 0x%x cmd %s\n",
|
2012-03-22 11:37:21 +01:00
|
|
|
pkt->getSrc(), pkt->getDest(), pkt->getAddr(),
|
2012-01-10 01:08:20 +01:00
|
|
|
pkt->cmdString());
|
|
|
|
}
|
|
|
|
|
2012-03-22 11:37:21 +01:00
|
|
|
// we should always see a request routed based on the address
|
|
|
|
assert(pkt->getDest() == Packet::Broadcast);
|
|
|
|
assert(pkt->isRequest());
|
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// forward to all snoopers
|
|
|
|
forwardFunctional(pkt, INVALID_PORT_ID);
|
|
|
|
}
|
2007-07-25 07:37:41 +02:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
void
|
|
|
|
Bus::forwardFunctional(PacketPtr pkt, int exclude_slave_port_id)
|
|
|
|
{
|
2007-08-10 22:14:01 +02:00
|
|
|
SnoopIter s_end = snoopPorts.end();
|
|
|
|
for (SnoopIter s_iter = snoopPorts.begin(); s_iter != s_end; s_iter++) {
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
BusSlavePort *p = *s_iter;
|
2012-03-22 11:37:21 +01: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
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
if (exclude_slave_port_id == INVALID_PORT_ID ||
|
|
|
|
p->getId() != exclude_slave_port_id)
|
|
|
|
p->sendFunctionalSnoop(pkt);
|
2012-03-22 11:37:21 +01:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
// if we get a response we are done
|
|
|
|
if (pkt->isResponse()) {
|
|
|
|
break;
|
2012-03-22 11:37:21 +01:00
|
|
|
}
|
2006-11-14 01:56:34 +01:00
|
|
|
}
|
2006-03-26 00:31:20 +01:00
|
|
|
}
|
|
|
|
|
2012-01-17 19:55:09 +01:00
|
|
|
/** Function called by the port when the bus is receiving a range change.*/
|
2006-03-26 00:31:20 +01:00
|
|
|
void
|
2012-01-17 19:55:09 +01:00
|
|
|
Bus::recvRangeChange(int id)
|
2006-03-26 00:31:20 +01:00
|
|
|
{
|
2006-07-06 20:41:01 +02:00
|
|
|
AddrRangeList ranges;
|
|
|
|
AddrRangeIter iter;
|
|
|
|
|
2012-01-17 19:55:09 +01:00
|
|
|
if (inRecvRangeChange.count(id))
|
2007-08-10 22:14:01 +02:00
|
|
|
return;
|
2012-01-17 19:55:09 +01:00
|
|
|
inRecvRangeChange.insert(id);
|
2006-04-07 22:26:22 +02:00
|
|
|
|
2006-05-26 20:24:46 +02:00
|
|
|
DPRINTF(BusAddrRanges, "received RangeChange from device id %d\n", id);
|
2006-05-26 20:17:33 +02:00
|
|
|
|
2007-08-04 22:05:55 +02:00
|
|
|
clearPortCache();
|
2012-01-17 19:55:09 +01:00
|
|
|
if (id == defaultPortId) {
|
2006-07-06 20:41:01 +02:00
|
|
|
defaultRange.clear();
|
2006-11-02 21:20:37 +01:00
|
|
|
// Only try to update these ranges if the user set a default responder.
|
2010-08-17 14:06:21 +02:00
|
|
|
if (useDefaultRange) {
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
AddrRangeList ranges =
|
|
|
|
masterPorts[id]->getSlavePort().getAddrRanges();
|
2006-11-02 21:20:37 +01:00
|
|
|
for(iter = ranges.begin(); iter != ranges.end(); iter++) {
|
|
|
|
defaultRange.push_back(*iter);
|
|
|
|
DPRINTF(BusAddrRanges, "Adding range %#llx - %#llx for default range\n",
|
|
|
|
iter->start, iter->end);
|
|
|
|
}
|
2006-07-06 20:41:01 +02:00
|
|
|
}
|
|
|
|
} else {
|
2006-04-20 23:14:30 +02:00
|
|
|
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
assert(id < masterPorts.size() && id >= 0);
|
|
|
|
BusMasterPort *port = masterPorts[id];
|
2006-07-06 20:41:01 +02:00
|
|
|
|
|
|
|
// Clean out any previously existent ids
|
2007-05-22 08:36:09 +02:00
|
|
|
for (PortIter portIter = portMap.begin();
|
|
|
|
portIter != portMap.end(); ) {
|
2006-12-15 07:49:41 +01:00
|
|
|
if (portIter->second == id)
|
|
|
|
portMap.erase(portIter++);
|
2006-07-06 20:41:01 +02:00
|
|
|
else
|
|
|
|
portIter++;
|
|
|
|
}
|
2006-04-06 06:51:46 +02:00
|
|
|
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
ranges = port->getSlavePort().getAddrRanges();
|
2006-08-22 22:08:18 +02:00
|
|
|
|
2007-05-22 08:36:09 +02:00
|
|
|
for (iter = ranges.begin(); iter != ranges.end(); iter++) {
|
2006-08-28 18:55:13 +02:00
|
|
|
DPRINTF(BusAddrRanges, "Adding range %#llx - %#llx for id %d\n",
|
2006-12-15 07:49:41 +01:00
|
|
|
iter->start, iter->end, id);
|
2008-06-21 07:06:27 +02:00
|
|
|
if (portMap.insert(*iter, id) == portMap.end()) {
|
|
|
|
int conflict_id = portMap.find(*iter)->second;
|
|
|
|
fatal("%s has two ports with same range:\n\t%s\n\t%s\n",
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
name(), masterPorts[id]->getSlavePort().name(),
|
|
|
|
masterPorts[conflict_id]->getSlavePort().name());
|
2008-06-21 07:06:27 +02:00
|
|
|
}
|
2006-07-06 20:41:01 +02:00
|
|
|
}
|
2006-04-20 23:14:30 +02:00
|
|
|
}
|
2012-03-22 11:37:21 +01:00
|
|
|
DPRINTF(BusAddrRanges, "port list has %d entries\n", portMap.size());
|
2006-04-28 21:37:48 +02:00
|
|
|
|
|
|
|
// tell all our peers that our address range has changed.
|
|
|
|
// Don't tell the device that caused this change, it already knows
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
std::vector<BusSlavePort*>::const_iterator intIter;
|
2007-03-09 00:57:15 +01:00
|
|
|
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
for (intIter = slavePorts.begin(); intIter != slavePorts.end(); intIter++)
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
(*intIter)->sendRangeChange();
|
2006-07-06 20:41:01 +02:00
|
|
|
|
2012-01-17 19:55:09 +01:00
|
|
|
inRecvRangeChange.erase(id);
|
2006-03-26 00:31:20 +01:00
|
|
|
}
|
|
|
|
|
2012-01-17 19:55:09 +01:00
|
|
|
AddrRangeList
|
|
|
|
Bus::getAddrRanges(int id)
|
2006-03-26 00:31:20 +01:00
|
|
|
{
|
2012-01-17 19:55:09 +01:00
|
|
|
AddrRangeList ranges;
|
2006-04-28 21:37:48 +02:00
|
|
|
|
2006-05-26 20:24:46 +02:00
|
|
|
DPRINTF(BusAddrRanges, "received address range request, returning:\n");
|
2006-07-06 20:41:01 +02:00
|
|
|
|
2007-05-22 08:36:09 +02:00
|
|
|
for (AddrRangeIter dflt_iter = defaultRange.begin();
|
|
|
|
dflt_iter != defaultRange.end(); dflt_iter++) {
|
2012-01-17 19:55:09 +01:00
|
|
|
ranges.push_back(*dflt_iter);
|
2006-11-14 01:56:34 +01:00
|
|
|
DPRINTF(BusAddrRanges, " -- Dflt: %#llx : %#llx\n",dflt_iter->start,
|
2006-07-06 20:41:01 +02:00
|
|
|
dflt_iter->end);
|
|
|
|
}
|
2007-05-22 08:36:09 +02:00
|
|
|
for (PortIter portIter = portMap.begin();
|
|
|
|
portIter != portMap.end(); portIter++) {
|
|
|
|
bool subset = false;
|
|
|
|
for (AddrRangeIter dflt_iter = defaultRange.begin();
|
|
|
|
dflt_iter != defaultRange.end(); dflt_iter++) {
|
2006-12-15 07:49:41 +01:00
|
|
|
if ((portIter->first.start < dflt_iter->start &&
|
|
|
|
portIter->first.end >= dflt_iter->start) ||
|
|
|
|
(portIter->first.start < dflt_iter->end &&
|
|
|
|
portIter->first.end >= dflt_iter->end))
|
2006-07-06 20:41:01 +02:00
|
|
|
fatal("Devices can not set ranges that itersect the default set\
|
|
|
|
but are not a subset of the default set.\n");
|
2006-12-15 07:49:41 +01:00
|
|
|
if (portIter->first.start >= dflt_iter->start &&
|
|
|
|
portIter->first.end <= dflt_iter->end) {
|
2006-07-06 20:41:01 +02:00
|
|
|
subset = true;
|
2006-08-28 18:55:13 +02:00
|
|
|
DPRINTF(BusAddrRanges, " -- %#llx : %#llx is a SUBSET\n",
|
2006-12-15 07:49:41 +01:00
|
|
|
portIter->first.start, portIter->first.end);
|
2006-07-06 20:41:01 +02:00
|
|
|
}
|
|
|
|
}
|
2006-12-15 07:49:41 +01:00
|
|
|
if (portIter->second != id && !subset) {
|
2012-01-17 19:55:09 +01:00
|
|
|
ranges.push_back(portIter->first);
|
2006-08-28 18:55:13 +02:00
|
|
|
DPRINTF(BusAddrRanges, " -- %#llx : %#llx\n",
|
2006-12-15 07:49:41 +01:00
|
|
|
portIter->first.start, portIter->first.end);
|
2006-11-14 01:56:34 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-17 19:55:09 +01:00
|
|
|
return ranges;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
Bus::isSnooping(int id) const
|
2012-01-17 19:55:09 +01:00
|
|
|
{
|
2012-03-22 11:37:21 +01:00
|
|
|
// in essence, answer the question if there are snooping ports
|
|
|
|
return !snoopPorts.empty();
|
2006-03-26 00:31:20 +01:00
|
|
|
}
|
|
|
|
|
2009-06-05 08:21:12 +02:00
|
|
|
unsigned
|
2007-05-07 20:42:03 +02:00
|
|
|
Bus::findBlockSize(int id)
|
|
|
|
{
|
|
|
|
if (cachedBlockSizeValid)
|
|
|
|
return cachedBlockSize;
|
|
|
|
|
2009-06-05 08:21:12 +02:00
|
|
|
unsigned max_bs = 0;
|
2007-05-22 08:36:09 +02:00
|
|
|
|
2007-08-10 22:14:01 +02:00
|
|
|
PortIter p_end = portMap.end();
|
|
|
|
for (PortIter p_iter = portMap.begin(); p_iter != p_end; p_iter++) {
|
MEM: Introduce the master/slave port sub-classes in C++
This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.
The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.
The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.
The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.
2012-03-30 15:40:11 +02:00
|
|
|
unsigned tmp_bs = masterPorts[p_iter->second]->peerBlockSize();
|
2007-05-07 20:42:03 +02:00
|
|
|
if (tmp_bs > max_bs)
|
|
|
|
max_bs = tmp_bs;
|
|
|
|
}
|
2007-08-10 22:14:01 +02:00
|
|
|
SnoopIter s_end = snoopPorts.end();
|
|
|
|
for (SnoopIter s_iter = snoopPorts.begin(); s_iter != s_end; s_iter++) {
|
2009-06-05 08:21:12 +02:00
|
|
|
unsigned tmp_bs = (*s_iter)->peerBlockSize();
|
2007-05-07 20:42:03 +02:00
|
|
|
if (tmp_bs > max_bs)
|
|
|
|
max_bs = tmp_bs;
|
|
|
|
}
|
2009-06-05 08:21:12 +02:00
|
|
|
if (max_bs == 0)
|
2007-05-07 20:42:03 +02:00
|
|
|
max_bs = defaultBlockSize;
|
|
|
|
|
|
|
|
if (max_bs != 64)
|
|
|
|
warn_once("Blocksize found to not be 64... hmm... probably not.\n");
|
|
|
|
cachedBlockSize = max_bs;
|
|
|
|
cachedBlockSizeValid = true;
|
|
|
|
return max_bs;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-11-02 01:00:49 +01:00
|
|
|
unsigned int
|
|
|
|
Bus::drain(Event * de)
|
|
|
|
{
|
|
|
|
//We should check that we're not "doing" anything, and that noone is
|
|
|
|
//waiting. We might be idle but have someone waiting if the device we
|
|
|
|
//contacted for a retry didn't actually retry.
|
2012-03-22 11:37:21 +01:00
|
|
|
if (!retryList.empty() || (curTick() < tickNextIdle &&
|
|
|
|
busIdleEvent.scheduled())) {
|
2006-11-02 01:00:49 +01:00
|
|
|
drainEvent = de;
|
|
|
|
return 1;
|
|
|
|
}
|
2007-09-05 23:12:41 +02:00
|
|
|
return 0;
|
2006-11-02 01:00:49 +01:00
|
|
|
}
|
|
|
|
|
2007-06-10 08:01:47 +02:00
|
|
|
void
|
|
|
|
Bus::startup()
|
|
|
|
{
|
2011-01-08 06:50:29 +01:00
|
|
|
if (tickNextIdle < curTick())
|
|
|
|
tickNextIdle = (curTick() / clock) * clock + clock;
|
2007-06-10 08:01:47 +02:00
|
|
|
}
|
|
|
|
|
2007-07-24 06:51:38 +02:00
|
|
|
Bus *
|
|
|
|
BusParams::create()
|
2006-03-26 00:31:20 +01:00
|
|
|
{
|
2007-08-30 21:16:59 +02:00
|
|
|
return new Bus(this);
|
2006-03-26 00:31:20 +01:00
|
|
|
}
|