Network interface

The network interface implementation is discussed on this page.

Network Interface

The Network Interface is the "glue" that merge all the component inside a tile that want to communicate with other tile in the NoC. It has several interface with the element inside the tile and an interface with the router. Basically, it has to convert a packet from the tile into flit injected in to the network and viceversa. In order to avoid deadlock, four different virtual network are used: request, forwaded request, response and service network.

The interface to the tile communicate with directory controller, cache controller and service units (boot manager, barrier core unit, synchronization manager). The units use the VN in this way:

The unit is divided in two parts:

TO router, in which the vn_core2net units buffer and convert the packet in flit;
FROM router, in which the vn_net2core units buffer and convert the flit in packet.

These two units support the multicast, sending k times a packet in unicast as many as the destinations are.

The vn_net2core units should be four as well as vn_core2net units, but the response network is linked with the DC and CC at the same time. So the solution is to add another vn_net2core and vn_core2net unit with the same output of the other one. If the output of the NI contains two different output port - so an output arbiter is useless, the two vn_core2net response units, firstly, has to compete among them and, secondly, among all the VN.

Note that packet_body_size is linked with the flit_numb, but we prefer to calculate them separately. (FILT_NUM = ceil(PACKET_BODY/FLIT_PAYLOAD) )

vn_net2core

This module stores incoming flit from the network and rebuilt the original packet. Also, it handles back-pressure informations (credit on/off). A flit is formed by an header and a body, the header has two fields: |TYPE|VCID|. VCID is fixed by the virtual channel ID where the flit is sent. The virtual channel depends on the type of message. The filed TYPE can be: HEAD, BODY, TAIL or HT. It is used by the control units to handles different flits.

When the control unit checks the TAIL or HT header, the packet is complete and stored in packed FIFO output directly connected to the Cache Controller.

E.g. : If those flit sequence occurs:

         1st Flit in => {FLIT_TYPE_HEAD, FLIT_BODY_SIZE'h20}
         2nd Flit in => {FLIT_TYPE_BODY, FLIT_BODY_SIZE'h40}
         3rd Flit in => {FLIT_TYPE_BODY, FLIT_BODY_SIZE'h60}
         4th Flit in => {FLIT_TYPE_TAIL, FLIT_BODY_SIZE'h10};

The rebuilt packet passed to the Cache Controller is:

         Packet out => {FLIT_BODY_SIZE'h10, FLIT_BODY_SIZE'h60, FLIT_BODY_SIZE'h40, FLIT_BODY_SIZE'h20}

A FIFO stores the reconstructed packet. When the CC can read, it asserts packet_consumed bit.

The FIFO threshold is reduced of 2 due to controller: if a sequence of consecutive 1-flit packet arrives, the on-off backpressure almost_full signal will raise up the clock edge after the threshold crossing as usual, so it is important to reduce of 2 the threshold to avoid packet lost. If the packet arriving near the threshold are bigger than 1 flit, the enqueue will be stopped with 1 free buffer space.

Control unit

Flits from the network are not stored in any FIFOs. The router_valid signal is directly connected to the rebuilt packet control unit. In Control Unit all incoming flit are mounted in a packet. It checks the Flit header, if it is a TAIL or a HT type, the control unit stores the composed packet in the output FIFO to the Cache Controller.

N2C_CU

vn_core2net

This module stores the original packet and converts in flit for the network. The conversion in flit starts fetching the packet from an internal queue. When the requestor has to send a packet, it asserts packed_valid bit, directly connected to the FIFO enqueue_en port. Those informations are used by the Control Unit to translate packet in FLITs for each destination.

Control unit

The Control Unit strips the packet from the Cache Controller into N flits for the next router. It checks the packet_has_data field, if a packet does not contain data, the CU generates just a flit (HT type), otherwise it generates N flits. It supports multicasting through multiple unicast messages.

A priority encoder selects from a mask which destination has to be served. All the information of the header flit are straightway filled, but the flit type.

assign packet_dest_pending                 = packet_destinations_valid & ~dest_served;

rr_arbiter # (
   .NUM_REQUESTERS ( DEST_NUMB )
)
rr_arbiter (
   .clk        ( clk                  ) ,
   .reset      ( reset                ) ,
   .request    ( packet_dest_pending  ) ,
   .update_lru ( 1'b0                 ) ,
   .grant_oh   ( destination_grant_oh )
) ;

The units performs the multicast throughout k unicast: when a destination is served (a packet is completed), the corresponding bit in the destination mask is deasserted.

dest_served <= dest_served | destination_grant_oh;

C2N_CU

The units has to know if the multicast is on. In this case, the signal packet_destinations_valid is a bitmap of destination to reach and the real_dest has the TILE_COUNT width; else the signal real_dest contains the (x,y) coordinates of the destination

generate
   if ( DEST_OH == "TRUE" ) begin
      assign
         real_dest.x  = destination_grant_id[`TOT_X_NODE_W - 1 : 0 ],
         real_dest.y  = destination_grant_id[`TOT_Y_NODE_W + `TOT_X_NODE_W - 1 -: `TOT_X_NODE_W];			
   end else 
      assign real_dest = packet_destinations[destination_grant_id];				
endgenerate

Note: if DEST_OH is false, the core_destination signal contains the component ID inside the tile that will receive the packet, else it has no sense.

assign cu_flit_out_header.core_destination = tile_destination_t'( destination_grant_oh[`DEST_TILE_W -1 : 0] );

Network interface

Contents