summaryrefslogtreecommitdiff
path: root/src/cpu/testers/traffic_gen/traffic_gen.hh
AgeCommit message (Collapse)Author
2018-07-13cpu: Split the traffic generator into two classesAndreas Sandberg
The traffic generator currently assumes that it is always driven from a configuration file. Split it into a base class (BaseTrafficGen) that handles basic packet generation and a derived class that implements the config handling (TrafficGen). Change-Id: I9407f04c40ad7e40a263c8d1ef29d37ff8e6f1b4 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com> Reviewed-on: https://gem5-review.googlesource.com/11515
2017-12-19cpu-tester: Added ExitGen to TrafficGenRiken Gohil
Added the ExitGen to the TrafficGenerator which allows an EXIT state to be added to the TrafficGen configuration file. Entering this state will cause the simulation to exit immediately. Please note that if multiple TrafficGen instances have an EXIT state, the first of these to be encountered will cause the simulation to terminate. Change-Id: Ieea51f05ffb780771f007787a2b119f79143d0c1 Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5723 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2017-12-19cpu-tester: Refactoring traffic generators into separate files.Riken Gohil
Change-Id: I2372a0a88e276dcb0c06c3d0a789e010cfba8013 Reviewed-by: Matteo Andreozzi <matteo.andreozzi@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5722 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
2017-06-20cpu, gpu-compute: Replace EventWrapper use with EventFunctionWrapperSean Wilson
Change-Id: Idd5992463bcf9154f823b82461070d1f1842cea3 Signed-off-by: Sean Wilson <spwilson2@wisc.edu> Reviewed-on: https://gem5-review.googlesource.com/3746 Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com>
2016-06-20mem: Resolve TrafficGen trace relative to the configAndreas Sandberg
The traffic generator currently resolves relative trace paths relative to gem5's current working directory. This can lead to surprising results for relative paths where the expectation would normally be that they are resolved relative to the configuration file. This changeset implements config-relative trace file lookups. The old behavior is kept as a fallback for configs that expect that behavior. Change-Id: I1bda4e16725842666ffc37dcb6838c23a6ff138c Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
2016-05-26cpu: Add a basic progress check to the TrafficGenAndreas Hansson
This patch adds a progress check to the TrafficGen so that it is easier to detect deadlock scenarios where the generator gets stuck waiting for a retry, and makes no further progress. Change-Id: Ifb8779ad0939f52c0518d0e867bac73f99b82e2b Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Radhika Jagtap <radhika.jagtap@arm.com>
2016-03-20cpu: warn if TrafficGen is suppressing a large numer of packetsAndreas Hansson
Add a basic warning for every 10000 packet that is suppressed to alert the user.
2015-10-12misc: Add explicit overrides and fix other clang >= 3.5 issuesAndreas Hansson
This patch adds explicit overrides as this is now required when using "-Wall" with clang >= 3.5, the latter now part of the most recent XCode. The patch consequently removes "virtual" for those methods where "override" is added. The latter should be enough of an indication. As part of this patch, a few minor issues that clang >= 3.5 complains about are also resolved (unused methods and variables).
2015-10-12misc: Remove redundant compiler-specific definesAndreas Hansson
This patch moves away from using M5_ATTR_OVERRIDE and the m5::hashmap (and similar) abstractions, as these are no longer needed with gcc 4.7 and clang 3.1 as minimum compiler versions.
2015-07-07sim: Refactor and simplify the drain APIAndreas Sandberg
The drain() call currently passes around a DrainManager pointer, which is now completely pointless since there is only ever one global DrainManager in the system. It also contains vestiges from the time when SimObjects had to keep track of their child objects that needed draining. This changeset moves all of the DrainState handling to the Drainable base class and changes the drain() and drainResume() calls to reflect this. Particularly, the drain() call has been updated to take no parameters (the DrainManager argument isn't needed) and return a DrainState instead of an unsigned integer (there is no point returning anything other than 0 or 1 any more). Drainable objects should return either DrainState::Draining (equivalent to returning 1 in the old system) if they need more time to drain or DrainState::Drained (equivalent to returning 0 in the old system) if they are already in a consistent state. Returning DrainState::Running is considered an error. Drain done signalling is now done through the signalDrainDone() method in the Drainable class instead of using the DrainManager directly. The new call checks if the state of the object is DrainState::Draining before notifying the drain manager. This means that it is safe to call signalDrainDone() without first checking if the simulator has requested draining. The intention here is to reduce the code needed to implement draining in simple objects.
2015-07-07sim: Refactor the serialization base classAndreas Sandberg
Objects that are can be serialized are supposed to inherit from the Serializable class. This class is meant to provide a unified API for such objects. However, so far it has mainly been used by SimObjects due to some fundamental design limitations. This changeset redesigns to the serialization interface to make it more generic and hide the underlying checkpoint storage. Specifically: * Add a set of APIs to serialize into a subsection of the current object. Previously, objects that needed this functionality would use ad-hoc solutions using nameOut() and section name generation. In the new world, an object that implements the interface has the methods serializeSection() and unserializeSection() that serialize into a named /subsection/ of the current object. Calling serialize() serializes an object into the current section. * Move the name() method from Serializable to SimObject as it is no longer needed for serialization. The fully qualified section name is generated by the main serialization code on the fly as objects serialize sub-objects. * Add a scoped ScopedCheckpointSection helper class. Some objects need to serialize data structures, that are not deriving from Serializable, into subsections. Previously, this was done using nameOut() and manual section name generation. To simplify this, this changeset introduces a ScopedCheckpointSection() helper class. When this class is instantiated, it adds a new /subsection/ and subsequent serialization calls during the lifetime of this helper class happen inside this section (or a subsection in case of nested sections). * The serialize() call is now const which prevents accidental state manipulation during serialization. Objects that rely on modifying state can use the serializeOld() call instead. The default implementation simply calls serialize(). Note: The old-style calls need to be explicitly called using the serializeOld()/serializeSectionOld() style APIs. These are used by default when serializing SimObjects. * Both the input and output checkpoints now use their own named types. This hides underlying checkpoint implementation from objects that need checkpointing and makes it easier to change the underlying checkpoint storage code.
2015-03-02mem: Split port retry for all different packet classesAndreas Hansson
This patch fixes a long-standing isue with the port flow control. Before this patch the retry mechanism was shared between all different packet classes. As a result, a snoop response could get stuck behind a request waiting for a retry, even if the send/recv functions were split. This caused message-dependent deadlocks in stress-test scenarios. The patch splits the retry into one per packet (message) class. Thus, sendTimingReq has a corresponding recvReqRetry, sendTimingResp has recvRespRetry etc. Most of the changes to the code involve simply clarifying what type of request a specific object was accepting. The biggest change in functionality is in the cache downstream packet queue, facing the memory. This queue was shared by requests and snoop responses, and it is now split into two queues, each with their own flow control, but the same physical MasterPort. These changes fixes the previously seen deadlocks.
2015-02-16cpu: TrafficGen sinks snoops without complainingAndreas Hansson
To be able to use the TrafficGen in a system with caches we need to allow it to sink incoming snoop requests. By default the master port panics, so silently ignore any snoops.
2013-05-30cpu: Add request elasticity to the traffic generatorAndreas Hansson
This patch adds an optional request elasticity to the traffic generator, effectievly compensating for it in the case of the linear and random generators, and adding it in the case of the trace generator. The accounting is left with the top-level traffic generator, and the individual generators do the necessary math as part of determining the next packet tick. Note that in the linear and random generators we have to compensate for the blocked time to not be elastic, i.e. without this patch the aforementioned generators will slow down in the case of back-pressure.
2013-05-30cpu: Block traffic generator when requests have to retryAndreas Hansson
This patch changes the queued port for a conventional master port and stalls the traffic generator when requests are not immediately accepted. This is a first step to allowing elasticity in the injection of requests. The patch also adds stats for the sent packets and retries, and slightly changes how the nextPacketTick and getNextPacket interact. The advancing of the trace is now moved to getNextPacket and nextPacketTick is only responsible for answering the question when the next packet should be sent.
2013-05-30cpu: Move traffic generator sending out of generator statesAndreas Hansson
This patch moves the responsibility for sending packets out of the generator states and leaves it with the top-level traffic generator. The main aim of this patch is to enable a transition to non-queued ports, i.e. with send/retry flow control, and to do so it is much more convenient to not wrap the port interactions and instead leave it all local to the traffic generator. The generator states now only govern when they are ready to send something new, and the generation of the packets to send. They thus have no knowledge of the port that is used.
2013-05-30cpu: Fold together the StateGraph and the TrafficGenAndreas Hansson
This patch simplifies the object hierarchy of the traffic generator by getting rid of the StateGraph class and folding this functionality into the traffic generator itself. The main goal of this patch is to facilitate upcoming changes by reducing the number of affected layers.
2013-04-22cpu: Make the generators usable outside the TrafficGen moduleAndreas Hansson
This patch enables the use of the generator behaviours outside the TrafficGen module. This is useful e.g. to allow packet replay modes for other devices in the system without having to replace them with a TrafficGen in the configuration files. This change also enables more specific behaviours to be composed as specific modules, e.g. BaseBandModem can use a number of generators and have application-specific parameters based around a specific set of generators.
2013-02-19scons: Fix warnings issued by clang 3.2svn (XCode 4.6)Andreas Hansson
This patch fixes the warnings that clang3.2svn emit due to the "-Wall" flag. There is one case of an uninitialised value in the ARM neon ISA description, and then a whole range of unused private fields that are pruned.
2013-01-07cpu: Share the send functionality between traffic generatorsAndreas Hansson
This patch moves the packet creating and sending to a member function in the shared base class to avoid code duplication.
2013-01-07cpu: Add support for protobuf input for the trace generatorAndreas Hansson
This patch adds support for reading input traces encoded using protobuf according to what is done in the CommMonitor. A follow-up patch adds a Python script that can be used to convert the previously used ASCII traces to protobuf equivalents. The appropriate regression input is updated as part of this patch.
2013-01-07cpu: Encapsulate traffic generator input in a streamAndreas Hansson
This patch encapsulates the traffic generator input in a stream class such that the parsing is not visible to the trace generator. The change takes us one step closer to using protobuf-based input traces for the trace replay. The functionality of the current input stream is identical to what it was, and the ASCII format remains the same for now.
2012-11-02sim: Move the draining interface into a separate base classAndreas Sandberg
This patch moves the draining interface from SimObject to a separate class that can be used by any object needing draining. However, objects not visible to the Python code (i.e., objects not deriving from SimObject) still depend on their parents informing them when to drain. This patch also gets rid of the CountedDrainEvent (which isn't really an event) and replaces it with a DrainManager.
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-09-21TrafficGen: Add a basic traffic generatorAndreas Hansson
This patch adds a traffic generator to the code base. The generator is aimed to be used as a black box model to create appropriate use-cases and benchmarks for the memory system, and in particular the interconnect and the memory controller. The traffic generator is a master module, where the actual behaviour is captured in a state-transition graph where each state generates some sort of traffic. By constructing a graph it is possible to create very elaborate scenarios from basic generators. Currencly the set of generators include idling, linear address sweeps, random address sequences and playback of traces (recording will be done by the Communication Monitor in a follow-up patch). At the moment the graph and the states are described in an ad-hoc line-based format, and in the future this should be aligned with our used of e.g. the Google protobufs. Similarly for the traces, the format is currently a simplistic ad-hoc line-based format that merely serves as a starting point. In addition to being used as a black-box model for system components, the traffic generator is also useful for creating test cases and regressions for the interconnect and memory system. In future patches we will use the traffic generator to create DRAM test cases for the controller model. The patch following this one adds a basic regressions which also contains an example configuration script and trace file for playback.