Systems and methods for label-based synchronization of tasks for machine learning operations

Abstract

Embodiments of the present disclosure relate to systems and methods for label-based synchronization of tasks for machine learning operations. A new approach for supporting label-based synchronization among different tasks of a machine learning (ML) operation. When a first task labeled with a set label indicating that one or more subsequent tasks need to be synchronized with it is received at an instruction stream engine, the engine saves the set label in a label table and transmits the instructions of the first task to a set of processing tiles for execution. When a second task with a synchronization label indicating that it needs to be synchronized with one or more previous tasks is received at the engine, the engine matches the instruction synchronization label with the set labels in the label table to identify the previous tasks on which the second task depends. The instruction stream engine holds the instructions of the second task until these matching previous tasks have been completed and then releases the instructions to the processing tiles for execution.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 950,745, filed on December 19, 2019, entitled “Tag based synchronization,” which is incorporated herein by reference in its entirety. Technical Field

[0003] Embodiments of the present disclosure relate to the field of machine learning, and more particularly, to a system and method for label-based synchronization of tasks for machine learning operations. Background Art

[0004] Hardware-based machine learning (ML) systems typically include multiple cores / subsystems (processing blocks or tiles), each with its own processing unit and on-chip memory (OCM) for executing ML applications / operations. ML applications typically include multiple tasks, where each task may include multiple programmable instructions that are gathered from a compiler and transferred to an instruction stream engine and executed by the ML system to complete the task. Some of the tasks may be executed independently on a processing tile without relying on other tasks to be executed, while some other tasks may have dependencies on other tasks and can only be scheduled after the other tasks are first executed by the processing tile. As such, the scheduling of tasks with dependencies needs to be synchronized.

[0005] Currently, since synchronization is not required, instructions for tasks that do not have dependencies are sent by the instruction stream engine to the processing tile. For tasks that do require synchronization (received with a synchronization flag (e.g., INS_Sync)), the default mode of synchronization is that the instruction stream engine holds the instructions for the task and waits for all previous tasks that arrived / scheduled before the task to be executed first before sending the instructions for the current task to the processing tile, even if the current task does not depend on all of those previous tasks. Such a synchronization process is considered heavyweight in terms of the wait time for the current task to be executed, and since some of the processing tiles in the processing tile may be kept idle during the wait time, it may result in a performance loss.

[0006] The foregoing examples of the related art and limitations thereof are intended to be illustrative and not exhaustive. Other limitations of the related art will become apparent upon reading the specification and studying the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Various aspects of the present disclosure will be best understood when the following detailed description is read in conjunction with the accompanying drawings. It should be noted that, in accordance with standard industry practice, the various features are not drawn to scale. In fact, the dimensions of the various features may be arbitrarily increased or decreased for clarity of discussion.

[0008] Figure 1 Depicted is an example of a diagram of a hardware-based programmable architecture for supporting tag-based synchronization of processing tiles for machine learning according to one aspect of the embodiments herein.

[0009] Figure 2 A flow diagram depicting an example of a process for supporting tag-based synchronization of processing tiles for machine learning according to one aspect of embodiments herein is depicted. DETAILED DESCRIPTION

[0010] The following disclosure provides many different embodiments, or examples, for implementing the different features of the subject matter of the present disclosure. Specific examples of components and arrangements are described below to simplify the present disclosure. Of course, these are merely examples and are not intended to be limiting. In addition, the present disclosure may repeat reference numerals and / or reference letters in various examples. This repetition is for simplicity and clarity and does not, in itself, indicate the relationship between the various embodiments and / or configurations discussed.

[0011] Before discussing various embodiments in more detail, it should be understood that each embodiment is not restrictive, because the element in such embodiment can change.Should be understood similarly that the specific embodiment described and / or illustrated herein has elements, these elements can be easily separated from the specific embodiment, and can optionally be combined with any embodiment in several other embodiments or replace the element in any embodiment in several other embodiments described herein.It should also be understood that the term used herein is in order to describe some concepts, and the term is not intended to be restrictive.Unless otherwise limited, all technical terms and scientific terms used herein have the same implication as the implication commonly understood in the field to which the embodiment belongs.

