-
Notifications
You must be signed in to change notification settings - Fork 12
routerSGML
The Router.sgml file describes the router microarchitecture that will be employed in simulation. In TOPAZ, router architecture can be described with different levels of detail. In Simple description a single component describes the whole router functionality. With this kind of router TOPAZ is able to simulate an elevated amount of cycles per second, at the cost of precision. In contrast, Detailed descriptions require different components to describe each router element (buffers, routing units, crossbar). This makes simulations much slower, but increases results accuracy.
Every router definition at Router.sgml file has a similar structure. A first tag identifies the structure, as well as some common parameters to all of its components. Second every component inside the router is defined, through one or multiple tags. Finally, the way all the components are interconnected and connected to router inputs and outputs is also defined. Simple and Detailed router definitions present some differences, making necessary an independent explanation for each of them:
Simple routers present the peculiarity of being built through a single component. This means that appart from Injector, Consumer and input/output ports, only one additional component must be defined. The code below corresponds to the definition of a Bi-dimensional router of the Simple type.
<Router id="MESH-WH-NOC" inputs=4 outputs=4 bufferSize=10 bufferControl=WH routingControl="MESH-DOR">
<Injector id="INJ" numHeaders=1 typeInj="WH" numMessTypes=5>
<Consumer id="CONS">
<SimpleRouter id="ROUTER" inputs="5" outputs="5" headerDelay=0 dataDelay=0 vnets=5 >
<Input id=1 type="X+">
<Input id=2 type="X-">
<Input id=3 type="Y+">
<Input id=4 type="Y-">
<Input id=5 type="Node">
<Output id=1 type="X+">
<Output id=2 type="X-">
<Output id=3 type="Y+">
<Output id=4 type="Y-">
<Output id=5 type="Node">
</SimpleRouter>
<Connection id="C01" source="INJ" destiny="ROUTER.5">
<Connection id="C02" source="ROUTER.5" destiny="CONS">
<Input id="1" type="X+" wrapper="ROUTER.1">
<Input id="2" type="X-" wrapper="ROUTER.2">
<Input id="3" type="Y+" wrapper="ROUTER.3">
<Input id="4" type="Y-" wrapper="ROUTER.4">
<Output id="1" type="X+" wrapper="ROUTER.1">
<Output id="2" type="X-" wrapper="ROUTER.2">
<Output id="3" type="Y+" wrapper="ROUTER.3">
<Output id="4" type="Y-" wrapper="ROUTER.4">
</Router>
Router
This first tag corresponds to the definition of some of the main characteristics of the router. First of all we find the router identifier id, which must be different for each configuration in Router.sgml file. Second, the number of inputs and outputs of the router are specified. This number must match with the amount of dimensions of the topology selected. Each network dimension requires two inputs/outputs, one for each direction (+/-). In the previous example, 4 ports means we must work with a bi-dimensional topology. bufferSize parameter fixes the amount of buffering in flits at each router input-port. bufferControl specifies the Flow Control policy selected for buffer operation. Finally, routingControl determines routing policy followed by every packet traversing the network.
Injector/Consumer
These components are in charge of message generation and consumption. When connected to external simulation tools, communication between simulators is performed through these two components. These two components are also parametrizable, and a deeper explanation can be found in
SimpleRouter
This single component implements the whole functionality of the router (buffers, arbiters, crossbar). This component must have always one more input and output port than the Router, because both Injector and Consumer are considered internal components of the Router. Through headerDelay and dataDelay we are able to configure the delay experienced by flits to traverse this component (emulating router pipeline). Finally, vnets parameter indicates how many virtual channels with exclusive buffering we are simulating at each router port.
Every SimpleRouter must define each of its input and output ports with an individual tag line. Each port definition requires a number to identify it as well as its dimension/direction information.
Connection
After defining every router component, we must determine how these components will be interconnected, and how they will be connected to router ports. Every connection defined in this file must have a unique name, source and destination. Otherwise, prepare for a debugging nightmare. source and destination determine the way in which flits move between two components. Connections are not bi-directional!.
Input/Output
These are the interfaces to interconnect multiple routers. They represent router ports and are connected to links between neighbor routers. The definition of each router port implies always three parameters; an identifier (id), its direction/dimension definition (type) and the internal component connected to that port (wrapper).
In the case of a Detailed description of a router, every internal router component is defined with its own tag in the Router.sgml file. TOPAZ provides a large amount of different components, and not all of them are present at each router definition. In fact, some components are only employed in a few specific router microarchitectures. Below we provide a typical router description, which employs many components available. We will explain the components of this example in first place, but we will also provide information about the remaining components available.
Router components are not freely interchangeable. This means, for example, that not all Buffer configurations work properly with any Crossbar available. When possible, we will notify which of these conflicts are present in TOPAZ.
<Router id="PRUEBA-MUXED-DOR" inputs=4 outputs=4 bufferSize=21 bufferControl=CT injControl=VNET routingControl="DOR-MUX">
<Injector id="INJ1" numHeaders=1 typeInj="CT-UC" numMessTypes=4>
<Injector id="INJ2" numHeaders=1 typeInj="CT-UC" numMessTypes=4>
<Injector id="INJ3" numHeaders=1 typeInj="CT-UC" numMessTypes=4>
<Injector id="INJ4" numHeaders=1 typeInj="CT-UC" numMessTypes=4>
<Consumer id="CONS">
<Buffer id="BUF111" type="X+" dataDelay=2>
<Buffer id="BUF112" type="X+" dataDelay=2>
<Buffer id="BUF113" type="X+" dataDelay=2>
<Buffer id="BUF114" type="X+" dataDelay=2>
<Buffer id="BUF211" type="X-" dataDelay=2>
<Buffer id="BUF212" type="X-" dataDelay=2>
<Buffer id="BUF213" type="X-" dataDelay=2>
<Buffer id="BUF214" type="X-" dataDelay=2>
<Buffer id="BUF311" type="Y+" dataDelay=2>
<Buffer id="BUF312" type="Y+" dataDelay=2>
<Buffer id="BUF313" type="Y+" dataDelay=2>
<Buffer id="BUF314" type="Y+" dataDelay=2>
<Buffer id="BUF411" type="Y-" dataDelay=2>
<Buffer id="BUF412" type="Y-" dataDelay=2>
<Buffer id="BUF413" type="Y-" dataDelay=2>
<Buffer id="BUF414" type="Y-" dataDelay=2>
<Buffer id="BUF511" type="Node" dataDelay=2>
<Buffer id="BUF512" type="Node" dataDelay=2>
<Buffer id="BUF513" type="Node" dataDelay=2>
<Buffer id="BUF514" type="Node" dataDelay=2>
<RoutingMuxed id="RTG1" type="X+" channel=1 inputs="4" headerDelay=2 dataDelay=0>
<RoutingMuxed id="RTG2" type="X-" channel=1 inputs="4" headerDelay=2 dataDelay=0>
<RoutingMuxed id="RTG3" type="Y+" channel=1 inputs="4" headerDelay=2 dataDelay=0>
<RoutingMuxed id="RTG4" type="Y-" channel=1 inputs="4" headerDelay=2 dataDelay=0>
<RoutingMuxed id="RTG5" type="Node" channel=1 inputs="4" headerDelay=2 dataDelay=0>
<Crossbar id="CROSSBAR" inputs="5" outputs="5" type="MUX-CT" mux="4" headerDelay=0 dataDelay=1>
<Input id=1 type="X+" channel=1>
<Input id=2 type="X-" channel=1>
<Input id=3 type="Y+" channel=1>
<Input id=4 type="Y-" channel=1>
<Input id=5 type="Node">
<Output id=1 type="X+">
<Output id=2 type="X-">
<Output id=3 type="Y+">
<Output id=4 type="Y-">
<Output id=5 type="Node">
</Crossbar>
<Connection id="C01a" source="INJ1" destiny="BUF511">
<Connection id="C01b" source="INJ2" destiny="BUF512">
<Connection id="C01c" source="INJ3" destiny="BUF513">
<Connection id="C01d" source="INJ4" destiny="BUF514">
<Connection id="C02" source="CROSSBAR.5" destiny="CONS">
<Connection id="C11" source="RTG1" destiny="CROSSBAR.1">
<Connection id="C12" source="RTG2" destiny="CROSSBAR.2">
<Connection id="C13" source="RTG3" destiny="CROSSBAR.3">
<Connection id="C14" source="RTG4" destiny="CROSSBAR.4">
<Connection id="C15" source="RTG5" destiny="CROSSBAR.5">
<Connection id="C21" source="BUF111" destiny="RTG1.1">
<Connection id="C22" source="BUF112" destiny="RTG1.2">
<Connection id="C23" source="BUF113" destiny="RTG1.3">
<Connection id="C24" source="BUF114" destiny="RTG1.4">
<Connection id="C31" source="BUF211" destiny="RTG2.1">
<Connection id="C32" source="BUF212" destiny="RTG2.2">
<Connection id="C33" source="BUF213" destiny="RTG2.3">
<Connection id="C34" source="BUF214" destiny="RTG2.4">
<Connection id="C41" source="BUF311" destiny="RTG3.1">
<Connection id="C42" source="BUF312" destiny="RTG3.2">
<Connection id="C43" source="BUF313" destiny="RTG3.3">
<Connection id="C44" source="BUF314" destiny="RTG3.4">
<Connection id="C51" source="BUF411" destiny="RTG4.1">
<Connection id="C52" source="BUF412" destiny="RTG4.2">
<Connection id="C53" source="BUF413" destiny="RTG4.3">
<Connection id="C54" source="BUF414" destiny="RTG4.4">
<Connection id="C61" source="BUF511" destiny="RTG5.1">
<Connection id="C62" source="BUF512" destiny="RTG5.2">
<Connection id="C63" source="BUF513" destiny="RTG5.3">
<Connection id="C64" source="BUF514" destiny="RTG5.4">
<Input id="1" type="X+" wrapper="BUF111,BUF112,BUF113,BUF114">
<Input id="2" type="X-" wrapper="BUF211,BUF212,BUF213,BUF214">
<Input id="3" type="Y+" wrapper="BUF311,BUF312,BUF313,BUF314">
<Input id="4" type="Y-" wrapper="BUF411,BUF412,BUF413,BUF414">
<Output id="1" type="X+" wrapper="CROSSBAR.1">
<Output id="2" type="X-" wrapper="CROSSBAR.2">
<Output id="3" type="Y+" wrapper="CROSSBAR.3">
<Output id="4" type="Y-" wrapper="CROSSBAR.4">
</Router>
As it can be seen, the information required to build a single router is much larger than in the case of Simple Router descriptions. It might seem useless to define, for example, each Buffer individually, taking into account that they share most of the parameters. However, this fact provides high flexibility to evaluate, for example, different delays depending on the Dimension. This can be a really interesting feature for On-chip 3D topologies exploration.
####Components####
Injector
This component generates the messages that will be injected into the network, adjusting message charactersitics to the synthetic traffic configuration or to the requirements imposed by a trace file or by an external simulation tool.
The number of flits required to store header information can be set to 1 or 2 through the numHeaders parameter. NoCs usually employ 1-flit headers, while some Off-chip networks with limited bandwidth might require 2-flit headers.The amount of message types must also be defined at each injector through the numMessTypes variable. This value must coincide with the one assigned at traffic definition in Simulation.sgml file.
In those routers with multiple injectors, the one selected for each generated message is selected according to the specifications in injControl. The available choices are:
- RANDOM: a random injector is selected.
- RROBIN: the injector is selected in Round Robin order.
- VNET: Each message type has its own exclusive injector.
According to its internal behavior, different types of injectors can be defined through the typeInj variable:
- CT-UC: Injector for routers with Cut-Through Flow Control and without multicast support.
- WH-UC: Injector for routers with Wormhole Flow Control and without multicast support.
- CT-MCAST: Injector for routers with Cut-Through Flow Control and with multicast support.
- WH-MCAST: Injector for routers with Wormhole Flow Control and with multicast support.
Consumer
This component retires the messages from the network when they reach destination. At each router, only one consumer can be defined. For the moment, support for multiple consumers is not provided. Despite not being present in the example above, different consumers are available through the typeCons variable:
- CT: Packet-level flow control at the consumer. Once the header flit is at the consumer, the remaining message flits must arrive prior to a new message. This consumer is employed in WH networks to avoid deadlocks produced by packet interleaving at consumption.
- BLESS: For bufferless routers, this consumer is in charge of re-assembling message flits (only when all message flits reach consumer the transmission is considered as finished).
- REACT: This consumer is employed in reactive traffic patterns to decide the generation of messages as a consequence of the consumption of previous ones.
Buffer
Each tag starting with this name defines a FIFO buffer present at the router. This component has a single read port and a single write port, which means that only one read and one write operations are possible on each simulated cycle. Buffer length is defined in flits and can be chosen through two different methods. If we want to define the same size for every router buffer, the bufferSize variable at Router tag will force the size of every Buffer defined. In contrast, to give each Buffer a different value, the size variable could be added to each buffer tag with uneven values. The delay through each buffer can be also different for each component defined, through the dataDelay parameter. Finally, according to the Flow Control selected for the router, different buffer behaviors can be simulated for every buffer through the bufferControl variable:
- CT: Packet Level (Virtual Cut Through) flow control. Only header flits respond to stop signals.
- CT-MCAST: VCT with support to multi-destination messages.
- WH: Flit level (Wormhole) flow control.
- WH-MCAST: Flit level flow control with multicast support.
- DAMQ: Special Flit level flow control, where all the buffers from an input port emulate the behavior of a shared buffer with dynamically allocated Virtual Channels.
Routing Muxed
This unit performs two different tasks. First it performs routing operations, deciding which router ports can be requested by each message. Second, this component performs a first phase of arbitration, granting access to the crossbar port connected to only a single buffer each cycle (separated allocators). From the buffer granted, a request to a crossbar output port is generated, and only after winning this request the message can advance. The arbitration of the different virtual channels at each input port can be based on different policies. TOPAZ only implements a priority-based one, necessary to prevent end-to-end deadlocks. However, different policies are easily implementable for this component. It must be noticed that for the moment this component only works properly for routers with Cut Through Flow control. This component can simulate different routing policies, according to the routingControl variable.
- DOR-MUX: Dimension Ordered Routing with a priority policy based on message type (higher type -> higher priority).
- DOR-MUX-BUBBLE: DOR with occupation restrictions (Bubble Flow control).
- DOR-MUX-ADAP: Fully Adaptive Routing, following always minimal routes. Also implements Bubble flow control.
Crossbar
This unit is in charge of emulating physical crossbar and in most cases arbitration units (both Virtual Channel arbitration and Switch arbitration). In some cases it will also be in charge of performing routing operations (when no routing units are present in the sgml router description). This component dictates how the router behaves, being for this reason the one with more available types. Here, only a brief description of the main characteristics of each type is provided.
- WH: Crossbar structure for a simple router with flit-level flow control and without virtual channels. It does not perform routing, therefore it requires routing units connected to crossbar inputs.
- WH-RTG: Wormhole crossbar which includes routing logic. In this case, input buffers are directly connected to crossbar ports.
- CT: Crossbar with Cut-Through flow control. Inputs to the crossbar are not multiplexed, so each buffer is connected to a single routing unit, and each routing unit to a single port.
- CTM: Same as previous one, but in this case the inputs to the crossbar are multiplexed.
- VC: Virtual Channel router with flit-level flow control. It incorporates routing, VC arbitration and SW arbitration (no routing units needed). Input from the same physical port are not multiplexed (larger crossbar).
- VC-OPT: Same as previous one, but with pipeline optimizations. Prepared to emulate 1-cycle router bypassed under a certain set of conditions.
- VC-MUX: Same as VC, but input buffers from the same port are multiplexed. Two buffers from the same port are not allowed to make use of the crossbar simultaneously.
- VC-MUX-OPT: Previous one with pipeline optimizations.
- VC-TORUS: This Virtual Channel router is prepared to work in Torus topologies. It requires a minimum of two virtual channels per message type to avoid deadlock through dally's mechanism.
- VC-TORUS-MUX: VC-TORUS with multiplexed inputs from each input port.
- MUX-CT: This crossbar is employed with multiplexed routing units. No routing is required and only output port access is arbitrated at the crossbar.
####Other Components####
Routing
This is a routing unit with a single input port. This means that one unit per input buffer is required in those routers using it. It is only available to implement Dimension Ordered Routing without (DOR) or with Bubble flow control (DOR-BU). Buffering flow control must be performed at packet level when making use of this component.
MPBuffer This component represent a buffer with a variable number of write ports and a single read port. This kind of buffer is only available for CT flow control. The order followed to read messages from the buffer is based on strict priority, extracted from the message type value. Different policies are easily implementable.
Multiplexor/Demultiplexor
Extremely simple components whose behavior may be easily deduced from component name. Currently they are limited to packet-level flow control, and follow strict Round-Robin policies to grant next input/output.