> On April 5, 2012, 9:34 a.m., Nilay Vaish wrote: > > src/mem/ruby/system/RubyPort.cc, line 708 > > <http://reviews.gem5.org/r/1118/diff/2/?file=25363#file25363line708> > > > > Andreas, this packet is sent to invalidate loads in the LSQ. This > > packet was earlier handled in the LSQ's recvTiming() function. Since that > > code for snooping is being moved to recvTimingSnoop(), I think this code > > should change as well. > > Andreas Hansson wrote: > It seems this is not used in any regression...so I simply did not catch > it. Fixed now and a new diff to come in a min or two. > > Andreas Hansson wrote: > It would be great if you can give it a bash with your set-up and give it > a "ship it" if things are fine. > > Andreas Hansson wrote: > Hi Nilay, > > Any chance you managed to try this out? > > Nilay Vaish wrote: > Nope. > > Andreas Hansson wrote: > Is there I test I can run that will exercise this piece of code?
There is none, I don't think any one uses ruby and o3 cpu currently. I am planning to commit a full system regression test for o3 cpu, ruby and x86 combination. This will have to wait since I am struggling with some error that I see while booting. It seems, I might be speaking too early, that SE/FS merge broke some thing some where. It will take some time (2-3 days) before I can be definitive on this issue. I will run your patch after that. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1118/#review2448 ----------------------------------------------------------- On April 10, 2012, 11:25 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1118/ > ----------------------------------------------------------- > > (Updated April 10, 2012, 11:25 a.m.) > > > Review request for Default. > > > Description > ------- > > MEM: Separate snoops and normal memory requests/responses > > This patch introduces port access methods that separates snoop > request/responses from normal memory request/responses. The > differentiation is made for functional, atomic and timing accesses and > builds on the introduction of master and slave ports. > > Before the introduction of this patch, the packets belonging to the > different phases of the protocol (request -> [forwarded snoop request > -> snoop response]* -> response) all use the same port access > functions, even though the snoop packets flow in the opposite > direction to the normal packet. That is, a coherent master sends > normal request and receives responses, but receives snoop requests and > sends snoop responses (vice versa for the slave). These two distinct > phases now use different access functions, as described below. > > Starting with the functional access, a master sends a request to a > slave through sendFunctional, and the request packet is turned into a > response before the call returns. In a system without cache coherence, > this is all that is needed from the functional interface. For the > cache-coherent scenario, a slave also sends snoop requests to coherent > masters through sendFunctionalSnoop, with responses returned within > the same packet pointer. This is currently used by the bus and caches, > and the LSQ of the O3 CPU. The send/recvFunctional and > send/recvFunctionalSnoop are moved from the Port super class to the > appropriate subclass. > > Atomic accesses follow the same flow as functional accesses, with > request being sent from master to slave through sendAtomic. In the > case of cache-coherent ports, a slave can send snoop requests to a > master through sendAtomicSnoop. Just as for the functional access > methods, the atomic send and receive member functions are moved to the > appropriate subclasses. > > The timing access methods are different from the functional and atomic > in that requests and responses are separated in time and > send/recvTiming are used for both directions. Hence, a master uses > sendTiming to send a request to a slave, and a slave uses sendTiming > to send a response back to a master, at a later point in time. Snoop > requests and responses travel in the opposite direction, similar to > what happens in functional and atomic accesses. With the introduction > of this patch, it is possible to determine the direction of packets in > the bus, and no longer necessary to look for both a master and a slave > port with the requested port id. > > In contrast to the normal recvFunctional, recvAtomic and recvTiming > that are pure virtual functions, the recvFunctionalSnoop, > recvAtomicSnoop and recvTimingSnoop have a default implementation that > calls panic. This is to allow non-coherent master and slave ports to > not implement these functions. > > > Diffs > ----- > > src/arch/x86/pagetable_walker.hh 5534a564f6a0 > src/arch/x86/pagetable_walker.cc 5534a564f6a0 > src/cpu/base.hh 5534a564f6a0 > src/cpu/base.cc 5534a564f6a0 > src/cpu/inorder/cpu.hh 5534a564f6a0 > src/cpu/inorder/cpu.cc 5534a564f6a0 > src/cpu/o3/cpu.hh 5534a564f6a0 > src/cpu/o3/cpu.cc 5534a564f6a0 > src/cpu/o3/lsq.hh 5534a564f6a0 > src/cpu/o3/lsq_impl.hh 5534a564f6a0 > src/cpu/simple/atomic.hh 5534a564f6a0 > src/cpu/simple/timing.hh 5534a564f6a0 > src/cpu/simple/timing.cc 5534a564f6a0 > src/cpu/testers/directedtest/RubyDirectedTester.hh 5534a564f6a0 > src/cpu/testers/directedtest/RubyDirectedTester.cc 5534a564f6a0 > src/cpu/testers/memtest/memtest.hh 5534a564f6a0 > src/cpu/testers/memtest/memtest.cc 5534a564f6a0 > src/cpu/testers/networktest/networktest.hh 5534a564f6a0 > src/cpu/testers/networktest/networktest.cc 5534a564f6a0 > src/cpu/testers/rubytest/RubyTester.hh 5534a564f6a0 > src/cpu/testers/rubytest/RubyTester.cc 5534a564f6a0 > src/dev/io_device.hh 5534a564f6a0 > src/dev/io_device.cc 5534a564f6a0 > src/mem/bridge.hh 5534a564f6a0 > src/mem/bridge.cc 5534a564f6a0 > src/mem/bus.hh 5534a564f6a0 > src/mem/bus.cc 5534a564f6a0 > src/mem/cache/base.hh 5534a564f6a0 > src/mem/cache/cache.hh 5534a564f6a0 > src/mem/cache/cache_impl.hh 5534a564f6a0 > src/mem/mport.hh 5534a564f6a0 > src/mem/mport.cc 5534a564f6a0 > src/mem/packet_queue.hh 5534a564f6a0 > src/mem/packet_queue.cc 5534a564f6a0 > src/mem/port.hh 5534a564f6a0 > src/mem/port.cc 5534a564f6a0 > src/mem/ruby/system/RubyPort.hh 5534a564f6a0 > src/mem/ruby/system/RubyPort.cc 5534a564f6a0 > src/sim/system.hh 5534a564f6a0 > > Diff: http://reviews.gem5.org/r/1118/diff/ > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