[0012] A new approach is proposed that considers systems and methods for supporting a tag-based synchronization scheme for fine-grained synchronization between different tasks in machine learning (ML) operations / applications. Specifically, when a first task marked with a setup tag (the setup tag indicating that one or more subsequent / later tasks need to be synchronized with the first task) is received at an instruction flow engine, the instruction flow engine saves the setup tag in a tag table and transmits the instructions of the first task to a set of processing tiles for execution based on its destination mask. When a second task with an instruction synchronization tag (the instruction synchronization tag indicating that the second task needs to be synchronized with one or more previous tasks) is received at the instruction flow engine, the instruction flow engine matches the instruction synchronization tag with the setup tags maintained in the tag table to identify one or more matching previous tasks on which the second task depends. The instruction flow engine retains the instructions of the second task until all of these matching previous tasks have been completed. The instruction flow engine then releases and transmits the instructions of the second task to the processing tiles for execution based on the destination mask of the second task.

[0013] Under the proposed tag-based synchronization method for resolving dependencies between tasks, a task that needs to synchronize with one or more previous tasks only needs to wait for the completion of those specific tasks on which it depends, thereby eliminating the need to wait for all previous tasks before it to complete. As a result, the waiting time before a task can be executed by a processing tile is significantly reduced. Such a tag-based synchronization method also improves the utilization of processing tiles because the idle time of a processing tile between the execution of instructions of two tasks is significantly reduced.

[0014] Figure 1 Depicted is an example of a diagram of a hardware-based programmable architecture 100 configured to support tag-based synchronization of processing tiles for machine learning. Although the diagram depicts components as being functionally separate, such description is for illustrative purposes only. It will be apparent that the components depicted in the figure can be arbitrarily combined or divided into separate software, firmware, and / or hardware components. Furthermore, it will also be apparent that regardless of how such components are combined or divided, such components can be executed on the same host or on multiple hosts, and wherein the multiple hosts can be connected by one or more networks.

[0015] exist Figure 1 In the example of FIG. 1 , the architecture 100 includes an instruction stream converter / flow engine 102, a plurality of instruction routers 104, and a two-dimensional array (e.g., Figure 11 ), wherein each processing brick 106 includes a set of (e.g., four) processing tiles 108 connected or coupled to each other via a router 110 to form the processing brick 106. The architecture 100 also includes a plurality of bidirectional links / interconnects 112 that interconnect the instruction flow engine 102, the instruction router 104, the router 110, and the DOD (DDR-OCMDMA) 114 to form the architecture 100. Each of these components in the mesh architecture 100 is a dedicated hardware block / component that is programmable for various machine learning operations by a user at a host (not shown) via a PCIe interface via software instructions through the flow engine 102. When the software instructions are executed, each of the hardware components becomes a dedicated hardware component for performing certain machine learning functions. In some embodiments, the mesh architecture 100 is on a single chip (e.g., a system on a chip (SOC)).

[0016] In some embodiments, each processing tile 108 further includes at least an on-chip memory (OCM) 116, a first type of processing unit (e.g., POD) 118, and a second type of processing unit (e.g., PE) 120. Each OCM 116 in a processing tile 108 includes one or more memory tiles / memory banks and is configured to accept and maintain data in a streaming manner for local access by the processing unit for various ML operations. In some embodiments, each POD 118 is configured to perform intensive or regular computations on data in the OCM 116, for example, matrix operations such as matrix multiplication and matrix manipulation. Each PE 120 is configured to perform sparse / irregular computations and / or complex data shape transformations on data in the OCM 116 and / or from the POD 118. Each processing brick 106 and its processing tile 108 can be programmed according to one or more programming instructions received from the instruction stream engine 102.

[0017] exist Figure 1 In the example of FIG, architecture 100 includes three primary independent networks for transferring programming instructions from instruction stream engine 102 to processing bricks 106 and their processing tiles 108, for transferring data packets from memory units (not shown) to processing bricks 106 via DOD 114 and between processing bricks 106, and for synchronizing the operations of processing tiles 108. In some embodiments, the three different networks are physically separate and do not share any resources such as interconnect 112.

[0018] exist Figure 1In an example, the instruction stream engine 102 is configured to receive / accept an ML task (or tasks) created by a compiler running on a host (not shown), wherein the task includes a set of programming instructions to be consumed by a set of processing bricks 106 and their processing tiles 108 for the task. In some embodiments, each task has an associated destination mask, wherein each bit in the destination mask indicates a corresponding destination processing brick and / or processing tile to which the instructions of the task must be sent for execution. If a bit in the destination mask is set to 1, the task is transferred / assigned to the corresponding processing brick 106 or processing tile 108 for execution. In some embodiments, the destination mask is passed by the instruction stream engine 102 along with the instructions of the task.

