> On May 13, 2015, 9:33 p.m., Andreas Hansson wrote: > > src/mem/ruby/system/RubyPort.cc, line 298 > > <http://reviews.gem5.org/r/2776/diff/1/?file=45140#file45140line298> > > > > I'd suggest to always send a retry, simply to comply with the timing > > protocol. This is extra important these days with bridging to SST and > > SystemC/TLM. > > > > The tester can simply ignore the retry if it does not care. > > Brad Beckmann wrote: > Not adding ports to the retry list while running the ruby tester is > behavior that already exists. This change simply added a generic variable to > turn on this behavior so that other testers can leverage the feature as well, > rather than assuming it is only used by the Ruby Tester. What you are > suggesting is to modify the Ruby Tester's basic assumptions. That goes > beyond this patch and would require significant modificaitons and testing of > both the public Ruby Tester and our internal testers. That is a lot of work > that goes well beyond this patch. > > Andreas Hansson wrote: > I am not suggesting to change any assumptions, merely that we have a > recvRetry in the tester port. It can be thrown away/empty. All I'm asking is > that we stick to the normal port conventions. It should be trivial to add.
As I said in my previous comment, not adding ports to the retry list while running the ruby tester is behaviour that already exists. I do not think the bar for allowing this patch to be checked in is to fix other bugs beyond the scope of this patch. What you are suggesting, should be a different patch. One that requires additional testing. Why are you putting up so much resistence to this change? > On May 13, 2015, 9:33 p.m., Andreas Hansson wrote: > > src/mem/ruby/system/RubyPort.cc, line 423 > > <http://reviews.gem5.org/r/2776/diff/1/?file=45140#file45140line423> > > > > In the crossbar we only send a single retry at a time. It used to look > > like this, but imho it makes no sense. Once one port goes ahead the > > RubyPort will be busy, will it not? > > Brad Beckmann wrote: > Actually, when we attach a GPU to the RubyPort we create on port per > work-item (lane of execution). Thus it is very common to retry many ports in > a single cycle. > > Andreas Hansson wrote: > May ports with different destinations make sense, I think my confusion > here is because the RubyPort is also an implicit crossbar. Actually, should > we not make the RubyPort 1:1 and rely on the interconnect Ruby or a CrossBar > to do the multiplexing. To me it seems this would solve a lot of the issues. We have a lot of code that relies on the RubyPort and its associated children objects to coalesce requests. The RubyPort is a natural place to coalesce because the port-RubyPort interface is a per request/address packet-based interface and Ruby's memory is cache-blocked based. - Brad ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2776/#review6249 ----------------------------------------------------------- On May 11, 2015, 10:28 p.m., Tony Gutierrez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2776/ > ----------------------------------------------------------- > > (Updated May 11, 2015, 10:28 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10833:e624796bae17 > --------------------------- > ruby: cleaner ruby tester support > > This patch allows the ruby random tester to use ruby ports that may only > support instr or data requests. This patch is similar to a previous changeset > (8932:1b2c17565ac8) that was unfortunately broken by subsequent changesets. > This current patch implements the support in a more straight-forward way. > The patch also includes better DPRINTFs and generalizes the retry behavior > needed by the ruby tester so that other testers/cpu models can use it as well. > > > Diffs > ----- > > configs/example/ruby_random_test.py > fbdaa08aaa426b9f4660c366f934ccb670d954ec > configs/ruby/MESI_Three_Level.py fbdaa08aaa426b9f4660c366f934ccb670d954ec > configs/ruby/MESI_Two_Level.py fbdaa08aaa426b9f4660c366f934ccb670d954ec > configs/ruby/MI_example.py fbdaa08aaa426b9f4660c366f934ccb670d954ec > configs/ruby/MOESI_CMP_directory.py > fbdaa08aaa426b9f4660c366f934ccb670d954ec > configs/ruby/MOESI_CMP_token.py fbdaa08aaa426b9f4660c366f934ccb670d954ec > configs/ruby/MOESI_hammer.py fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/cpu/testers/rubytest/Check.cc fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/cpu/testers/rubytest/CheckTable.cc > fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/cpu/testers/rubytest/RubyTester.hh > fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/cpu/testers/rubytest/RubyTester.cc > fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/cpu/testers/rubytest/RubyTester.py > fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/mem/packet_queue.cc fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/mem/ruby/system/RubyPort.hh fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/mem/ruby/system/RubyPort.cc fbdaa08aaa426b9f4660c366f934ccb670d954ec > src/mem/ruby/system/Sequencer.py fbdaa08aaa426b9f4660c366f934ccb670d954ec > > Diff: http://reviews.gem5.org/r/2776/diff/ > > > Testing > ------- > > > Thanks, > > Tony Gutierrez > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
