1. Distributed Sequencing for Resource Sharing in Multi-Applicative Heterogeneous NoC Platforms 林鼎原 Department of Electrical Engineering National Cheng Kung University Tainan, Taiwan, R.O.C 2016/7/1 1 隱藏之投影片 ★★★ Xen ??? To be studied :

2. 2 Abstract(1/1)  While static reconfiguration between applications has already been extensively studied, we propose a potential increase in hardware resource usage by enabling concurrent or overlapping applications on the top of a heterogeneous NoC platform.  In this paper, we describe a distributed sequencing protocol allowing hardware resource sharing between several applications.  This protocol ensures correct synchronization of the processing between hardware resources without the need of a global fine-grain scheduler on the system, thus alleviating the pressure on the run-time system.

3. 3 Introduction  While last decade’s Application Specific Integrated Circuits (ASICs) had been designed to fulfill a single well defined application, the present decade has been, for consumer electronics, the one of Systems-on-Chip (SoC).  There has been a race for the integration of more and more functionality, and the limiting factor has soon become the interconnect architecture.  Nevertheless, the development of Networks-on-Chip (NoC) has broken this wall by allowing for more complex interconnect topologies on which information is carried within data packet.

4. 4 Introduction  Using the NoC technology, it is now not so rare to find more than a hundred cores in the bigger SoCs,  massively parallel homogeneous single-chip multiprocessors  heterogeneous manycores SoCs.  In order to maximize utilization of these flexible resources, it is possible to map several tasks on a same reconfigurable hardware.

5. 5 Application segmenting & composition(1/4) Spatial segmenting of an application:  In various cases, there may be a need for a larger buffering capacity, in the case of data-dependent processing, where the previous data decoded determines a parameterization of the current processing, or large data reordering, e.g. transposition of large matrices.  For that reason, the targeted data-flow applications present specific PEs, which essentially have a large buffering function, that we will call memory buffers (MBs).  The coexistence of multiple applications on the network on chip is possible only if one can stall the other applications in MBs( memory buffers ), while access to the shared resources is granted only to the elected application.  Hence, applications should be segmented using MBs, so that portions of applications that are exclusive can be limited in space.  MBs are dedicated to store data of a single task  Each disconnected component of the task graph, including the MBs at the boundary will be called a “ segment ” in the following.

6. 6 Application segmenting & composition(2/4) Compound task graph :  Given the mapping of the tasks of each application on the hardware resources of the NoC platform, it is possible to derive a composition of several task graphs.  The result is a directed graph,  nodes are labeled with the set of applications using the corresponding hardware resource  Square nodes will be MBs, round nodes will be PEs.  As the segments defined on each application are considered together, they may intersect and form “ multi-segments ”, defined as the union of the application segments sharing at least a common node,  as shown in Figure 1.

7. 7 Application segmenting & composition(3/4)  Square nodes will be MBs (memory buffers)  Round nodes will be PEs (processing elements) Figure 1. Labeled compound task graph for composition of two (similar) applications a1 and a2, with associated segmenting

8. 8 Application segmenting & composition(4/4) Inter-segment spatial task parallelization:  For a well segmented system containing several concurrent applications, considering that data of each application may be stalled in the MBs at the boundaries of each segment or multi-segment,  the scheduling of the application on each multi-segment is independent from the others.  Indeed, provided that sufficient data is present in the input MBs of a multi- segment, and that sufficient free space is available in the output MBs of the multi-segment, there is no dependency outside of the multi-segment.  As an example multi-segments 1 and 3 could be running application a1 while multi-segment 2 would run application a2 (Figure 1).

9. 9 Intra-segment task synchronization protocol(1/8) Scheduling issue for resource sharing:  When multiple applications are competing for several shared resources that may be acquired in a different order by the applications, several issues may induce deadlocks.  We must guarantee that all shared resources switch to the same application together  Risk of deadlock for multiple shared resources when accessed in different orders.  (1)Cyclic dependencies  (2)Flow divergence

10. 10 Intra-segment task synchronization protocol(2/8) 1)Cyclic dependencies :  In Figure 2. On this example, there may be a scheduling where the above shared resource is switched to application a1, while the below shared resource is switched to application a2,  forming a deadly embrace that prevents both applications to acquire the second needed shared resource. Figure 2. Example combination of task graphs leading to a cyclic dependency

11. 11 Intra-segment task synchronization protocol(3/8) 2)Flow divergence:  In this example, there is a potential race condition in the propagation of the applications a1 and a2,  one can find a particular scheduling where the fork in a1 would be propagated first to the above shared node, and try to access the below shared node after that, while this node would already have switched to application a2.  Each application having acquired only one of the shared resources, neither one would be able to propagate on the whole segment Figure 3. Example nonlinear task graphs leading to a race condition

12. 12 Intra-segment task synchronization protocol(4/8)  Our proposal is to enforce the naive concurrent scheduling of applications along their respective data paths by a few added virtual dependencies that would define a consistent switching of the PEs to the same application.  The key element is that the decision to switch to an application should be taken in a single point, and then propagated downstream to all shared nodes in the segment.  Identify the border of the shared subset  Let a single entry point in the border  Create virtual dependencies to and from this entry point:

13. 13 Intra-segment task synchronization protocol(5/8) Shared subset within a multi-segment:  Identify the border of the shared subset  The shared subset of the graph on the multi-segment is defined as the complementary component  It may also be defined as the union of the fanout cones of all the shared nodes of the multi-segment. Figure 4. Shared subset and border identification

14. 14 Intra-segment task synchronization protocol(6/8) Sequencing node selection  Once the shared subset and the multi-applicative border have been identified, what is left to do for single point synchronization is to modify the graph so that the new multi-applicative border is limited to a single node.  Then, this “ sequencing node ” will present a fanout cone that covers all the shared subset:  the decision to switch to either application will propagate to all the shared subset.

15. 15 Intra-segment task synchronization protocol(7/8)  it is possible to derive a final compound task graph for the multi-segment, where a sequencing node has been elected among the shared nodes, and which includes additional arcs ( 箭頭 )to enforce the desired scheduling on the multi-segment, as shown in Figure 5. Figure 5. Sequencing node and added dependencies

16. 16 Intra-segment task synchronization protocol(8/8)  In this example, the dashed arrows ( ) are new dependencies that were added to create a sequencing node.  arcs should be added from the output MBs to the first nodes in the segment, on which signaling messages should be sent when sufficient storage space is available in the MB to absorb all data produced during the session.  The dotted arrows( ) are the (optional) arcs that ensure the end of the propagation of the sequencing node’s decision on the entire shared sub- graph.  additional arcs should be added to notify the sequencing node at the end of the propagation.

17. 17 Conclusion  In order to overcome potential deadlocks in the concurrent scheduling, an algorithm to introduce virtual dependencies between PEs was proposed.  This algorithm prevents the system to perform conflicting scheduling choices in different places by a minimal increase in synchronization between PEs.