[0019] In some embodiments, the current task received by the instruction stream engine 102 arrives with an associated set_tag, which is a non-zero identifier indicating that one or more subsequent tasks may depend on the current task and therefore need to be synchronized with the current task. For example, before one or more subsequent tasks received after the current task can proceed to be executed, the one or more subsequent tasks must wait for the processing brick 106 and their processing tile 108 to finish executing the current task. In some embodiments, set_tag is a multi-digit (e.g., 5-digit) number specified by the user. Since a value of 0 means no tag, set_tag needs to be a non-zero value to be a valid tag. In some embodiments, multiple tasks can share the same set_tag, indicating that these tasks may need to synchronize with the same group of later tasks.

[0020] In some embodiments, each of one or more later tasks received by the instruction stream engine 102 has an instruction synchronization tag, ins_sync_tag, which is a non-zero identifier pointing to a tag set on a previous task (e.g., the current task) with which the later task will synchronize. Like set_tag, ins_sync_tag must be a non-zero value to be a valid tag, with 0 meaning no tag. In some embodiments, a later task may need to synchronize with multiple previous tasks with the same tag. Note that ins_sync_tag is only valid if the associated task has a synchronization flag (e.g., INS_Sync) set (e.g., sync_bits is 11). If ins_sync_tag is 0 and the synchronization flag is set, the task synchronizes with the immediately preceding task. In some embodiments, a task may arrive with both set_tag and ins_sync_tag because the task may need to synchronize with one or more previous tasks and also be dependent on by the later task. In some embodiments, when the task's instructions are compiled, both the set_tag and ins_sync_tag of the task are set by the compiler, which is aware of the dependencies between the tasks.

[0021] exist Figure 1 In an example of FIG, the instruction flow engine 102 is configured to determine the scheduling of tasks, such as when the instructions of a task are transmitted according to the destination mask of the task and executed by the corresponding processing brick 106 and processing tile 108. In some embodiments, the instruction flow engine 102 is configured to maintain a tag table 111, which includes the set_tags of all received tasks that have a set_tag and are executed by their corresponding processing bricks 106 and processing tiles 108. When a task with a non-zero set_tag is received, the instruction flow engine 102 is configured to send a global synchronization message (e.g., global_sync) to the processing brick and processing tile for the task for global synchronization of the task as described below, and insert the global_sync into the tag table 111. The instruction flow engine 102 then saves the set_tag to the tag table 111 entry corresponding to the global_sync for synchronization with later tasks.

[0022] In some embodiments, once set_tag has been saved in tag table 111, instruction flow engine 102 is configured to transmit the task's instructions (and global_sync) horizontally to one or more instruction routers 104 according to the task's destination mask, wherein each of the one or more instruction routers 104 is positioned in a column of the two-dimensional array of processing bricks 106 and processing tiles 108 assigned to the task. The one or more instruction routers 104 then transmit the task's instructions vertically to the processing bricks 106 and processing tiles 108 at the corresponding rows for processing according to the destination mask. In some embodiments, once all of the processing bricks 106 and their processing tiles 108 assigned by global_sync (and receiving global_sync) have completed the execution of the ML task, one or more of the processing bricks 106 and / or their processing tiles 108 send a response (e.g., one bit per processing tile) to the instruction flow engine 102, notifying the instruction flow engine 102 that the execution of the ML task has been completed. When the responses from these processing bricks 106 and / or processing tiles 108 that executed the ML task have been received, the instruction flow engine 102 invalidates the set_tag of the task or removes it from the tag table, because future tasks no longer need to synchronize with the task. In some embodiments, one or more of the processing bricks 106 and / or processing tiles 108 are configured to monitor the remaining processing bricks 106 and processing tiles 108 that are performing the same task, and one of them is configured to send a response back to the instruction stream engine 102 when all of them have completed the instructions for performing the task.

