> 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? > > Nilay Vaish wrote: > No. I don't recall right now why I added this line. I'll check again > whether this line is required or not.
Actually, build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby and all the other rubytest and memtest for the various protocols, could (and probably should?) move to use NULL rather than ALPHA, should they 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? > > Nilay Vaish wrote: > 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. If possible I'd avoid the change. The scripts that are part of the public repo are in util and are encode/decode_packet_trace. I'd make this a separate changeset if the name really has to be modified. 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. > > Nilay Vaish wrote: > 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. My bad, I should have been more clear. Today with the "normal" ports we do Master -> Slave With the Ruby message buffers we do Master -> Slave in the config, but master -> buffer -> slave in the C++. I was merely wondering if we could not embed the message buffer on either side of the interface (master or slave), and do master -> slave between the objects? - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2348/#review5298 ----------------------------------------------------------- On Aug. 25, 2014, 8:01 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2348/ > ----------------------------------------------------------- > > (Updated Aug. 25, 2014, 8:01 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10293:670b9fb93f37 > --------------------------- > 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
