Print indd

4.1
Hardware Implementation
Basically, the hardware implementation works similar to the software implemen-
tation. The difference is a dedicated receive logic to process ready flits indepen-
dent from data flits: ready flits are processed by our new logic, while data flits
are still processed on the processing element. For the differentiation of ready and
data flits, we introduce an additional 1-bit signal isReady everywhere between
sender and receive logic. For data flits, it is 0 and for ready flits it is set to 1.
Architectural changes besides the additional signal are colored in grey in Fig.
4
.
A node consists of a processing element with local memory, which is connected
to the network router via a NI. The original NI comprises a send and receive
buffer. Now we extend the NI by a hardware bit array, which is called Bit Array
in the Figure. It stores the source nodes’ id of incoming ready flits and as such
has the same role as the array in the software implementation.
A multiplexer denoted as MUX in Fig.
4
is required to distinguish each incom-
ing flit if it is a ready or data flit. This is done via the isReady signal. Therefore,
data flits are stored in the receive buffer just as normal and when the isReady
Fig. 4. Hardware structure of a node: processing element with local memory, connected
to the NoC router via a NI containing send buffer, receive buffer and hardware bit
array. Furthermore, there is a multiplexer to distinguish between ready and data flits.
Components added by our approach are colored in grey.
4
At some architectures, this might be solved with a header flit. However, not all
architectures support this approach, see for example the RC/MC architecture [
10
].

---

Lightweight Hardware Synchronization for Avoiding Buffer Overflows in NoC
119
signal is set the sender’s corresponding bit in the hardware bit array is set to 1.
Each node has its own bit array where each bit corresponds to one particular
node.
When a node wants to send data to some other node, it can check the bit
array if the corresponding node is ready. As shown in Fig.
4
, the processing
element should have direct access to the bit array to check the state. All flits
that arrive at the node are either needed by the processing element (data which
was requested and is now processed) or they are ready synchronization flits. The
latter do not reach the processing element, but are processed in the NI and put
in the hardware bit array. Therefore, it is avoided that flits which are currently
not needed reach the processing element. Furthermore, this is a very scalable
solution since each additional node only needs one bit of additional storage per
node.