cpu: Stream/SubstreamID support in TrafficGen

This patch is adding support for generating memory requests which set
the StreamID/SubstreamID field, so that is possible to emulate devices
attached to an external IOMMU/SMMU with a Traffic generator.

Change-Id: Iea068de581ae7125a9d49314124a08c045c75b49
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12188

cpu: Add a Python-enabled traffic generator

The current traffic generator relies on a configuration file that
describes a small machine to generate stimuli. This configuration file
is usually generated by the gem5 Python configuration. This creates an
unnecessary and fragile step.

This changeset introduces a Python-based trace module. When
instantiated, the module exposes a start method that takes an iterable
object as a parameter (e.g., a generator). The iterable object is
expected to represent a list of generators that will be run one after
the other. For example:

system.tgen = PyTrafficGen()
m5.instantiate()

def trace():
yield system.tgen.createIdle(1000)
yield system.tgen.createExit(0)

system.tgen.start(trace())

Change-Id: I58e60ca517e86c197859f4daaa67750066abdc1c
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/11518
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>

cpu: Split the traffic generator into two classes

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

cpu-tester: Added ExitGen to TrafficGen

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>

cpu-tester: Refactoring traffic generators into separate files.

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>

cpu: Make the generators usable outside the TrafficGen module

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.

cpu: Add support for protobuf input for the trace generator

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.

TrafficGen: Add a basic traffic generator

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.