----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/#review5658 -----------------------------------------------------------
src/mem/ruby/system/RubyPort.cc <http://reviews.gem5.org/r/2549/#comment5049> 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. - Joel Hestness 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
