> 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. > > Andreas Hansson wrote: > 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?
Yes, they should and would be soon enough. And now I know why I need to add MI_example to NULL ISA's build_opts. The file src/python/swig/pyobject.cc now includes a header file that includes a header file generated at build time depending on the PROTOCOL in use. Since NULL ISA was not specifying any protocol, I saw compilation problems and added the PROTOCOL option to build_opts for NULL ISA. I am moving this change to a separate patch. > 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. > > Andreas Hansson wrote: > 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. Well, I am unable to run the encode script as I donot have Python protobuf module installed. Can you test the separate patch that I posted a few minutes ago and see if it works properly or not? 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. > > Andreas Hansson wrote: > 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? Note that in C++, the port is actually not involved. It is only the buffer that is ultimately used. Ideally we should move to master-> slave at sometime in future, I doubt this would happen since SLICC would need to undergo even more drastic changes. - Nilay ----------------------------------------------------------- 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
