NA NA NA
Input port
Output ports
(a) Multiple network adapters, where each handles one packet to one destination.
NA
Output port Controller Multicast
Input port
(b) Multicasts are handled in the syn-chronous domain before the network adapter.
Multicast Controller
NA
Input port Output port
(c) Multicasts are handled by a multicast controller inside the network adapter.
Figure 7.4: 3 different proposals for implementing multicast support.
7.4 Multicast
In the current implementation multicasts are implicitly supported because data arrives at all possible destinations1. This is not the case in a packet-switched NoC implementation and instead a packet must be generated for each destination. The following paragraphs go through different possibilities, adding support for multicasts.
Multiple network adapters A simple solution is to create a network adapter for each possible destination. If a port in the original network can send to 3 different destinations this re-quires 3 separate network adapters as illustrated in figure 7.4a. The input port is connected to all three network adapters, which each handles the generation of a single packet. The individual network adapters can be disabled/enabled by a configuration controller.
The disadvantages of this solution are the sizes of the additional network adapters and that the number of input ports in the network increases significantly. This leads to an increase in network size, power usage, and latency. This increase in network size makes this solution infeasible.
Blocks handles multicast If the connected DSP blocks generate a packet for each destination, the network only has to support unicast. This simplifies the network as it does not have to worry about multicasts at all. If the DSP blocks are general purpose processors or similar
1Chapter 5.3
devices, they can generate the packets in software. The DSP blocks in the ’Aphrodite DSP’ are not general purpose processors and the idea in this project is to substitute the current network with a new network having the same functionality. Therefore, this pro-posal is out of the question.
Multicast before the Network Adapters Instead of letting the blocks handle multicasts a spe-cial multicast controller can be inserted between the input ports and the network adapters as illustrated in figure 7.4b. This allows the multicast controller to be implemented in the synchronous domain and the network adapter only needs to handle unicasts
In this solution the networks adapters need a way to tell the multicast controllers that the previous packet has been successfully sent. This indication is asynchronous and must be synchronized in the multicast controller which takes at least 4 clock cycles if a 4-phase protocol is used2. Even though this might not be a problem this solution has not been chosen because of the latency.
Multicast in the Network Adapters The route of a packet is determined in the network adapter and another possibility is to implement the multicast functionality inside the network adapter. Figure 7.4c illustrates how the network adapter contains a multicast controller.
When multicasts are handled in the network adapter, the multicast circuitry can be made both in the synchronous domain or the asynchronous domain. A synchronous solution is analogue to placing the multicast controller before the network adapter and has already been considered. By implementing the multicast controller in the asynchronous domain, no synchronization is necessary between the packets. This also makes it possible to send several packets within the same clock-cycle.
Reusable Multicast blocks In the solutions mentioned so far, one of the major disadvantages is that the number of possible destinations must be known when doing the synthesis and that the multicast circuitry must be included in all network adapters which is foreseen to do multicast. Instead of implementing multicast in the network adapters, a shared multicast block is created. This multicast block receives a single packet on its input and sends two packets on its output. If a block wants to multicast it does not send the packet directly to the destinations. Instead it does an indirect multicast by sending a single packet to one of the shared multicast blocks, which handle the actual multicast. A number of these shared multicast blocks are instantiated according to the needs in the specific application.
Since the multicast blocks are shared, only a subset of the number of multicast blocks are needed and the complexity of the network adapters decreases as they only need to support unicast. The needed number of multicast blocks are the largest number of simultaneously multicasts for all input ports. In this application at most 2 input port are multicasting at the same time.
One question arises when talking about multicast blocks: Where are they to be placed in the network? The placement of the multicast blocks affects both the area and dynamic
2Appendix A goes into detail about synchronization between two different domains
7.4. MULTICAST
Multicast
Router tree Multicast
Merge tree Multicaster blocks Reusable
Additional merger and router
Router Tree Tree
Merge
MC
MC
(a) An additional router and merger are inserted to control access to the multicast net-work which consists of a router tree, multicast blocks and a merger tree.
MC
MC
(b) Example of a unicast.
MC
MC
(c) Example of a multicast. A single packet is sent to one of the multicast blocks which generates two new pack-ets.
Figure 7.5: The reusable multicast blocks are placed at the root of the tree to decrease the latency of multicasts. This example only contains two multicast blocks, but any number of multicast blocks could be inserted.
power consumption. In this project a binary tree topology is implemented and one solu-tion is to increase the size of the network with one addisolu-tional input and output for each multicast block.
Another solution is to place the multicast blocks near the root of the tree, thereby decreas-ing the latency of multicasts. Figure 7.5a illustrates a possible implementation of this. An additional router and merge block are inserted independent of the number of multicast
blocks. Figure 7.5b illustrates a unicast which does not use the multicast blocks, while figure 7.5c illustrates a multicast.
If general a router topology is used, the multicast blocks could be distributed across the router nodes or placed at special router nodes which was reserved to serve multicast.
Two different multicast implementations are compared. In the first, multicasts are handled in the network adapters while the second solution handles multicasts in two shared multicast blocks.