Tushar, The reason I am modifying the protocol is that I want to implement a shared-bus based crossbar where each node has its own dedicated write channel and other nodes listen to it. However, I see that ruby does not support hardware broadcast, so modifying the protocol seems to me the only way to implement this. I think by modifying all the messages to be broadcast messages can solve this. It would be really helpful if you could provide me more information how to implement this kind of topology. I think mXbar is very very close to what I wanna do. Thank you very much!
Best, Jinzhu On Thu, Jul 26, 2012 at 7:30 PM, Tushar Krishna <tus...@csail.mit.edu>wrote: > Hi Jinzhu, > Why do you want to broadcast to L1s and the directories? Just to add more > messages in the network? MOESI_hammer inherently broadcasts to all L1s > which gives you a broadcast to all nodes. I don't think you should mess > with the protocol, unless you have a strong justification for why those > extra messages are needed: example you come up with some new protocol that > sends more broadcasts instead of tracking some state etc… In which case, > yes you would have to define extra transitions to handle the extra messages. > > The two broadcast based protocols provided with gem5 are MOESI_hammer > (where a directory broadcasts to all L1s) and MOESI_CMP_token, where L1's > broadcast to all L2s … > > cheers, > Tushar > > > On Jul 26, 2012, at 6:21 PM, gem5 gem5 wrote: > > Hi Tushar, > > Thanks for your reply! I think you are right. I need to deal with those > extra messages. Any suggestions how to do that? Should I define some new > transitions and get rid of those messages? > > I have read your 1 to many paper before. If I want to implement some > crossbar topology which supports broadcast like mXbar, do you think > modifying the protocol is the right way to do or there is some other better > method? Thank you very much for your help. > > Best, > > Jinzhu > > > > On Thu, Jul 26, 2012 at 12:53 PM, Tushar Krishna <tus...@csail.mit.edu>wrote: > >> The error has nothing to do with the virtual network being ordered or not. >> If you look at MessageBuffer.hh, line 131, a setOrdering function needs >> to be called for each MessageBuffer. >> This is called from the coherence protocol's generated files. [The >> ordering itself might be true or false depending on the vnet, but this >> function has to be called for the message buffer to be valid]. >> >> If all you have changed in the protocol is to broadcast to all L1's and >> directories, instead only only to L1's, you also need to account for what >> happens when these directories receive these messages. My guess is that >> these messages are being inserted into some message buffer that is not part >> of the protocol specifications and hence this error shows up. >> >> >> - Tushar >> >> >> On Jul 25, 2012, at 5:29 PM, gem5 gem5 wrote: >> >> > Hi all, >> > >> > I want to modify MOESI_hammer protocol to broadcast all the messages. >> Since multicast is supported, I think it's possible to do this. I got some >> problem with my first step. When I modify >> out_msg.Destination.broadcast(MachineType:L1Cache); to be >> out_msg.Destination.broadcast() which I assume means to broadcast to all >> nodes, inside of action(fn_forwardRequestIfNecessary, "fn", desc="Forward >> requests if necessary"), I got some error like this when run the >> rubynetwork tester with Pt2Pt topology: >> > >> > panic: Ordering property of has not been set >> > @ cycle 40 >> > [enqueue:build/X86_SE/mem/ruby/buffers/MessageBuffer.cc, line 165] >> > Memory Usage: 241400 KBytes >> > Program aborted at cycle 40 >> > Abort >> > >> > I tried to set the corresponding virtual network forwardFromDir's >> ordered="true", but still I cannot get rid of this error. Any help will be >> appreciated. Thanks a lot! >> > >> > Jinzhu >> > >> > >> > _______________________________________________ >> > gem5-users mailing list >> > gem5-users@gem5.org >> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
