> On April 8, 2012, 9:22 p.m., Steve Reinhardt wrote: > > Overall looks good. I like your descriptions in the commit message... can > > you incorporate the bulk of that in a comment somewhere, or put it on the > > wiki? No need for the "before" part (that's useful for the changeset, but > > not as part of the stable documentation), but the middle few paragraphs > > that describe how things work need to be included somewhere where they're > > easier for future generations to find. > > Andreas Hansson wrote: > Thanks! > > I have a document ready for updating the wiki, and this indeed part of > it. Overall, we have prepared a decent amount of documentation that will go > on the wiki as the functionality is committed, and this is probably a good > time to start putting things in place.
Is there anything else I can do, or are you happy with the current version Steve? The code duplication should be at a very minimum with the latest diff. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1118/#review2512 ----------------------------------------------------------- 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
