On Tue, Dec 9, 2014 at 7:17 PM, Joel Hestness via gem5-dev < gem5-dev@gem5.org> wrote:
> > So, I'm not sure I follow how this can work... The RubySequencer can > still block a request if (1) a master issues accesses in excess of the > sequencer's outstanding request count, or (2) the master issues an access > for a cache line with an existing outstanding access. Are there no mainline > gem5 masters (e.g. CPU cores) that rely on the retry signal to restart > injection after bumping up against either of these blocking conditions? > Gem5-gpu GPU LSQs currently rely on the Sequencer retry signals. I admit I am confused by the situation here too. As Alex mentioned in another post, we were not having any problems with the code that Nilay is removing here until we recently updated our tree, and we tracked our problems down to this changeset: http://repo.gem5.org/gem5/rev/6be8945d226b. I would like to see a definitive explanation that it's this code that's wrong and should be removed, and not this other changeset that's the problem, before we make any drastic changes like this. Steve _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
