It sounds like we are generally agreeing that we should, if at all
possible, only have a single traffic generator that is configurable to
generate all the patterns we might care about (including random and
trace-based generation, but also the more complex patterns Andreas
Not having looked at any of the code, it sounds to me like Andreas's new
traffic generator is more general than the one we currently have. If so,
then Andreas's plan to put his tester in and gradually migrate the
functionality of other testers over, eventually deleting the other testers,
makes sense. Nilay's comment about upgrading the existing testers is also
a reasonable path that would be worth considering if Andreas had not
already written a new tester, but I think the existence of Andreas's more
general framework makes that moot.
It's clear to me that this new traffic generator/tester belongs with the
other traffic generator/memory testers that are currently under
src/cpu/testers (and src/cpu/trace for trace readers). Historically, we've
had these things under src/cpu because they're "cpu-like", i.e., bus
masters driving the system, and particularly cpu-like in the situation
where they're replaying cpu traces. Another way to look at it is that a
system almost always has to have at least one component from under src/cpu
to be doing anything interesting, and from that perspective the tester is
clearly taking the place of a "regular" cpu.
I can see where a tester that's modeling some black-box device traffic
starts to stretch that concept, and I agree that src/mem/testers is an
equally reasonable place for things like this to live. However, I think
the most important thing is that all the similar modules should be in the
same place, and I'm not convinced that src/mem/testers is enough better
to warrant moving things around. If anyone feels strongly about this, feel
free to speak up.
On Sat, Aug 25, 2012 at 10:45 PM, Andreas Hansson
Post by Andreas Hansson
I see your point. However, there is currently nothing in gem5 to simulate
the "non-CPU" components in a System on Chip, and that is why we are
adding this traffic generator.
The framework based on the state graphs also enables us to e.g. add a
probabilistic behaviour in terms of graph traversal, and all the "vanilla"
network patterns (that have nothing at all to do with real lifeŠuniform
random, bit reversal, tornado etc) can also be generated if anyone
strongly feels like they add any value.
1) Get the new traffic generator in there. Perhaps src/mem is not the
right location, but it is definitely not a CPU or a tester, so suggestions
2) Progressively rebase some of the existing testers on the more generic
It is also worth noting that the existing testers are cycle callable (they
tick even when there is nothing to do) and the new traffic generator is
Post by Nilay Vaish Post by Andreas Hansson
I think the point that Andreas is trying to make is that traffic
generators are useful for more than testing and people want to to use
traffic generators to inject traffic into the systems (many systems have
lots of other traffic going through them, not just CPU traffic). The
traffic generator we posted lets the user specifies a configuration file
that describes what kind of traffic that generator will generate. You
can create infinite different configurations including one that emulates
an hdlcd controller, video encoders or decoders, etc. Anyone who is
interested in a client system should be interested in traffic from other
components in the system and this traffic generator is a good way to
produce some traffic for that purpose. It's far more configurable than
the testers that currently are in gem5.
The meta-question I have is, why do you care that much? It's a
reasonably small piece of code that is well documented and comes with a
set of regression tests. It seems like exactly the thing we want in the
Since we already have some traffic generators in place, we should be
upgrading those if possible. I would prefer if we have only a single way
to generate a given type of traffic.
gem5-dev mailing list
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
gem5-dev mailing list