Garnet2.0

[UNDER DEVELOPMENT].

More details of the gem5 Ruby Interconnection Network are here.

Garnet2.0: An On-Chip Network Model for Heterogeneous SoCs

Garnet2.0 is a detailed interconnection network model inside gem5. It builds upon the original Garnet model which was published in 2009.

If your use of Garnet contributes to a published paper, please cite the following paper:

@inproceedings{garnet,
  title={GARNET: A detailed on-chip network model inside a full-system simulator},
  author={Agarwal, Niket and Krishna, Tushar and Peh, Li-Shiuan and Jha, Niraj K},
  booktitle={Performance Analysis of Systems and Software, 2009. ISPASS 2009. IEEE International Symposium on},
  pages={33--42},
  year={2009},
  organization={IEEE}
}

Garnet2.0 provides a cycle-accurate micro-architectural implementation of an on-chip network router. It leverages the Topology and Routing infrastructure provided by gem5's ruby memory system model.

The default router is a state-of-the-art 1-cycle pipeline. There is support to add additional delay of any number of cycles in any router, by specifying it within the topology.

• Related Files:
  • src/mem/ruby/network/Network.py
  • src/mem/ruby/network/garnet2.0/GarnetNetwork.py
  • src/mem/ruby/network/Topology.cc

Invocation

The garnet networks can be enabled by adding --network=garnet2.0.

Configuration

Garnet2.0 uses the generic network parameters in Network.py:

• • number_of_virtual_networks: This is the maximum number of virtual networks. The actual number of active virtual networks is determined by the protocol.
  • control_msg_size: The size of control messages in bytes. Default is 8. m_data_msg_size in Network.cc is set to the block size in bytes + control_msg_size.

Additional parameters are specified in garnet2.0/GarnetNetwork.py:

• • ni_flit_size': flit size in bytes. Flits are the granularity at which information is sent from one router to the other. Default is 16 (=> 128 bits). [This default value of 16 results in control messages fitting within 1 flit, and data messages fitting within 5 flits]. Garnet requires the ni_flit_size to be the same as the bandwidth_factor (in network/BasicLink.py) as it does not model variable bandwidth within the network. This can also be set from the command line with --link-width-bits.
  • vcs_per_vnet': number of virtual channels (VC) per virtual network. Default is 4. This can also be set from the command line with --vcs-per-vnet.
  • buffers_per_data_vc: number of flit-buffers per VC in the data message class. Since data messages occupy 5 flits, this value can lie between 1-5. Default is 4.
  • buffers_per_ctrl_vc: number of flit-buffers per VC in the control message class. Since control messages occupy 1 flit, and a VC can only hold one message at a time, this value has to be 1. Default is 1.
  • routing_algorithm: 0: Weight-based table (default), 1: XY, 2: Custom. More details below.

Topology

Garnet2.0 leverages the Topology infrastructure provided by gem5's ruby memory system model. Any heterogeneous topology can be modeled. Each router in the topology file can be given an independent latency, which overrides the default. In addition, each link has 2 optional parameters: src_outport and dst_inport, which are strings with names of the output and input ports of the source and destination routers for each link. These can be used inside garnet2.0 to implement custom routing algorithms, as described next. For instance, in a Mesh, the west to east links have src_outport set to "west" and dst_inport" set to "east".

• Network Components:
  • GarnetNetwork: This is the top level object that instantiates all network interfaces, routers, and links. Topology.cc calls the methods to add "external links" between NIs and routers, and "internal links" between routers.
  • NetworkInterface: Each NI connects to one coherence controller via MsgBuffer interfaces on one side. It has a link to a router on the other. Every protocol message is put into a one-flit control or multi (default=5)-flit data (depending on its vnet), and injected into the router. Multiple NIs can connect to the same router (for e.g., in the Mesh topology, cache and dir controllers connect via individual NIs to the same router).
  • Router: The router manages arbitration for output links, and flow control between routers.
  • NetworkLink: Network links carry flits. They can be of one of 3 types: EXT_OUT_ (router to NI), EXT_IN_ (NI to router), and INT_ (internal router to router)
  • CreditLink: Credit links carry VC/buffer credits between routers for flow control.

Routing

Garnet2.0 leverages the Routing infrastructure provided by gem5's ruby memory system model. The default routing algorithm is a deterministic table-based routing algorithm with shortest paths. Link weights can be used to prioritize certain links over others. See src/mem/ruby/network/Topology.cc for details about how the routing table is populated.

Custom Routing: To model custom routing algorithms, say adaptive, we provide a framework to name each link with a src_outport and dst_inport direction, and use these inside garnet to implement routing algorithms. For instance, in a Mesh, West-first can be implemented by sending a flit along the "west" outport link till the flit no longer has any X- hops remaining, and then randomly (or based on next router VC availability) choosing one of the remaining links. See how outportComputeXY() is implemented in src/mem/ruby/network/garnet2.0/RoutingUnit.cc. Similarly, outportComputeCustom() can be implemented, and invoked by adding --routing-algorithm=2 in the command line.

Multicast messages: The network modeled does not have hardware multi-cast support within the network. A multi-cast message gets broken into multiple uni-cast messages at the Network Interface.

Router Microarchitecture

• Router Components:
  • InputUnit

The garnet fixed-pipeline models a classic 5-stage Virtual Channel router. The 5-stages are:

1. Buffer Write (BW) + Route Compute (RC): The incoming flit gets buffered and computes its output port.
2. VC Allocation (VA): All buffered flits allocate for VCs at the next routers. [The allocation occurs in a separable manner: First, each input VC chooses one output VC, choosing input arbiters, and places a request for it. Then, each output VC breaks conflicts via output arbiters]. All arbiters in ordered virtual networks are queueing to maintain point-to-point ordering. All other arbiters are round-robin.
3. Switch Allocation (SA): All buffered flits try to reserve the switch ports for the next cycle. [The allocation occurs in a separable manner: First, each input chooses one input VC, using input arbiters, which places a switch request. Then, each output port breaks conflicts via output arbiters]. All arbiters in ordered virtual networks are queueing to maintain point-to-point ordering. All other arbiters are round-robin.
4. Switch Traversal (ST): Flits that won SA traverse the crossbar switch.
5. Link Traversal (LT): Flits from the crossbar traverse links to reach the next routers.

The flow-control implemented is credit-based.

Buffer Management

Each router input port has number_of_virtual_networks Vnets, each with vcs_per_vnet VCs. VCs in control Vnets have a depth of buffers_per_ctrl_vc (default = 1) and VCs in data Vnets have a depth of buffers_per_data_vc (default = 4). Credits are used to manage VCs.