Review Board 2.0.15


Changes to the gem5 memory-system (release-0.2)

Review Request #817 - Created Aug. 5, 2011 and discarded

Information
Andreas Hansson
gem5
default
Reviewers
Default
ali, gblack, nate, stever 
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.

   

  


 


 

  

  









  
 


  

 


















 













 



 

  


 

  

   

   
Review request changed

   
Updated  (July 9, 2012, 7:25 p.m.)

  

  


   

    Status:
    

    Discarded