> On Aug. 24, 2014, 2:25 p.m., Andreas Hansson wrote: > > build_opts/NULL, line 3 > > <http://reviews.gem5.org/r/2348/diff/1/?file=40720#file40720line3> > > > > Could you elaborate on this one? > > > > Are we also transitioning the Ruby tests to use the NULL ISA?
No. I don't recall right now why I added this line. I'll check again whether this line is required or not. > On Aug. 24, 2014, 2:25 p.m., Andreas Hansson wrote: > > src/cpu/testers/traffic_gen/generators.cc, line 304 > > <http://reviews.gem5.org/r/2348/diff/1/?file=40729#file40729line304> > > > > This probably breaks a bunch of python scripts as well? Well, the code compiles cleanly and I did not see any python script that uses the namespace Message. I am willing to fix any script that you think may not work because of this change. You would need to tell me which ones should to test and how. > On Aug. 24, 2014, 2:25 p.m., Andreas Hansson wrote: > > src/mem/ruby/slicc_interface/AbstractController.hh, line 52 > > <http://reviews.gem5.org/r/2348/diff/1/?file=40774#file40774line52> > > > > Is this a bug fix? I think this is not required now. Earlier I was attempting some different approach where this was required. I am removing this change. On Aug. 24, 2014, 2:25 p.m., Nilay Vaish wrote: > > I'm not sure I understand how the MessageBuffer relates to the existing > > ports in gem5. Is a MessageBuffer a kind of channel in TLM terminology? > > Would it not be possible to make the buffer either input or output and then > > simply connect the ports? Perhaps I'm missing something here as I'm not too > > familiar with Ruby. A MessageBuffer is a one way queue of messages between two entities. I am unable to understand the suggestion that you make. With this patch we are moving to the way we connect entities in the rest of the gem5 i.e. through ports. Till now, controllers in ruby did not have any notion of gem5's ports. In pyobject.cc, we now create the required message buffer and then bind it to the entities. This is only slightly different from what entities that directly connect via ports do. Ultimately, we might drop MessageBuffers altogether and just rely on ports. But that's not happening any time soon. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2348/#review5298 ----------------------------------------------------------- On Aug. 16, 2014, 1:17 a.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2348/ > ----------------------------------------------------------- > > (Updated Aug. 16, 2014, 1:17 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10292:ca80c52fa694 > --------------------------- > ruby: message buffers: significant changes > > This patch is the final patch in a series of patches. The aim of the series > is to make ruby more configurable than it was. More specifically, the > connections between controllers are not at all possible (unless one is ready > to make significant changes to the coherence protocol). Moreover the buffers > themselves are magically connected to the network inside the slicc code. > These connections are not part of the configuration file. > > This patch makes changes so that these connections will now be made in the > python configuration files associated with the protocols. This requires > each state machine to expose the message buffers it uses for input and output. > So, the patch makes these buffers configurable members of the machines. > > The patch drops the slicc code that usd to connect these buffers to the > network. Now these buffers are exposed to the python configuration system > as Master and Slave ports. In the configuration files, any master port > can be connected any slave port. The file pyobject.cc has been modified to > take care of allocating the actual message buffer. This is inline with how > other port connections work. > > > Diffs > ----- > > build_opts/NULL 79fde1c67ed8 > configs/ruby/MESI_Three_Level.py 79fde1c67ed8 > configs/ruby/MESI_Two_Level.py 79fde1c67ed8 > configs/ruby/MI_example.py 79fde1c67ed8 > configs/ruby/MOESI_CMP_directory.py 79fde1c67ed8 > configs/ruby/MOESI_CMP_token.py 79fde1c67ed8 > configs/ruby/MOESI_hammer.py 79fde1c67ed8 > configs/ruby/Network_test.py 79fde1c67ed8 > configs/ruby/Ruby.py 79fde1c67ed8 > src/cpu/testers/traffic_gen/generators.cc 79fde1c67ed8 > src/mem/comm_monitor.cc 79fde1c67ed8 > src/mem/protocol/MESI_Three_Level-L0cache.sm 79fde1c67ed8 > src/mem/protocol/MESI_Three_Level-L1cache.sm 79fde1c67ed8 > src/mem/protocol/MESI_Two_Level-L1cache.sm 79fde1c67ed8 > src/mem/protocol/MESI_Two_Level-L2cache.sm 79fde1c67ed8 > src/mem/protocol/MESI_Two_Level-dir.sm 79fde1c67ed8 > src/mem/protocol/MESI_Two_Level-dma.sm 79fde1c67ed8 > src/mem/protocol/MI_example-cache.sm 79fde1c67ed8 > src/mem/protocol/MI_example-dir.sm 79fde1c67ed8 > src/mem/protocol/MI_example-dma.sm 79fde1c67ed8 > src/mem/protocol/MOESI_CMP_directory-L1cache.sm 79fde1c67ed8 > src/mem/protocol/MOESI_CMP_directory-L2cache.sm 79fde1c67ed8 > src/mem/protocol/MOESI_CMP_directory-dir.sm 79fde1c67ed8 > src/mem/protocol/MOESI_CMP_directory-dma.sm 79fde1c67ed8 > src/mem/protocol/MOESI_CMP_token-L1cache.sm 79fde1c67ed8 > src/mem/protocol/MOESI_CMP_token-L2cache.sm 79fde1c67ed8 > src/mem/protocol/MOESI_CMP_token-dir.sm 79fde1c67ed8 > src/mem/protocol/MOESI_CMP_token-dma.sm 79fde1c67ed8 > src/mem/protocol/MOESI_hammer-cache.sm 79fde1c67ed8 > src/mem/protocol/MOESI_hammer-dir.sm 79fde1c67ed8 > src/mem/protocol/MOESI_hammer-dma.sm 79fde1c67ed8 > src/mem/protocol/Network_test-cache.sm 79fde1c67ed8 > src/mem/protocol/Network_test-dir.sm 79fde1c67ed8 > src/mem/ruby/SConscript 79fde1c67ed8 > src/mem/ruby/network/Network.hh 79fde1c67ed8 > src/mem/ruby/network/Network.cc 79fde1c67ed8 > src/mem/ruby/network/Network.py 79fde1c67ed8 > src/mem/ruby/network/garnet/BaseGarnetNetwork.hh 79fde1c67ed8 > src/mem/ruby/network/garnet/BaseGarnetNetwork.cc 79fde1c67ed8 > src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.hh > 79fde1c67ed8 > src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc > 79fde1c67ed8 > src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.hh > 79fde1c67ed8 > src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc > 79fde1c67ed8 > src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 79fde1c67ed8 > src/mem/ruby/network/garnet/flexible-pipeline/flitBuffer.hh 79fde1c67ed8 > src/mem/ruby/network/garnet/flexible-pipeline/flitBuffer.cc 79fde1c67ed8 > src/mem/ruby/network/simple/PerfectSwitch.hh 79fde1c67ed8 > src/mem/ruby/network/simple/PerfectSwitch.cc 79fde1c67ed8 > src/mem/ruby/network/simple/SimpleNetwork.hh 79fde1c67ed8 > src/mem/ruby/network/simple/SimpleNetwork.cc 79fde1c67ed8 > src/mem/ruby/network/simple/Switch.hh 79fde1c67ed8 > src/mem/ruby/network/simple/Switch.cc 79fde1c67ed8 > src/mem/ruby/network/simple/Throttle.hh 79fde1c67ed8 > src/mem/ruby/network/simple/Throttle.cc 79fde1c67ed8 > src/mem/ruby/slicc_interface/AbstractController.hh 79fde1c67ed8 > src/mem/ruby/slicc_interface/AbstractController.cc 79fde1c67ed8 > src/mem/ruby/slicc_interface/Controller.py 79fde1c67ed8 > src/mem/slicc/symbols/StateMachine.py 79fde1c67ed8 > src/proto/packet.proto 79fde1c67ed8 > src/python/swig/pyobject.cc 79fde1c67ed8 > > Diff: http://reviews.gem5.org/r/2348/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
