Print indd

4
Hardware Supported ready Synchronization
The software implementation leads to several drawbacks: First, all nodes may
receive ready flits from other nodes, which might get data at a later point in the
program execution. They have to handle these ready flits and note that these
nodes are ready. The number of these ready flits is limited to the number of
(other) nodes in the NoC. Therefore, the receive buffer has to be large enough:
besides the entries for data flits, there have to be enough entries for ready flits (as
many as there are other nodes in the NoC). Figure
3
illustrates an example with
8 other nodes: Node D sends a lot of data flits to node E (continuous arrows).
Fig. 3. One node is sending data flits to node E (continuous arrows), all other nodes
send ready flits (dotted arrows) at the same time. Therefore, buffer space is needed for
incoming data as well as for incoming ready flits.

---

118
M. Frieb et al.
Then, all other nodes (A–C, F–I) send their software ready flits to node E at
the same time (dotted arrows). Therefore, the receive buffer of node E has to
be large enough to save the arrived data flits as well as the ready flits from all
other nodes.
Furthermore, it is possible, though very unlikely, that some data flit has
exactly the same payload as a ready flit – how can data and ready flits be
distinguished in a safe way?
4
Finally, program execution is still slowed down
by flits that arrive and have to be handled, but are not needed yet. Therefore,
ready synchronization should be implemented in hardware. Then, ready flits
can be handled in dedicated hardware logic bypassing the normal receive buffer
in the NI. A simple check mechanism for the sender to know whether some node
is ready is provided.