[0023] In some embodiments, when a task with a non-zero ins_sync_tag is received by the instruction flow engine 102, the instruction flow engine 102 first checks whether the synchronization flag is set for the task (e.g., whether the corresponding sync_bits in the task is set to 11). If the synchronization flag is not set, the instruction flow engine 102 ignores the ins_sync_tag and flags a non-fatal error for the task. If the synchronization flag is set, the instruction flow engine 102 is configured to check the entries in the tag table 111 for any (multiple) tags that match the ins_sync_tag of the task. If there is no match, the task does not require synchronization with any previous task, and the instruction flow engine 102 proceeds to transfer the task's instructions to its corresponding brick 106 and processing tile 108 for execution, as described above, because the previous task on which the current task depends has been completed and its tag has been removed from the tag table 111. If there is a match, indicating that the previous task(s) on which the current task depends are still being executed by the corresponding processing brick 106 and processing tile 108, the instruction flow engine 102 is configured to retain the task's instructions (instead of transmitting the instructions to the instruction router 104) until the corresponding / matching entry in the tag table 111 is invalidated or removed, indicating that synchronization with the previous task(s) on which the current task depends has completed. Note that there may be multiple entries in the tag table 111 that match the ins_sync_tag of the task. In that case, the instruction flow engine 102 retains the task's instructions until all matching entries in the matching entries in the tag table 111 are invalidated or removed. In the case where the sync flag is set but the ins_sync_tag is zero, the task is treated as a standard ins_sync task, and the instruction flow engine 102 is configured to retain the task's instructions until its immediate previous task is completed. For a task that has both set_tag and ins_sync_tag set, ins_sync_tag takes precedence over set_tag because ins_sync_tag requires pre-task operations, ie, the previous task needs to have completed first, whereas set_tag only requires post-task operations.

[0024] The following is a non-limiting example illustrating the operation of the architecture 100 for tag-based synchronization of tasks. In this non-limiting example, task #3 is received by the instruction flow engine 102, where task #3 has a set_tag (e.g., 20) indicating that task #3 is later required by a different task #11 that depends on it. The instruction flow engine 102 saves the set_tag 20 of task #3 to the tag table 111 and transmits the instructions of task #3 to a set of processing bricks 106 and tiles 108 for execution via a set of instruction routers 104 based on the destination mask of task #3. When task #11 with the ins_sync_tag (e.g., 20) is received by the instruction flow engine 102, the instruction flow engine searches the tag table 111 to find an entry that matches the ins_sync_tag. If, by then, Task #3 has been completed by processing brick 106 and tile 108, the entry corresponding to Task #3 in the tag table will have been cleared / removed, and no match will be found in tag table 111, indicating that Task #3, on which Task #11 depends, has already been executed and completed. Thus, Task #11 can be sent to its corresponding processing brick 106 and tile 108 for execution. If Task #3 has not yet been completed by its processing brick 106 and tile 108, a match will be found in tag table 111, indicating that Task #3 is still being processed. As a result, the instructions for Task #11 are held by the instruction flow engine 102 until the clear signal for Task #3 is received. Meanwhile, other processing bricks 106 and tiles 108 can execute other tasks that do not depend on Task #3. Thus, Task #11 only needs to wait for Task #3 to complete (rather than all previous Tasks #1 to #10 received by the instruction flow engine 102 before Task #11). Thus, tile utilization is maximized, and the amount of waiting time and processing time for each task is reduced because the need to wait until all processing tiles are free when a dependency is encountered is eliminated.

[0025] Use Cases

[0026] A non-limiting example of a use case for tag-based synchronization for the tasks discussed above is synchronizing between two direct memory access (DMA) requests / points, where the second DMA reuses the same memory region used by the first DMA. In this case, the second DMA would need to wait until the task using the first DMA's data has completed. Without tag-based synchronization, the second DMA would have to perform a heavyweight INS_Sync immediately before it, which would hard synchronize and wait for all tasks across the entire compute cluster to complete, even though the tasks using the first DMA may have completed long ago. Any amount of separation between the last use of the first DMA and the second DMA would not help in removing the INS_Sync immediately before the second DMA. This can occur because software reuses OCM space between different layers for weights and activations. If a hard INS_Sync were required to ensure that a later DMA did not overwrite the previous data before it was fully consumed, nearly every DMA would need to be preceded by an INS_Sync, making it impossible to overlap a DMA with a previous task. With tag-based synchronization, the last use of the first DMA can be assigned a tag and synchronized with the second DMA based on that tag. Other tasks can also be scheduled between the two DMA points, so by the time the second DMA is encountered, it is likely that the last use of the first DMA has completed. This will ensure that no hard INS_Sync is required immediately before the second DMA.

