> On 2011-08-27 22:37:34, Steve Reinhardt wrote: > > src/mem/module_interface.hh, line 195 > > <http://reviews.m5sim.org/r/817/diff/1/?file=14527#file14527line195> > > > > I know the "debug" name derives from SystemC TLM usage, but I think the > > m5 label "functional" is more descriptive (since it's not just debugging), > > and has more continuity with the old code. We should at least have a > > larger discussion about this before making a permanent decision. > > Andreas Hansson wrote: > From the perspective of the memory system, a "functional" access is > rather confusing, since it does rather the opposite and does not model the > functionality of the components. recvDebug corresponds more or less exactly > with the semantics of transport_dgb in TLM-2.0: "A debug access must be > performed without any of the delays, waits, event notifications, or side > effects associated with a regular transaction. The debug interface is, > therefore, non-intrusive." > > ...but indeed it's up for discussion. >
Just one comment to add here.... I was very much against this originally, but over the last year as I've described and ultimately confused enough people with our naming I think it might be the right decision. So, yes, we should consider if we want to have a global s/func/debug/g. - Ali ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/817/#review1470 ----------------------------------------------------------- On 2011-08-05 10:17:39, Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/817/ > ----------------------------------------------------------- > > (Updated 2011-08-05 10:17:39) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > Changes to the gem5 memory-system (release-0.2) > > ------------------------------------------------------------------------------ > > What is the goal > > The goal is to make it easier to use gem5 for communication-centric > modelling by adopting a communication framework similar to that of the > TLM-2.0 transaction level modelling standard from the Open SystemC > Initiative (OSCI). Just like TLM-2.0, the basic idea behind the > changes is to facilitate modelling of inter-module communication > through a set of well-define module interfaces, e.g. a memory-mapped > interface, and a cache-maintenance interface. > > The major difference with release 0.1 of the extensions is that all > modules now implement the 4-phase handshakes. Thus, this serves as a > good indication of what the modules will look and feel like. > > After this submission we are starting to put incremental patches in > place to get this into the main repository. In other words, the sooner > we get feedback the better. Once again thanks for the comments on the > first round. > > ------------------------------------------------------------------------------ > > What are the key improvements > > - Master and slave interfaces (SystemC sc_export), distinguishing the > different roles in inter-module communication. A master (TLM-2.0 > initiator) is a MemObject that initiates new transactions, and a > slave (TLM2 target) is a module that responds to transactions > initiated by master modules. The same module can act both as a > master and a slave, and this would typically be the case for a model > of a bridge, a router, or a bus. See src/mem/module_interface.hh > > - Master and slave port interfaces that are used to access the > corresponding module interfaces (SystemC sc_port). Together with the > module interfaces the port interfaces form the basis for having > ports and modules with different protocols. For example, a > memory-mapped master port would be used to call functions > implemented by a memory-mapped slave interface. See > src/mem/port_interface.{hh,cc} > > - Ports that only convey structural information and leave the syntax > (payload type) and semantics to a specific port interface. The > ports themselves only contain information about their owners > (structurally) and basic knowledge of their connectivity. The actual > semantics and syntax of the communication between a master and a > slave port is determined by their port interfaces and the > corresponding exported module interfaces. See src/mem/port.{hh,cc} > > - The specific type of packet is determined by the protocol of the > interfaces enabling diversity in payload types. See > src/mem/protocol.{hh,cc} and src/mem/packet.{hh,cc} > > - Standard 4-phase handshakes (TLM-2.0 approximately timed) for > request/response avoid complex receive/retry interaction between > modules in timing mode. Every MemObject is not using the new 4-phase > semantics. > > - Ports do not implement any module-specific functionality but merely > calls functions on their interface classes. > > ------------------------------------------------------------------------------ > > How does it work > > A master port has a protocol-specific master-port interface, and is > associated with a master-module interface. An example of this is the > data and instruction port of a CPU. The master-port interface calls > functions on the connected slave-module interface. In the case of the > CPU, this could be e.g. memory, or a cache, both implementing the > memory-mapped slave interface and making it visible through a > memory-mapped slave port. The Python instantiation is currently based > on the position of the ports (left or right of the equality sign) to > determine if they are masters or slaves, but this should be eventually > be specified in the Module.py using subclasses of Port. Similarly, the > cache ports are currently determined by looking at the name of the > port. This should also be extended to use an enum or literal in the > Module.py. The binding is checked at instantiation time when the C++ > objects are created and their ports connected. As part of the > instantiation a structural diagram of the system is also created as a > Graphviz dot file. Run it through "dot -Tsvg" and have a look in your > browser. The diagram clearly shows what ports are connected, what > protocol and role they have, and as a tooltip if also shows the > address ranges of all memory-mapped slave ports. > > Currently the 4-phase handshake are used by all the MemObjects in the > system. However, the bridges are still present to facilitate the > integration work. See src/mem/bridge_classic_to_4phase.{hh,cc} and > src/mem/bridge_4phase_to_classic.{hh,cc}. The 4-phase is completely > replacing the old receive/retry handshakes, but there are situations > with unaligned accesses that still have to be addressed (we only > looked at Alpha and so got away without worrying). > > Similar to the classic gem5 memory-system, a packet points to a > request and its associated data. In the typical case, a memory-mapped > request packet is created by a master, such as a DMA or a CPU. Once > beginReq is called, the sending (master) module should not change the > packet until its response is returned through a beginResp (where > applicable). An intermediate component, such as a bus or cache, may > create forwarded cache-maintenance packets from the original > memory-mapped request. Thus, one request gives rise to a chain of > requests and responses. Currently the lifetime and rules governing > those packets (and their request and data pointers) is work in > progress (see e.g. coherent_bus.cc). The original request/response may > be deallocated before the snoop request/response and vice versa. Smart > pointers and reference counting might be a viable solution, or > alternatively a more intelligent snoop controller in the > buses. In addition, the different packets (currently memory-mapped > and cache-maintenance) should be stripped of as much common > functionality as possible, reducing the memory-mapped packets to a > bare essential. > > In response to questions from the reviews of release 0.1, the 4-phase > does not mandate a response handshake (it is possible to have only a > request begin/end). Also note that the untimed cache maintenance > protocol does not use the 4-phase at all. Thus, if there is need for > something else it is possible. > > ------------------------------------------------------------------------------ > > What is the intention with this patch > > This patch is not showing all the changes made to the repository, but > in contrast to the release 0.1 this includes essentially all source > changes, and also diffs with respect to the revision the day we > branched (22 February 2011). > > - The underlying infrastructure > o Module Interface (what does a master/slave have to provide) > o Port Interface (how is it accesses through the ports) > o Port (how are the structural ports and logical interfaces bound together) > o Protocol > > - The basic building blocks > o MemObject (maintain collections of ports and do look ups of names) > o Packet Queue (similar to the Payload Event Queue in TLM2, and > closely related to the SimpleTimingPort) > > - The models themselves > o NonCoherentBus, CoherentBus > o I/O Device (show a simple memory-mapped slave) > o PhysicalMemory (same as above) > o Bridge (show the benefits of the protocol separation and clear port roles) > o CPU (demonstrate the shift from functionality in the ports to > interfaces of the modules) > o Bridge classic to/from 4-phase (highlighting the difference between > the semantics) > > - An example of their use > o Tsunami system (show the port connections and the structure) > o Caches > o CPUs > > The goal is to get feedback and suggestions on anything from the > actual design and how it is implemented, to the coding style and code > comments. This is also an opportunity for everyone to influence and > steer the changes and the integration into the main gem5 > repository. With this second review we also hope to share the > remaining trajectory for integration into the repository, chopping the > contributions up in incremental patches. This work is about to start, > so let us know as soon as possible if you have questions or concerns. > > ------------------------------------------------------------------------------ > > Testing and verification > > In order to work effectively we have limited the regression to only > include the quick Alpha tests. For these tests, the appropriate > updates have been made to connect the additional ports, and define the > role and protocol for the ports in question. Due to the changes in > timing, small deviations (plus minus a few percent) in statistics have > been observed for a number of tests. We have considered this to be > within reasonable limits and updated the reference behaviour. > > > Diffs > ----- > > configs/common/CacheConfig.py 6548721032fa > configs/common/FSConfig.py 6548721032fa > configs/common/Options.py 6548721032fa > src/cpu/base.hh 6548721032fa > src/cpu/base.cc 6548721032fa > src/cpu/base_dyn_inst.hh 6548721032fa > src/cpu/o3/O3CPU.py 6548721032fa > src/cpu/o3/bpred_unit_impl.hh 6548721032fa > src/cpu/o3/comm.hh 6548721032fa > src/cpu/o3/commit.hh 6548721032fa > src/cpu/o3/commit_impl.hh 6548721032fa > src/cpu/o3/cpu.hh 6548721032fa > src/cpu/o3/cpu.cc 6548721032fa > src/cpu/o3/cpu_builder.cc 6548721032fa > src/cpu/o3/dyn_inst.hh 6548721032fa > src/cpu/o3/dyn_inst_impl.hh 6548721032fa > src/cpu/o3/fetch.hh 6548721032fa > src/cpu/o3/fetch_impl.hh 6548721032fa > src/cpu/o3/iew.hh 6548721032fa > src/cpu/o3/iew_impl.hh 6548721032fa > src/cpu/o3/inst_queue_impl.hh 6548721032fa > src/cpu/o3/lsq.hh 6548721032fa > src/cpu/o3/lsq_impl.hh 6548721032fa > src/cpu/o3/lsq_unit.hh 6548721032fa > src/cpu/o3/lsq_unit_impl.hh 6548721032fa > src/cpu/o3/mem_dep_unit_impl.hh 6548721032fa > src/cpu/o3/thread_context.hh 6548721032fa > src/cpu/o3/thread_context_impl.hh 6548721032fa > src/cpu/simple/AtomicSimpleCPU.py 6548721032fa > src/cpu/simple/TimingSimpleCPU.py 6548721032fa > src/cpu/simple/atomic.hh 6548721032fa > src/cpu/simple/atomic.cc 6548721032fa > src/cpu/simple/base.hh 6548721032fa > src/cpu/simple/timing.hh 6548721032fa > src/cpu/simple/timing.cc 6548721032fa > src/cpu/simple_thread.hh 6548721032fa > src/cpu/simple_thread.cc 6548721032fa > src/cpu/thread_context.hh 6548721032fa > src/cpu/thread_state.hh 6548721032fa > src/cpu/thread_state.cc 6548721032fa > src/dev/Device.py 6548721032fa > src/dev/Ethernet.py 6548721032fa > src/dev/Pci.py 6548721032fa > src/dev/SConscript 6548721032fa > src/dev/alpha/Tsunami.py 6548721032fa > src/dev/alpha/backdoor.hh 6548721032fa > src/dev/alpha/backdoor.cc 6548721032fa > src/dev/alpha/tsunami.cc 6548721032fa > src/dev/alpha/tsunami_cchip.hh 6548721032fa > src/dev/alpha/tsunami_cchip.cc 6548721032fa > src/dev/alpha/tsunami_io.hh 6548721032fa > src/dev/alpha/tsunami_io.cc 6548721032fa > src/dev/alpha/tsunami_pchip.hh 6548721032fa > src/dev/alpha/tsunami_pchip.cc 6548721032fa > src/dev/baddev.hh 6548721032fa > src/dev/baddev.cc 6548721032fa > src/dev/dma_device.cc PRE-CREATION > src/dev/dma_device.cc~ PRE-CREATION > src/dev/dma_device.hh PRE-CREATION > src/dev/dma_device.hh~ PRE-CREATION > src/dev/i8254xGBe.hh 6548721032fa > src/dev/i8254xGBe.cc 6548721032fa > src/dev/ide_ctrl.hh 6548721032fa > src/dev/ide_ctrl.cc 6548721032fa > src/dev/io_device.hh 6548721032fa > src/dev/io_device.cc 6548721032fa > src/dev/isa_fake.hh 6548721032fa > src/dev/isa_fake.cc 6548721032fa > src/dev/ns_gige.hh 6548721032fa > src/dev/ns_gige.cc 6548721032fa > src/dev/pciconfigall.hh 6548721032fa > src/dev/pciconfigall.cc 6548721032fa > src/dev/pcidev.hh 6548721032fa > src/dev/pcidev.cc 6548721032fa > src/dev/platform.hh 6548721032fa > src/dev/platform.cc 6548721032fa > src/dev/simple_disk.hh 6548721032fa > src/dev/simple_disk.cc 6548721032fa > src/dev/sinic.hh 6548721032fa > src/dev/sinic.cc 6548721032fa > src/dev/uart8250.hh 6548721032fa > src/dev/uart8250.cc 6548721032fa > src/mem/Bridge.py 6548721032fa > src/mem/Bridge4PhaseToClassic.py PRE-CREATION > src/mem/BridgeClassicTo4Phase.py PRE-CREATION > src/mem/CoherentBus.py PRE-CREATION > src/mem/NonCoherentBus.py PRE-CREATION > src/mem/PhysicalMemory.py 6548721032fa > src/mem/SConscript 6548721032fa > src/mem/bridge.hh 6548721032fa > src/mem/bridge.cc 6548721032fa > src/mem/bridge_4phase_to_classic.hh PRE-CREATION > src/mem/bridge_4phase_to_classic.cc PRE-CREATION > src/mem/bridge_classic_to_4phase.hh PRE-CREATION > src/mem/bridge_classic_to_4phase.cc PRE-CREATION > src/mem/bus.hh 6548721032fa > src/mem/bus.cc 6548721032fa > src/mem/cache/BaseCache.py 6548721032fa > src/mem/cache/base.hh 6548721032fa > src/mem/cache/base.cc 6548721032fa > src/mem/cache/blk.hh 6548721032fa > src/mem/cache/builder.cc 6548721032fa > src/mem/cache/cache.hh 6548721032fa > src/mem/cache/cache_impl.hh 6548721032fa > src/mem/cache/mshr.hh 6548721032fa > src/mem/cache/mshr.cc 6548721032fa > src/mem/cache/mshr_queue.hh 6548721032fa > src/mem/cache/mshr_queue.cc 6548721032fa > src/mem/coherent_bus.hh PRE-CREATION > src/mem/coherent_bus.cc PRE-CREATION > src/mem/fs_translating_proxy.hh PRE-CREATION > src/mem/fs_translating_proxy.cc PRE-CREATION > src/mem/mem_object.hh 6548721032fa > src/mem/mem_object.cc 6548721032fa > src/mem/module_interface.hh PRE-CREATION > src/mem/mport.hh 6548721032fa > src/mem/mport.cc 6548721032fa > src/mem/noncoherent_bus.hh PRE-CREATION > src/mem/noncoherent_bus.cc PRE-CREATION > src/mem/packet.hh 6548721032fa > src/mem/packet_queue.hh PRE-CREATION > src/mem/packet_queue.cc PRE-CREATION > src/mem/physical.hh 6548721032fa > src/mem/physical.cc 6548721032fa > src/mem/port.hh 6548721032fa > src/mem/port.cc 6548721032fa > src/mem/port_impl.hh 6548721032fa > src/mem/port_interface.hh PRE-CREATION > src/mem/port_interface.cc PRE-CREATION > src/mem/port_proxy.hh PRE-CREATION > src/mem/port_proxy.cc PRE-CREATION > src/mem/protocol.hh PRE-CREATION > src/mem/se_translating_proxy.hh PRE-CREATION > src/mem/se_translating_proxy.cc PRE-CREATION > src/mem/tport.hh 6548721032fa > src/mem/tport.cc 6548721032fa > src/mem/translating_port.hh 6548721032fa > src/mem/translating_port.cc 6548721032fa > src/mem/vport.hh 6548721032fa > src/mem/vport.cc 6548721032fa > src/python/m5/SimObject.py 6548721032fa > src/python/m5/main.py 6548721032fa > src/python/m5/params.py 6548721032fa > src/python/m5/simulate.py 6548721032fa > src/python/swig/pyobject.hh 6548721032fa > src/python/swig/pyobject.cc 6548721032fa > src/python/swig/sim_object.i 6548721032fa > src/sim/System.py 6548721032fa > src/sim/arguments.hh 6548721032fa > src/sim/process.hh 6548721032fa > src/sim/process.cc 6548721032fa > src/sim/process_impl.hh 6548721032fa > src/sim/pseudo_inst.hh 6548721032fa > src/sim/pseudo_inst.cc 6548721032fa > src/sim/root.hh 6548721032fa > src/sim/root.cc 6548721032fa > src/sim/sim_object.hh 6548721032fa > src/sim/sim_object.cc 6548721032fa > src/sim/sim_object_params.hh 6548721032fa > src/sim/simulate.cc 6548721032fa > src/sim/syscall_emul.hh 6548721032fa > src/sim/syscall_emul.cc 6548721032fa > src/sim/system.hh 6548721032fa > src/sim/system.cc 6548721032fa > src/sim/tlb.hh 6548721032fa > tests/configs/o3-nocaches-timing.py PRE-CREATION > tests/configs/o3-timing.py 6548721032fa > tests/configs/realview-simple-atomic.py 6548721032fa > tests/configs/realview-simple-timing.py 6548721032fa > tests/configs/simple-atomic.py 6548721032fa > tests/configs/simple-timing.py 6548721032fa > tests/configs/tsunami-nocaches-timing.py PRE-CREATION > tests/configs/tsunami-o3-dual.py 6548721032fa > tests/configs/tsunami-o3.py 6548721032fa > tests/configs/tsunami-simple-atomic-dual.py 6548721032fa > tests/configs/tsunami-simple-atomic.py 6548721032fa > tests/configs/tsunami-simple-timing-dual.py 6548721032fa > tests/configs/tsunami-simple-timing.py 6548721032fa > tests/configs/twosys-tsunami-simple-atomic.py 6548721032fa > > Diff: http://reviews.m5sim.org/r/817/diff > > > Testing > ------- > > > Thanks, > > Andreas > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
