Allocator (for arbitration) - Project-Bonfire/Bonfire GitHub Wiki

The implementation of the allocator in the NoC router with credit-based flow control is illustrated in Fig. 1.

Figure 1. Overview of the allocator unit in NoC router with credit-based flow control

Specifications

  • Allocator (including Arbiter_in and Arbiter_out modules) is a sub-set of router’s control part.

  • Used for managing the following cases:

    1. If adaptive routing is used, LBDR can request more than one output port. However, finally, one output port should be chosen as the candidate port for forwarding the packet (flits). This is handled by Arbiter_in module. Arbiter_in is instantiated per each input port. Arbiter_in is implemented using FSM.
    2. If multiple inputs want to request the same output port, this should be handled in a fair way, in order to avoid contention. This is handled using Arbiter_out module, which implements an FSM-based prioritization mechanism, based on Round-Robin policy. Arbiter_out is instantiated per each output port.

The round-robin prioritization mechanism in Allocator unit always considers the following order for serving the input requests: N-> E-> W-> S-> L ->N -> ... (in a circular manner)

  • Allocator is also in charge of keeping track of the credit counter when giving grant to an input request. In addition it also checks the credit_in signals from the next router/NI (used for the flow control) to know when to update the credit counter:

    1. If credit is given from next router/NI and Allocator has issued a grant to the corresponding output direction (to one of the inputs), that means one flit can leave the current router’s FIFO to be sent to the next router and also the next router has enough slots in FIFO, therefore, the credit counter value at the current router does not change.
    2. If credit is given from next router/NI, but no grant is given from allocator to any inputs, then the credit counter is incremented (it is checked to make sure it does not overflow).
    3. If grant is given from allocator to one of the inputs, but credit is not received from the next router/NI, that means the next router/NI’s FIFO has one less free slot, therefore, the credit counter at the current router is decremented (it is checked to avoid underflowing).

  • Arbiter_in has an internal FSM, which prioritizes the requests from LBDR modules based on Round-Robin policy. The FSM state variable can have 5 possible values: IDLE, North, East, West, South and Local. In order to facilitate single stuck-at fault detection, the state variable can be encoded as one-hot (for our checkers, we have done this).

  • In Arbiter_in, based on the N->E->W->S->L (circular) prioritization the requests from inputs (from LBDR modules) are checked, if one gets granted (which means basically, if the request is high), the corresponding grant signal (X_i , i=N,E,W,S or L) goes high and also based on the direction requested, the state variable of Arbiter_in changes, correspondingly.

Example: Arbiter_in serving the Local input is in IDLE state initially. If A flit comes to the Local FIFO and LBDR of Local input generates two active output requests (let’s assume Req_N and Req_E go high, since the destination is on the North-East quadrant for instance), the requests are fed to the Arbiter_in logic of Local input. The FSM checks FIRST the Request from North input, since, N has higher priority than E, and since Req_N is already ‘1’, North is given priority, therefore, the state variable of the FSM (at the rising edge of the clock cycle) gets updated to NORTH and the corresponding grant signal (X_N) is generated, which is then sent to the Arbiter_out module of Allocator unit. Since North output has already got the grant, the other Request (Req_E) is not checked and ignored at this time. Then Arbiter_out comes to play.

Let’s assume that initially Arbiter_out’s state variable is also set to IDLE. Arbiter_out’s FSM also checks the requests from Arbiter_in modules via the Round-Robin prioritization policy (N->E->W->S->L (circular)). Therefore, the Arbiter_out for North output (N Arbiter_out) first checks request from North. As X_N is already generated by L Arbiter_in, it gets the highest priority and at the rising edge of the clock cycle the state variable of Arbiter_out gets updated to North. Later, when the state is checked, since it is North, it is checked, if the credit counter for North output is not zero and also if the Grant for North provided by L Arbiter_in is still active, the final Grant for North output (Grant_Y_N) is generated and set to ‘1’. That means finally Arbiter_out gives grants to Local input to access North output (and request for East output port is muted). (And since we do not have multi-cast support in our router, only one output port can finally be chosen.)

The final grant provided by the Allocator for this case, which is Grant_N_L (Grant to access N output by L input) by also checking the empty signal which is fed from the L FIFO. Thus, allocator makes sure the FIFO of Local input port is not empty when the grant generated. And finally Grant is generated. Once grant is generated, The select line of XBAR (crossbar switch) for N output port gets the following value: “00001”, This case is assigned to transmit data from Local port to output. Thus XBAR for North output port can transmit the data provided from Local FIFO to the output of the router (North output). And the data is sent to the next neighbor router, located on the North direction.

On reset :

  • All credit counters for all output directions get maximum value (3), meaning that the network is without any traffic, therefore, all FIFOs have all their slots free.

  • For Arbiter_in: In its internal FSM, the state gets initialized to IDLE.

  • For Arbiter_out: In its internal FSM, the state gets initialized to IDLE.