[0027] Figure 2 A flowchart 200 depicts an example of a process for supporting tag-based synchronization of processing tiles for machine learning. Although the figure depicts functional steps in a particular order for illustrative purposes, the process is not limited to any particular order or arrangement of steps. Those skilled in the relevant art will understand that the various steps depicted in this figure may be omitted, rearranged, combined, and / or adapted in various ways.

[0028] exist Figure 2In the example of FIG, flowchart 200 begins at block 202, where a first task for an ML operation is received by the instruction stream engine, wherein the first task has a setup tag, which is a non-zero identifier indicating that one or more subsequent tasks need to synchronize with the first task. Flowchart 200 continues to block 204, where the setup tag of the first task is saved to a tag table associated with the instruction stream engine. Flowchart 200 continues to block 206, where, if the first task does not have an instruction synchronization tag, then, based on a destination mask of the first task, the instructions of the first task are transmitted by the instruction stream engine and routed to a set of processing tiles to be executed. Flowchart 200 continues to block 208, where a second task for an ML operation is received by the stream processing engine, wherein the second task has an instruction synchronization tag, which is a non-zero identifier that points to a setup tag on a previous task with which the second task will synchronize. Flowchart 200 continues to block 210, where the instruction synchronization tag of the second task is matched with an entry in the tag table. If a match is found, the flowchart 200 continues to block 212 where the instructions of the second task are held by the instruction flow engine until the matching entry in the tag table is invalidated or removed, indicating that synchronization with the previous task on which the second task depends has been completed. The flowchart 200 ends at block 214 where, based on the destination mask of the second task, the instructions of the second task are released by the instruction flow engine and transferred to a set of processing tiles to be executed.

[0029] The foregoing description of various embodiments of the claimed subject matter has been provided for purposes of illustration and description. The foregoing description is not intended to be exhaustive or to limit the claimed subject matter to the precise forms disclosed. Many modifications and variations will be apparent to those skilled in the art. The embodiments are chosen and described in order to best illustrate the principles of the invention and its practical application, thereby enabling others skilled in the relevant art to understand the claimed subject matter, the various embodiments, and various modifications suitable for the particular use contemplated.

Claims

1. A hardware-based programmable device for supporting label-based synchronization for machine learning (ML), comprising: a plurality of processing blocks arranged in a two-dimensional array of a plurality of rows and columns, wherein each of the plurality of processing blocks includes a plurality of processing tiles connected to each other; as well as An instruction stream engine, wherein the instruction stream engine is configured to: accepting a first task for an ML operation, wherein the first task has a setup tag, the setup tag being a non-zero identifier indicating that one or more subsequent tasks need to synchronize with the first task; Saving the set tag of the first task to a tag table associated with the instruction stream engine; If the first task does not have an instruction synchronization tag, transmitting and routing instructions of the first task to a set of processing tiles to be executed based on a destination mask of the first task; accepting a second task for the ML operation, wherein the second task has an instruction synchronization tag, the instruction synchronization tag being a non-zero identifier pointing to a set tag on a previous task with which the second task is to synchronize; matching the instruction synchronization tag of the second task with an entry in the tag table; If a match is found, holding the instructions of the second task until the matching entry in the tag table is invalidated or removed, the matching entry in the tag table being invalidated or removed indicating that the synchronization with the previous task on which the second task depends has completed; as well as Based on the destination mask of the second task, the instructions of the second task are released and transferred to a set of processing tiles to be executed.

2. The hardware-based programmable device of claim 1 , further comprising: a plurality of instruction routers, each instruction router of the plurality of instruction routers being associated with one of the columns in the processing block, wherein each instruction router of the plurality of instruction routers is configured to: receiving the instruction transmitted horizontally from the instruction stream engine; as well as The received instructions are routed vertically to the processing tiles at different rows in the columns.

3. The hardware-based programmable device of claim 1 , wherein: Each of the processing tiles further comprises: an on-chip memory OCM comprising one or more memory tiles configured to accept and maintain data for access by one or more processing units for the ML operation; The one or more processing units include: a first processing unit configured to perform intensive computation or regular computation on the data in the OCM; and A second processing unit is configured to perform sparse calculation / irregular calculation and / or complex data shape transformation on the data in the OCM and / or from the first processing unit.

4. The hardware-based programmable device of claim 1 , wherein: Each bit in the destination mask represents a corresponding destination processing tile, which is associated with executing the instruction of the first task or executing the instruction of the second task.

