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 mentioned).
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. Steve On Sat, Aug 25, 2012 at 10:45 PM, Andreas Hansson <[email protected]>wrote: > Hi Nilay, > > 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. > > I would suggest: > > 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 > are welcome. > > 2) Progressively rebase some of the existing testers on the more generic > traffic generator. > > 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 > purely event-based. > > Andreas > > On 26/08/2012 00:40, "Nilay Vaish" <[email protected]> wrote: > > >On Sat, 25 Aug 2012, Ali Saidi wrote: > >> > >> Hi Nilay, > >> > >> 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 > >> repository. > >> > > > >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. > > > >-- > >Nilay > >_______________________________________________ > >gem5-dev mailing list > >[email protected] > >http://m5sim.org/mailman/listinfo/gem5-dev > > > > > -- 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 > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
