gem5/src/mem/bus.hh

410 lines
14 KiB
C++
Raw Normal View History

/*
* Copyright (c) 2011-2013 ARM Limited
* All rights reserved
*
* The license below extends only to copyright in the software and shall
* not be construed as granting a license to any other intellectual
* property including but not limited to intellectual property relating
* to a hardware implementation of the functionality of the software
* licensed hereunder. You may use the software subject to the license
* terms below provided that you ensure that this notice is replicated
* unmodified and in its entirety in all distributions of the software,
* modified or unmodified, in source code or in binary form.
*
* Copyright (c) 2002-2005 The Regents of The University of Michigan
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
* met: redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer;
* redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution;
* neither the name of the copyright holders nor the names of its
* contributors may be used to endorse or promote products derived from
* this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* Authors: Ron Dreslinski
* Ali Saidi
* Andreas Hansson
* William Wang
*/
/**
* @file
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
* Declaration of an abstract bus base class.
*/
#ifndef __MEM_BUS_HH__
#define __MEM_BUS_HH__
#include <deque>
#include "base/addr_range_map.hh"
#include "base/types.hh"
#include "mem/mem_object.hh"
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
#include "params/BaseBus.hh"
#include "sim/stats.hh"
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
/**
* The base bus contains the common elements of the non-coherent and
* coherent bus. It is an abstract class that does not have any of the
* functionality relating to the actual reception and transmission of
* packets, as this is left for the subclasses.
*
* The BaseBus is responsible for the basic flow control (busy or
* not), the administration of retries, and the address decoding.
*/
class BaseBus : public MemObject
{
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
protected:
/**
* A bus layer is an internal bus structure with its own flow
* control and arbitration. Hence, a single-layer bus mimics a
* traditional off-chip tri-state bus (like PCI), where only one
* set of wires are shared. For on-chip buses, a good starting
* point is to have three layers, for requests, responses, and
* snoop responses respectively (snoop requests are instantaneous
* and do not need any flow control or arbitration). This case is
* similar to AHB and some OCP configurations.
*
* As a further extensions beyond the three-layer bus, a future
* multi-layer bus has with one layer per connected slave port
* provides a full or partial crossbar, like AXI, OCP, PCIe etc.
*
* The template parameter, PortClass, indicates the destination
* port type for the bus. The retry list holds either master ports
* or slave ports, depending on the direction of the layer. Thus,
* a request layer has a retry list containing slave ports,
* whereas a response layer holds master ports.
*/
template <typename SrcType, typename DstType>
class Layer : public Drainable
{
public:
/**
* Create a bus layer and give it a name. The bus layer uses
* the bus an event manager.
*
* @param _port destination port the layer converges at
* @param _bus the bus this layer belongs to
* @param _name the layer's name
*/
Layer(DstType& _port, BaseBus& _bus, const std::string& _name);
/**
* Drain according to the normal semantics, so that the bus
* can tell the layer to drain, and pass an event to signal
* back when drained.
*
* @param de drain event to call once drained
*
* @return 1 if busy or waiting to retry, or 0 if idle
*/
unsigned int drain(DrainManager *dm);
/**
* Get the bus layer's name
*/
const std::string name() const { return bus.name() + _name; }
/**
* Determine if the bus layer accepts a packet from a specific
* port. If not, the port in question is also added to the
* retry list. In either case the state of the layer is
* updated accordingly.
*
* @param port Source port presenting the packet
*
* @return True if the bus layer accepts the packet
*/
bool tryTiming(SrcType* src_port);
/**
* Deal with a destination port accepting a packet by potentially
* removing the source port from the retry list (if retrying) and
* occupying the bus layer accordingly.
*
* @param busy_time Time to spend as a result of a successful send
*/
void succeededTiming(Tick busy_time);
/**
* Deal with a destination port not accepting a packet by
* potentially adding the source port to the retry list (if
* not already at the front) and occupying the bus layer
* accordingly.
*
* @param src_port Source port
* @param busy_time Time to spend as a result of a failed send
*/
void failedTiming(SrcType* src_port, Tick busy_time);
/** Occupy the bus layer until until */
void occupyLayer(Tick until);
/**
* Send a retry to the port at the head of waitingForLayer. The
* caller must ensure that the list is not empty.
*/
void retryWaiting();
/**
* Handle a retry from a neighbouring module. This wraps
* retryWaiting by verifying that there are ports waiting
* before calling retryWaiting.
*/
void recvRetry();
/**
* Register stats for the layer
*/
void regStats();
private:
/** The destination port this layer converges at. */
DstType& port;
/** The bus this layer is a part of. */
BaseBus& bus;
/** A name for this layer. */
std::string _name;
/**
* We declare an enum to track the state of the bus layer. The
* starting point is an idle state where the bus layer is
* waiting for a packet to arrive. Upon arrival, the bus layer
* transitions to the busy state, where it remains either
* until the packet transfer is done, or the header time is
* spent. Once the bus layer leaves the busy state, it can
* either go back to idle, if no packets have arrived while it
* was busy, or the bus layer goes on to retry the first port
* in waitingForLayer. A similar transition takes place from
* idle to retry if the bus layer receives a retry from one of
* its connected ports. The retry state lasts until the port
* in questions calls sendTiming and returns control to the
* bus layer, or goes to a busy state if the port does not
* immediately react to the retry by calling sendTiming.
*/
enum State { IDLE, BUSY, RETRY };
/** track the state of the bus layer */
State state;
/** manager to signal when drained */
DrainManager *drainManager;
/**
* A deque of ports that retry should be called on because
* the original send was delayed due to a busy layer.
*/
std::deque<SrcType*> waitingForLayer;
/**
* Port that we are currently in the process of telling to
* retry a previously failed attempt to perform a timing
* transaction. This is a valid port when in the retry state,
* and NULL when in busy or idle.
*/
SrcType* retryingPort;
/**
* Track who is waiting for the retry when receiving it from a
* peer. If no port is waiting NULL is stored.
*/
SrcType* waitingForPeer;
/**
* Release the bus layer after being occupied and return to an
* idle state where we proceed to send a retry to any
* potential waiting port, or drain if asked to do so.
*/
void releaseLayer();
/** event used to schedule a release of the layer */
EventWrapper<Layer, &Layer::releaseLayer> releaseEvent;
/**
* Stats for occupancy and utilization. These stats capture
* the time the bus spends in the busy state and are thus only
* relevant when the memory system is in timing mode.
*/
Stats::Scalar occupancy;
Stats::Formula utilization;
};
/** cycles of overhead per transaction */
const Cycles headerCycles;
/** the width of the bus in bytes */
const uint32_t width;
typedef AddrRangeMap<PortID>::iterator PortMapIter;
typedef AddrRangeMap<PortID>::const_iterator PortMapConstIter;
AddrRangeMap<PortID> portMap;
/** all contigous ranges seen by this bus */
AddrRangeList busRanges;
AddrRange defaultRange;
/**
* Function called by the port when the bus is recieving a range change.
*
* @param master_port_id id of the port that received the change
*/
void recvRangeChange(PortID master_port_id);
/** Find which port connected to this bus (if any) should be given a packet
* with this address.
* @param addr Address to find port for.
* @return id of port that the packet should be sent out of.
*/
PortID findPort(Addr addr);
// Cache for the findPort function storing recently used ports from portMap
struct PortCache {
bool valid;
PortID id;
AddrRange range;
};
PortCache portCache[3];
// Checks the cache and returns the id of the port that has the requested
// address within its range
inline PortID checkPortCache(Addr addr) const {
if (portCache[0].valid && portCache[0].range.contains(addr)) {
return portCache[0].id;
}
if (portCache[1].valid && portCache[1].range.contains(addr)) {
return portCache[1].id;
}
if (portCache[2].valid && portCache[2].range.contains(addr)) {
return portCache[2].id;
}
return InvalidPortID;
}
// Clears the earliest entry of the cache and inserts a new port entry
inline void updatePortCache(short id, const AddrRange& range) {
portCache[2].valid = portCache[1].valid;
portCache[2].id = portCache[1].id;
portCache[2].range = portCache[1].range;
portCache[1].valid = portCache[0].valid;
portCache[1].id = portCache[0].id;
portCache[1].range = portCache[0].range;
portCache[0].valid = true;
portCache[0].id = id;
portCache[0].range = range;
}
// Clears the cache. Needs to be called in constructor.
inline void clearPortCache() {
portCache[2].valid = false;
portCache[1].valid = false;
portCache[0].valid = false;
}
/**
* Return the address ranges the bus is responsible for.
*
* @return a list of non-overlapping address ranges
*/
AddrRangeList getAddrRanges() const;
/**
* Calculate the timing parameters for the packet. Updates the
* busFirstWordDelay and busLastWordDelay fields of the packet
* object with the relative number of ticks required to transmit
* the header and the first word, and the last word, respectively.
*/
void calcPacketTiming(PacketPtr pkt);
/**
* Remember for each of the master ports of the bus if we got an
* address range from the connected slave. For convenience, also
* keep track of if we got ranges from all the slave modules or
* not.
*/
std::vector<bool> gotAddrRanges;
bool gotAllAddrRanges;
/** The master and slave ports of the bus */
std::vector<SlavePort*> slavePorts;
std::vector<MasterPort*> masterPorts;
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
/** Convenience typedefs. */
typedef std::vector<SlavePort*>::iterator SlavePortIter;
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
typedef std::vector<MasterPort*>::iterator MasterPortIter;
typedef std::vector<SlavePort*>::const_iterator SlavePortConstIter;
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
typedef std::vector<MasterPort*>::const_iterator MasterPortConstIter;
Add default responder to bus Update configuration for new default responder on bus Update to devices to handle their own pci config space without pciconfigall Remove most of pciconfigall, it now is a dumbdevice which gets it's address based on the bus it's supposed to respond for Remove need for pci config space from platform, add registerPciDevice function to prevent more than one device from having same bus:dev:func and interrupt Remove pciconfigspace from pci devices, and py files Add calcConfigAddr that returns address for config space based on bus/dev/function + offset configs/test/fs.py: Update configuration for new default responder on bus src/dev/ide_ctrl.cc: src/dev/ide_ctrl.hh: src/dev/ns_gige.cc: src/dev/ns_gige.hh: src/dev/pcidev.cc: src/dev/pcidev.hh: Update to handle it's own pci config space without pciconfigall src/dev/io_device.cc: src/dev/io_device.hh: change naming for pio port break out recvTiming into two functions to reuse code src/dev/pciconfigall.cc: src/dev/pciconfigall.hh: removing most of pciconfigall, it now is a dumbdevice which gets it's address based on the bus it's supposed to respond for src/dev/pcireg.h: add a max size for PCI config space (per PCI spec) src/dev/platform.cc: src/dev/platform.hh: remove need for pci config space from platform, add registerPciDevice function to prevent more than one device from having same bus:dev:func and interrupt src/dev/sinic.cc: remove pciconfigspace as it's no longer a needed parameter src/dev/tsunami.cc: src/dev/tsunami.hh: src/dev/tsunami_pchip.cc: src/dev/tsunami_pchip.hh: add calcConfigAddr that returns address for config space based on bus/dev/function + offset (per PCI spec) src/mem/bus.cc: src/mem/bus.hh: src/python/m5/objects/Bus.py: add idea of default responder to bus src/python/m5/objects/Pci.py: add config port for pci devices add latency, bus and size parameters for pci config all (min is 8MB, max is 256MB see pci spec) --HG-- extra : convert_revision : 99db43b0a3a077f86611d6eaff6664a3885da7c9
2006-07-06 20:41:01 +02:00
/** Port that handles requests that don't match any of the interfaces.*/
PortID defaultPortID;
Add default responder to bus Update configuration for new default responder on bus Update to devices to handle their own pci config space without pciconfigall Remove most of pciconfigall, it now is a dumbdevice which gets it's address based on the bus it's supposed to respond for Remove need for pci config space from platform, add registerPciDevice function to prevent more than one device from having same bus:dev:func and interrupt Remove pciconfigspace from pci devices, and py files Add calcConfigAddr that returns address for config space based on bus/dev/function + offset configs/test/fs.py: Update configuration for new default responder on bus src/dev/ide_ctrl.cc: src/dev/ide_ctrl.hh: src/dev/ns_gige.cc: src/dev/ns_gige.hh: src/dev/pcidev.cc: src/dev/pcidev.hh: Update to handle it's own pci config space without pciconfigall src/dev/io_device.cc: src/dev/io_device.hh: change naming for pio port break out recvTiming into two functions to reuse code src/dev/pciconfigall.cc: src/dev/pciconfigall.hh: removing most of pciconfigall, it now is a dumbdevice which gets it's address based on the bus it's supposed to respond for src/dev/pcireg.h: add a max size for PCI config space (per PCI spec) src/dev/platform.cc: src/dev/platform.hh: remove need for pci config space from platform, add registerPciDevice function to prevent more than one device from having same bus:dev:func and interrupt src/dev/sinic.cc: remove pciconfigspace as it's no longer a needed parameter src/dev/tsunami.cc: src/dev/tsunami.hh: src/dev/tsunami_pchip.cc: src/dev/tsunami_pchip.hh: add calcConfigAddr that returns address for config space based on bus/dev/function + offset (per PCI spec) src/mem/bus.cc: src/mem/bus.hh: src/python/m5/objects/Bus.py: add idea of default responder to bus src/python/m5/objects/Pci.py: add config port for pci devices add latency, bus and size parameters for pci config all (min is 8MB, max is 256MB see pci spec) --HG-- extra : convert_revision : 99db43b0a3a077f86611d6eaff6664a3885da7c9
2006-07-06 20:41:01 +02:00
/** If true, use address range provided by default device. Any
address not handled by another port and not in default device's
range will cause a fatal error. If false, just send all
addresses not handled by another port to default device. */
const bool useDefaultRange;
Bus: Split the bus into a non-coherent and coherent bus This patch introduces a class hierarchy of buses, a non-coherent one, and a coherent one, splitting the existing bus functionality. By doing so it also enables further specialisation of the two types of buses. A non-coherent bus connects a number of non-snooping masters and slaves, and routes the request and response packets based on the address. The request packets issued by the master connected to a non-coherent bus could still snoop in caches attached to a coherent bus, as is the case with the I/O bus and memory bus in most system configurations. No snoops will, however, reach any master on the non-coherent bus itself. The non-coherent bus can be used as a template for modelling PCI, PCIe, and non-coherent AMBA and OCP buses, and is typically used for the I/O buses. A coherent bus connects a number of (potentially) snooping masters and slaves, and routes the request and response packets based on the address, and also forwards all requests to the snoopers and deals with the snoop responses. The coherent bus can be used as a template for modelling QPI, HyperTransport, ACE and coherent OCP buses, and is typically used for the L1-to-L2 buses and as the main system interconnect. The configuration scripts are updated to use a NoncoherentBus for all peripheral and I/O buses. A bit of minor tidying up has also been done. --HG-- rename : src/mem/bus.cc => src/mem/coherent_bus.cc rename : src/mem/bus.hh => src/mem/coherent_bus.hh rename : src/mem/bus.cc => src/mem/noncoherent_bus.cc rename : src/mem/bus.hh => src/mem/noncoherent_bus.hh
2012-05-31 19:30:04 +02:00
BaseBus(const BaseBusParams *p);
virtual ~BaseBus();
/**
* Stats for transaction distribution and data passing through the
* bus. The transaction distribution is globally counting
* different types of commands. The packet count and total packet
* size are two-dimensional vectors that are indexed by the bus
* slave port and master port id (thus the neighbouring master and
* neighbouring slave), summing up both directions (request and
* response).
*/
Stats::Formula throughput;
Stats::Vector transDist;
Stats::Vector2d pktCount;
Stats::Vector2d totPktSize;
public:
virtual void init();
/** A function used to return the port associated with this bus object. */
BaseMasterPort& getMasterPort(const std::string& if_name,
PortID idx = InvalidPortID);
BaseSlavePort& getSlavePort(const std::string& if_name,
PortID idx = InvalidPortID);
virtual unsigned int drain(DrainManager *dm) = 0;
virtual void regStats();
};
#endif //__MEM_BUS_HH__