> On Dec. 10, 2014, 3:17 a.m., Joel Hestness wrote: > > src/mem/ruby/system/RubyPort.cc, line 372 > > <http://reviews.gem5.org/r/2549/diff/2/?file=42942#file42942line372> > > > > 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.
Ok, after another look there is indeed additional complications here due to the fact that we do not always pass the packet on to the "normal" port through schedTiming. I suggest we resolve the issue Steve highlighted before going any further with this patch. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/#review5658 ----------------------------------------------------------- On Dec. 9, 2014, 3:15 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2549/ > ----------------------------------------------------------- > > (Updated Dec. 9, 2014, 3:15 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10602:d3bb9d95bf76 > --------------------------- > ruby: ruby port: do not check for blocked ports > RubyPort used to maintain a list of blocked ports which are sent retries when > the port becomes unblocked. This is unnecessary since RubyPort's port > definitions > inherit from QueuedPort. > > > Diffs > ----- > > src/mem/ruby/system/RubyPort.hh 6efb37480d87 > src/mem/ruby/system/RubyPort.cc 6efb37480d87 > > Diff: http://reviews.gem5.org/r/2549/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
