summaryrefslogtreecommitdiff
path: root/src/mem/comm_monitor.cc
AgeCommit message (Collapse)Author
2013-02-19mem: Add predecessor to SenderState base classAndreas Hansson
This patch adds a predecessor field to the SenderState base class to make the process of linking them up more uniform, and enable a traversal of the stack without knowing the specific type of the subclasses. There are a number of simplifications done as part of changing the SenderState, particularly in the RubyTest.
2013-02-19mem: Ensure trace captures packet fields before forwardingAndreas Hansson
This patch fixes a bug in the CommMonitor caused by the packet being modified before it is captured in the trace. By recording the fields before passing the packet on, and then putting these values in the trace we ensure that even if the packet is modified the trace captures what the CommMonitor saw.
2013-01-07mem: Add tracing support in the communication monitorAndreas Hansson
This patch adds packet tracing to the communication monitor using a protobuf as the mechanism for creating the trace. If no file is specified, then the tracing is disabled. If a file is specified, then for every packet that is successfully sent, a protobuf message is serialized to the file.
2012-11-16sim: have a curTick per eventqNilay Vaish
This patch adds a _curTick variable to an eventq. This variable is updated whenever an event is serviced in function serviceOne(), or all events upto a particular time are processed in function serviceEvents(). This change helps when there are eventqs that do not make use of curTick for scheduling events.
2012-10-15Port: Add protocol-agnostic ports in the port hierarchyAndreas Hansson
This patch adds an additional level of ports in the inheritance hierarchy, separating out the protocol-specific and protocl-agnostic parts. All the functionality related to the binding of ports is now confined to use BaseMaster/BaseSlavePorts, and all the protocol-specific parts stay in the Master/SlavePort. In the future it will be possible to add other protocol-specific implementations. The functions used in the binding of ports, i.e. getMaster/SlavePort now use the base classes, and the index parameter is updated to use the PortID typedef with the symbolic InvalidPortID as the default.
2012-07-09Port: Make getAddrRanges constAndreas Hansson
This patch makes getAddrRanges const throughout the code base. There is no reason why it should not be, and making it const prevents adding any unintentional side-effects.
2012-07-09Port: Add getAddrRanges to master port (asking slave port)Andreas Hansson
This patch adds getAddrRanges to the master port, and thus avoids going through getSlavePort to be able to ask the slave. Similar to the previous patch that added isSnooping to the SlavePort, this patch aims to introduce an additional level of hierarchy in the ports (base port being protocol-agnostic) and getSlave/MasterPort will return port pointers to these base classes. The function is named getAddrRanges also on the master port, but does nothing besides asking the connected slave port. The slave port, as before, has to provide an implementation and actually produce a list of address ranges. The initial design used the name getSlaveAddrRanges for the new function, but the more verbose name was later changed.
2012-07-09Port: Add isSnooping to slave port (asking master port)Andreas Hansson
This patch adds isSnooping to the slave port, and thus avoids going through getMasterPort to be able to ask the master. Over the course of the next few patches, all getMasterPort/getSlavePort in Port and MemObject are to be protocol agnostic, and the snooping is part of the protocol layer. The function is already present on the master port, where it is implemented by the module itself, e.g. a cache. On the slave side, it is merely asking the connected master port. The same name is used by both functions despite their difference in behaviour. The initial design used isMasterSnooping on the slave port side, but the more verbose function name was later changed.
2012-05-09MEM: Add the communication monitorAndreas Hansson
This patch adds a communication monitor MemObject that can be inserted between a master and slave port to provide a range of statistics about the communication passing through it. The communication monitor is non-invasive and does not change any properties or timing of the packets, with the exception of adding a sender state to be able to track latency. The statistics are only collected in timing mode (not atomic) to avoid slowing down any fast forwarding. An example of the statistics captured by the monitor are: read/write burst lengths, bandwidth, request-response latency, outstanding transactions, inter transaction time, transaction count, and address distribution. The monitor can be used in combination with periodic resetting and dumping of stats (through schedStatEvent) to study the behaviour over time. In future patches, a selection of convenience scripts will be added to aid in visualising the statistics collected by the monitor.