5. The hardware-based programmable device of claim 1 , wherein: One of the first task or the second task has both a setup tag and an instruction synchronization tag, which indicate that the task needs to synchronize with one or more previous tasks and is simultaneously dependent on by one or more later tasks.

6. The hardware-based programmable device of claim 5, wherein: When the one of the first task or the second task has both the setup tag and the instruction synchronization tag, the instruction synchronization tag takes precedence over the setup tag.

7. The hardware-based programmable device of claim 1 , wherein: Multiple first tasks share the same setup tag, which indicates that these tasks will be synchronized with the same set of later tasks.

8. The hardware-based programmable device of claim 1 , wherein: The instruction synchronization tag of the second task matches more than one setup tag in the tag table.

9. The hardware-based programmable device of claim 8, wherein: The instruction flow engine is configured to hold the instruction of the second task until all matching entries in the tag table are invalidated or removed, indicating that the synchronization with all previous tasks on which the second task depends is completed.

10. The hardware-based programmable device of claim 1 , wherein: The instruction flow engine is configured to send a global synchronization message to the processing tile for the first task according to the destination mask of the first task for global synchronization of the first task.

11. The hardware-based programmable device of claim 1 , wherein: The set of processing tiles executing the instructions of the first task are configured to send a response to notify the instruction stream engine that execution of the instructions has completed.

12. The hardware-based programmable device of claim 11 , wherein: The instruction flow engine is configured to remove the set tag of the first task from the tag table when responses from the set of processing tiles that executed the instruction of the first task have been received.

13. The hardware-based programmable device of claim 11 , wherein: One or more of the processing tiles that execute the instructions for the first task are configured to monitor other processing tiles that execute the first task, wherein one of the processing tiles is configured to send a response back to the instruction stream engine when all of the processing tiles associated with the execution of the instructions for the first task have completed executing the instructions for the first task.

14. The hardware-based programmable device of claim 1 , wherein: The instruction flow engine is configured to transmit the instructions of the second task to its corresponding processing tile for execution in response to a mismatch indicating that the second task does not require synchronization with any previous task.

15. A method for supporting label-based synchronization for machine learning (ML), comprising: accepting a first task for an ML operation, wherein the first task has a setup tag, the setup tag being a non-zero identifier indicating that one or more subsequent tasks need to synchronize with the first task; Saving the set tag of the first task to a tag table associated with an instruction stream engine; If the first task does not have an instruction synchronization tag, transmitting and routing instructions of the first task to a set of processing tiles to be executed based on a destination mask of the first task; accepting a second task for the ML operation, wherein the second task has an instruction synchronization tag, the instruction synchronization tag being a non-zero identifier pointing to a set tag on a previous task with which the second task is to synchronize; matching the instruction synchronization tag of the second task with an entry in the tag table; If a match is found, holding the instructions of the second task until the matching entry in the tag table is invalidated or removed, the matching entry in the tag table being invalidated or removed indicating that the synchronization with the previous task on which the second task depends has completed; as well as Based on the destination mask of the second task, the instructions of the second task are released and transferred to a set of processing tiles to be executed.

16. The method according to claim 15, further comprising: When the instruction synchronization tag of the second task matches more than one set tag in the tag table, the instruction of the second task is held until all matching entries in the tag table are invalidated or removed, and all matching entries in the tag table being invalidated or removed indicates that the synchronization with all previous tasks on which the second task depends has been completed.

17. The method according to claim 15, further comprising: A global synchronization message is sent to the processing tile for the first task according to the destination mask of the first task for global synchronization of the first task.

18. The method according to claim 15, further comprising: Responses are sent by the set of processing tiles executing the instructions of the first task to notify the instruction stream engine that the execution of the instructions has completed.

19. The method according to claim 18, further comprising: When responses from the set of processing tiles executing the instructions of the first task have been received, the setup tag of the first task is removed from the tag table because future tasks no longer need to synchronize with the first task.

20. The method of claim 18, further comprising: One or more of the processing tiles that execute the instructions for the first task monitor other processing tiles that execute the first task, wherein one of the processing tiles is configured to send a response back to the instruction stream engine when all of the processing tiles associated with the execution of the instructions for the first task have completed executing the instructions for the first task.

21. The method of claim 15, further comprising: The instructions of the second task are transferred to its corresponding processing tile for execution in response to a mismatch, the mismatch indicating that the second task does not require synchronization with any previous task.

Images