Task mapping and data transfer scheduling method for network-on-chip based multi-core accelerator

Abstract

The application discloses a task mapping and data transmission scheduling method of a multi-core accelerator based on a network on chip, and relates to the technical field of data transmission. The method comprises the following steps: constructing a task hypergraph by taking the transmission data volume as a hyperedge weight, performing hypergraph division corresponding to two-dimensional grid recursive bisection on the task hypergraph, and obtaining initial mapping of the task to a processing core; constructing a multicast routing tree connecting all endpoints for each multicast communication relationship according to the initial mapping, and locating all tree edges of each multicast routing tree on a link surrounded by a bounding box of the multicast routing tree; constructing a conflict graph by taking the multicast routing tree as a vertex and coloring the conflict graph, and making the color number correspond to a time slot of a time division multiplexing frame one by one, so that the multicast routing trees in the same time slot occupy independent links, and when the color number exceeds an upper limit of a frame length, the multicast routing tree with the largest sharing degree is selected to be reconstructed in the bounding box to compress the color number. The application suppresses the multicast link load, compresses the transmission time sequence quantity, and reduces the inter-core communication delay.

Description

Technical Field

[0001] This invention relates to the field of data transmission technology, and in particular to a method for task mapping and data transmission scheduling of multi-core accelerators based on on-chip networks. Background Technology

[0002] On-chip networking (NIC) is the communication infrastructure within a multi-core accelerator that carries inter-core data exchange. It arranges processing cores, routers, and network interfaces in a two-dimensional grid, with adjacent routers interconnected via short-range links, and data forwarded hop-by-hop in packet form. As the number of processing cores integrated on a single chip continues to increase, applications such as artificial intelligence inference, remote sensing image processing, and scientific computing, when running on accelerators, generate a large number of one-to-many data distribution needs between cores, such as weighted broadcasting and intermediate result aggregation. These needs manifest as multicast communication in NIC. How to place tasks on appropriate processing cores and arrange reasonable paths and timings for inter-core data transmission directly determines the accelerator's communication latency and throughput.

[0003] Existing task mapping methods typically aim to minimize communication hops, using heuristic search to place tasks one by one onto grid nodes. Existing data transmission scheduling methods often employ deterministic routing combined with virtual channel arbitration, or time-division multiplexing to divide different data streams into independent time slots. When handling multicast communication, some existing methods split a multicast into multiple point-to-point unicasts, each occupying its own bandwidth; others establish a distribution tree covering all destination nodes for the multicast, and then arrange the transmission timing based on the links occupied by the distribution tree.

[0004] The aforementioned existing technologies exhibit significant shortcomings in dense multicast scenarios. When multicast is split into multiple unicast streams, the same data is repeatedly transmitted on the common link, increasing link load and generating difficult-to-eliminate transmission timing conflicts. When establishing a distribution tree for multicast, path selection and transmission timing arrangement are disconnected. The distribution tree often traverses links shared by a large number of data streams, drastically increasing the number of transmission timings that need to be staggered, forcing the time-division multiplexing frames to lengthen, and consequently increasing communication latency. Furthermore, the load on local processing cores can drift during application operation, and existing methods lack a means to quickly adjust local mappings without interrupting overall transmission. Therefore, there is an urgent need for a task mapping and data transmission scheduling method that can suppress multicast link load, reduce the number of transmission timings, and support rapid local adjustments. Summary of the Invention

[0005] In view of this, the present invention provides a task mapping and data transmission scheduling method for multi-core accelerators based on on-chip networks to solve the problems of high link load, large number of transmission timings, and difficulty in quickly adjusting local mappings when carrying dense multicast communication in existing technologies. The present invention constructs a task hypergraph with the amount of transmitted data as the hyperedge weight and performs hypergraph partitioning corresponding to grid recursive bisection, placing closely communicating tasks in adjacent processing cores; it constructs a multicast routing tree for each multicast communication relationship, with all tree edges located within its own bounding box, so that multicast data is distributed along a single tree without repeatedly occupying common links; it constructs a conflict graph with the multicast routing tree as the vertices and colors it, mapping the color number to the time slot of the time-division multiplexing frame, so that multicast routing trees within the same time slot occupy independent links; when the number of transmission timings exceeds the frame length limit, it reconstructs the multicast routing trees occupying highly shared links within their bounding boxes at the cost of link sharing, thereby compressing the required number of time slots.

[0006] The technical solution adopted in this invention is as follows:

[0007] A task mapping and data transmission scheduling method for multi-core accelerators based on on-chip networks is applied to multi-core accelerators containing a two-dimensional mesh on-chip network. The two-dimensional mesh on-chip network comprises multiple nodes arranged in multiple rows and columns. Each node contains one processing core, one router, and one network interface. Routers of adjacent nodes are connected via bidirectional links. One of the processing cores also serves as the management core. The method includes steps 1 to 3, which are executed by the management core during the application deployment phase.

[0008] Step 1: Obtain the task set and multicast communication relationship set of the application to be deployed. Each task has a computational load, and each multicast communication relationship includes one source task, at least one destination task, and the amount of data transmitted. Construct a task hypergraph with each task in the task set as a vertex, the task group consisting of the source task and all destination tasks of each multicast communication relationship as a hyperedge, and the amount of data transmitted as the hyperedge weight. Perform hypergraph partitioning on the task hypergraph corresponding to the recursive bisection of the two-dimensional mesh on-chip network to obtain the initial mapping from tasks to processing cores.

[0009] Step 2: Based on the initial mapping, the node containing the source task in each multicast communication relationship is designated as the source node, and the node containing the destination task is designated as the destination node. The source node and all destination nodes are collectively referred to as endpoints. The rectangular area enclosed by the minimum and maximum x-coordinates, minimum and maximum y-coordinates of all endpoints in each multicast communication relationship is designated as the bounding box. All nodes whose x-coordinates are between the minimum and maximum x-coordinates and whose y-coordinates are between the minimum and maximum y-coordinates are designated as nodes covered by the bounding box. Nodes on all four boundary coordinates are also included in the nodes covered by the bounding box. Links where both ends are nodes covered by the bounding box are designated as links covered by the bounding box. For each multicast communication relationship with endpoints distributed across two or more nodes, a multicast routing tree connecting all endpoints is constructed. Each edge of the multicast routing tree corresponds to one link in the two-dimensional mesh on-chip network. All edges of each multicast routing tree belong to the links covered by its own bounding box. Data of each multicast communication relationship is transmitted from the source node to all destination nodes along the corresponding multicast routing tree.

[0010] Step 3: Using each multicast routing tree as a vertex in the conflict graph, when any two multicast routing trees occupy at least one of the same links, connect the corresponding two vertices in the conflict graph with an edge; color the conflict graph, assigning a color number to each multicast routing tree. The color numbers of the multicast routing trees corresponding to two vertices connected by an edge in the conflict graph are different. Record the total number of color numbers used as the color number; when the color number is greater than the preset frame length limit, perform tree reconstruction iteration: for each multicast routing tree, sum the number of multicast routing trees that are different from itself on each link it occupies to obtain the sharing degree, and select the multicast routing tree with the highest sharing degree as the reconstruction object; reconstruct the reconstruction object, and re... All edges of the reconstructed multicast routing tree still belong to the links covered by its own bounding box. The connection edges of the corresponding vertices in the conflict graph are updated with the reconstructed multicast routing tree and the coloring is re-executed. The tree reconstruction iteration is repeated until the number of colors is less than or equal to the preset frame length limit or the number of iterations reaches the preset iteration limit. The time-division multiplexing frame contains a number of time slots equal to the number of colors. The color number corresponds one-to-one with the time slot. Each multicast routing tree occupies the link for transmission in the time slot corresponding to its own color number in each time-division multiplexing frame. Each multicast routing tree transmitted in the same time slot occupies an independent link between each other. A time slot table is generated based on the coloring results and all multicast routing trees. The management core distributes the time slot table to each router and each network interface.

[0011] Further, in step 1, each round of bisection in the hypergraph partitioning divides the current vertex set into two vertex subsets and simultaneously divides the current sub-region into two rectangular sub-regions. When the number of rows in the current sub-region is greater than or equal to the number of columns, it is divided along the row direction into two rectangular sub-regions with the smallest difference in the number of nodes (upper and lower). When the number of columns in the current sub-region is greater than the number of rows, it is divided along the column direction into two rectangular sub-regions with the smallest difference in the number of nodes (left and right). The two vertex subsets correspond one-to-one with the two rectangular sub-regions. The goal of each round of bisection is to minimize the sum of the weights of the hyperedges spanning the two vertex subsets and satisfy the balance constraint. The balance constraint is that the absolute value of the difference between the sum of the computational cost of all tasks in each vertex subset and the corresponding target computational cost is less than or equal to the preset balance tolerance. The corresponding target computational cost is equal to the sum of the computational cost of all tasks in the current vertex set multiplied by the ratio of the number of nodes in the corresponding rectangular sub-region to the total number of nodes in the two rectangular sub-regions. Bisection is recursively performed on each vertex subset and its corresponding rectangular sub-region until each rectangular sub-region contains only one node, and all tasks in each vertex subset are mapped to the processing core of the corresponding node.

[0012] Furthermore, in step 1, each round of binary search is implemented using gain iteration: the reduction in the sum of the weights of the super-edges spanning two vertex subsets caused by moving a vertex from its own vertex subset to another vertex subset is recorded as the movement gain. Each time, the vertex that satisfies the balance constraint and has the largest movement gain is moved and the moved vertex is locked. After all vertices are locked, the process reverts to the intermediate partition state where the sum of the weights of the super-edges spanning two vertex subsets is the smallest. The gain iteration is repeated until the sum of the weights of the super-edges spanning two vertex subsets converges.

[0013] Furthermore, in step 2, when the number of endpoints is less than or equal to the preset upper limit of the number of endpoints, a rectangular Steiner minimum tree connecting all endpoints is constructed using a lookup table method as a multicast routing tree: all endpoints are sorted by their horizontal coordinates from smallest to largest, and if the horizontal coordinates are the same, they are sorted by their vertical coordinates from smallest to largest. The ranking of the vertical coordinates of each endpoint after sorting is recorded to obtain the position sequence. The Steiner tree topology lookup table, which is constructed offline, is retrieved using the number of endpoints and the position sequence as indexes. Each index entry of the Steiner tree topology lookup table stores all the potential optimal Steiner tree topologies for the corresponding position sequence. Each Steiner tree topology retrieved is restored to a set of horizontal and vertical line segments on the grid based on the actual coordinates of all endpoints, and the bus length is calculated. The tree restored from the Steiner tree topology with the smallest bus length is selected as the construction result.

[0014] Further, in step 2, when the number of endpoints is greater than the preset upper limit of the number of endpoints, all endpoints are sorted by their horizontal coordinates from smallest to largest. If the horizontal coordinates are the same, they are sorted by their vertical coordinates from smallest to largest. The endpoint in the middle position after sorting is selected as the common endpoint. When the number of endpoints is even, the endpoint in the middle two positions with the earlier position is selected as the common endpoint. The common endpoint and all endpoints in the sorted sequence before the common endpoint are divided into the first endpoint subset. The common endpoint and all endpoints in the sorted sequence after the common endpoint are divided into the second endpoint subset. Trees are constructed for the two endpoint subsets respectively. When the number of endpoints in the endpoint subset is less than or equal to the preset upper limit of the number of endpoints, a lookup table method is used for construction. When the number of endpoints in the endpoint subset is greater than the preset upper limit of the number of endpoints, the partitioning and construction of the endpoint subset are recursively performed. The two trees obtained are connected at the common endpoint to form a tree.

[0015] Further, in step 2, with the source node as the root, the direction of each tree edge is determined to be the direction away from the source node. For each node in the multicast routing tree, the tree edge extending from the node along the direction away from the source node is the downstream tree edge of the node. The network interface corresponding to the source node submits the data packet to the router corresponding to the source node. The router corresponding to the source node sends the data packet along all the downstream tree edges of the source node. Nodes with two or more downstream tree edges are denoted as branch nodes. The router corresponding to the branch node is configured with a replication forwarding table entry. When the data packet arrives at the branch node, the router corresponding to the branch node replicates it according to the replication forwarding table entry and forwards it along all the downstream tree edges of the branch node. The router corresponding to the node with one downstream tree edge forwards the arriving data packet along the downstream tree edge. The router corresponding to the destination node delivers the arriving data packet to the processing core of the destination node through the network interface corresponding to the destination node. When the destination node has a downstream tree edge, it forwards the data packet along the downstream tree edge.

[0016] Furthermore, in step 3, two vertices connected by an edge in the conflict graph are considered adjacent vertices. The coloring of the conflict graph adopts a saturation priority strategy: the number of color types used by the adjacent vertices of a vertex is recorded as the saturation. Each time, the vertex with the highest saturation is selected. When the saturation is the same, the vertex with the larger amount of transmitted data is selected. The selected vertex is assigned the smallest color number that is different from the colors used by all its adjacent vertices, until all vertices are colored.

[0017] Further, in step 3, for each link, the number of multicast routing trees that are different from the reconstructed object in the multicast routing trees traversed by the link is recorded as the shared quantity. The link cost is equal to the sum of the product of the shared penalty coefficient and the shared quantity and 1, and the shared penalty coefficient is greater than 0. The reconstruction of the reconstructed object adopts the point-to-point access method: with the source node as the initial form of the current tree, the weighted shortest path from the destination node to the current tree is calculated for each destination node that is yet to be accessed. The path weight is the sum of the link costs of the traversed links. The search range of the weighted shortest path is limited to the links covered by the bounding box of the reconstructed object. The destination node with the smallest path weight is selected, and all links traversed by the corresponding weighted shortest path are merged into the current tree. The selected destination node is marked as accessed. The access process is repeated until all destination nodes are accessed. When the number of iterations reaches the preset iteration limit and the tree reconstruction iteration ends, the coloring with the smallest color number in the previous coloring is selected, and the coloring result corresponding to the selected coloring and all multicast routing trees at the time of the selected coloring are used. The time slot table is generated based on the final coloring result and all multicast routing trees.

[0018] Furthermore, in step 3, the duration of each time slot in the time-division multiplexing frame is greater than or equal to the maximum value of the transmission completion duration corresponding to each multicast routing tree. The transmission completion duration corresponding to one multicast routing tree is the time required for one data packet to travel from the source node to all destination nodes along the multicast routing tree.

[0019] Furthermore, in step 3, when coloring the conflict graph, more than two color numbers are assigned to the multicast routing tree whose corresponding transmitted data volume is greater than the preset data volume threshold, and one color number is assigned to the multicast routing tree whose corresponding transmitted data volume is less than or equal to the preset data volume threshold. The intersection of the two sets formed by the color numbers held by the two multicast routing trees corresponding to the two vertices connected by the edge in the conflict graph is an empty set. Each multicast routing tree occupies the link transmission in the time slot corresponding to each color number it holds in each time division multiplexing frame.

[0020] By adopting the above technical solution, the present invention has produced the following beneficial effects:

[0021] A task hypergraph is constructed using the amount of transmitted data as the weight of the hyperedges, and the hypergraph partitioning corresponds layer by layer to the recursive binary search of a two-dimensional mesh. This concentrates tasks undertaking the same multicast communication relationship into adjacent processing cores, shortening the propagation range of multicast data in the network from the source and reducing the overall hop count of inter-core communication. A multicast routing tree covering all destination nodes is constructed for each multicast communication relationship. Multicast data is distributed along the tree and replicated at branches. The same data is transmitted only once on any link, avoiding the duplicate occupation of common links caused by splitting multicast into multiple unicasts, thus suppressing link load. All edges of each multicast routing tree are constrained to be inside its own bounding box, strictly limiting the spatial range of the routing tree by the endpoint distribution, providing a simple and reliable spatial basis for determining whether two routing trees occupy independent links. A conflict graph is constructed and colored using the multicast routing trees as vertices, mapping the color numbers one by one to the time slots of time-division multiplexed frames. This ensures that multicast routing trees transmitting in the same time slot occupy mutually independent links, eliminating link contention within the same time slot and making the transmission timing deterministic. When the required number of time slots exceeds the frame length limit, a multicast routing tree occupying a highly shared link is selected. At the cost of link sharing, a new routing tree is re-established within its bounding box, actively avoiding links shared by a large number of routing trees. This compresses the number of transmission sequences and shortens the length of the time-division multiplexed frame. These effects support each other, enabling the invention to achieve both low communication latency, high link utilization, and good scalability. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the overall architecture of the multi-core accelerator based on on-chip network in this embodiment of the invention.

[0023] Figure 2 This is a schematic diagram of the principle of constructing a task hypergraph with tasks as vertices and multicast communication relationships as hyperedges in an embodiment of the present invention;

[0024] Figure 3 This is a schematic diagram of the hypergraph partitioning and task mapping corresponding to the recursive binary search of a two-dimensional mesh in this embodiment of the invention;

[0025] Figure 4 This is a schematic diagram illustrating the principle of constructing a rectangular Steiner minimum tree using a lookup table method in an embodiment of the present invention, ensuring that all tree edges are located inside the bounding box.

[0026] Figure 5 This is a schematic diagram illustrating the principle of constructing a multicast routing tree by dividing and conquering common endpoints when the number of endpoints exceeds the upper limit in an embodiment of the present invention.

[0027] Figure 6 This is a schematic diagram of the principle of constructing a conflict graph with multicast routing trees as vertices and mapping the color numbers to time-division multiplexing frame slots in an embodiment of the present invention;

[0028] Figure 7 This is a schematic diagram illustrating the principle of reconstructing the multicast routing tree occupying the high shared link within the bounding box when the number of colors exceeds the frame length limit in an embodiment of the present invention.

[0029] Figure 8 This is a comparison curve of the method and the control method in terms of color number and average transmission delay in the embodiments of the present invention. Detailed Implementation

[0030] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention. Without conflict, the following embodiments and their technical features can be combined with each other.

[0031] The technical solution of this invention is applicable to multi-core accelerators interconnected by a two-dimensional mesh on-chip network. See also Figure 1 This multi-core accelerator comprises multiple nodes arranged in multiple rows and columns. Each node includes one processing core, one router, and one network interface. The processing core is responsible for executing tasks assigned to its node, the network interface is responsible for transmitting data between the processing core and the router, and the router is responsible for forwarding data within the network. Routers of adjacent nodes are connected via bidirectional links, and data is forwarded hop-by-hop along the links in the network. One processing core is designated as the management core, responsible for the calculation and distribution of task mapping and transmission scheduling. For ease of explanation, the following embodiment uses a two-dimensional mesh on-chip network with 16 nodes in 4 rows and 4 columns as an example. Nodes are identified by their row and column positions using horizontal and vertical coordinates, with the horizontal coordinate increasing along the column direction and the vertical coordinate increasing along the row direction. The horizontal and vertical coordinates of the bottom-left node are both recorded as 0. The number of rows and columns of the mesh can be other values ​​depending on the scale of the accelerator.

[0032] The method of this invention includes steps 1 to 3 performed during the application deployment phase, and a runtime incremental remapping process performed during the accelerator operation phase. Steps 1 to 3 and the runtime incremental remapping process are all executed by the management core, and the results are distributed to each router and each network interface in the form of a timeslot table. The three steps of the deployment phase will be described first, followed by the incremental remapping process during the operation phase.

[0033] Step 1 involves constructing a task hypergraph and performing hypergraph partitioning to obtain the initial mapping. The management core first obtains the task set and multicast communication relationship set of the application to be deployed. Each task in the task set corresponds to a computation that needs to be executed on a certain processing core in the application. Each task has a computational load, which describes the computational load occupied by the task on the processing core. Each multicast communication relationship in the multicast communication relationship set corresponds to a one-to-many data distribution. Each multicast communication relationship includes one source task, at least one destination task, and the amount of data to be transmitted. The source task generates data, and all destination tasks receive the same data. The amount of data to be transmitted describes the scale of data that needs to be transmitted in the network for this distribution.

[0034] After obtaining the two sets mentioned above, the management core constructs a task hypergraph, using each task in the task set as a vertex, the task group consisting of the source task and all destination tasks of each multicast communication relationship as a hyperedge, and the amount of data transmitted in that multicast communication relationship as the weight of the hyperedge. See also... Figure 2 , Figure 2 Taking 8 tasks and 4 multicast communication relationships as an example, the task hypergraph is illustrated. The numbers inside the circles represent tasks, and the closed curves enclosing several tasks represent hyperedges. A hyperedge groups the source tasks and all destination tasks participating in the same multicast communication relationship into the same group. Unlike the representation of one-to-many communication as multiple one-to-one connections, using hyperedges to represent a single multicast as a vertex group allows for the consideration of all tasks belonging to the same multicast as a whole during subsequent partitioning, preventing the distribution of the same data from being fragmented to distant processing cores. Here, the amount of transmitted data is used as the weight of the hyperedge, prioritizing the grouping of tasks involved in multicast communication relationships with large data transmission volumes during the partitioning process. The larger the data transmission volume of a multicast, the more bandwidth it occupies on the link; placing these multicast tasks more compactly reduces the propagation range of large data volumes in the network.

[0035] After obtaining the task hypergraph, the management core performs a hypergraph partitioning corresponding to the recursive bisection of the 2D mesh on-chip network, resulting in the initial mapping from tasks to processing cores. See also... Figure 3Hypergraph partitioning and mesh splitting are performed layer by layer in a corresponding manner. Each round of bisection divides the current vertex set into two vertex subsets and simultaneously divides the current rectangular subregion into two rectangular subregions, ensuring a one-to-one correspondence between the two vertex subsets and the two rectangular subregions. That is, all tasks within one vertex subset are placed within one rectangular subregion, and all tasks within the other vertex subset are placed within the other rectangular subregion. When splitting rectangular subregions, if the number of rows in the current subregion is greater than or equal to the number of columns, the current subregion is split along the row direction into two rectangular subregions with the smallest difference in the number of nodes (upper and lower). If the number of columns in the current subregion is greater than the number of rows, the current subregion is split along the column direction into two rectangular subregions with the smallest difference in the number of nodes (left and right). Each split is performed along the longer one-dimensional axis to make the resulting subregions as close to squares as possible, avoiding the creation of elongated shapes. Elongated subregions have larger maximum distances between nodes, which is detrimental to placing closely communicating tasks in adjacent positions. Figure 3 In the 4x4 grid shown, the first-level bisection divides the grid into two rectangular sub-regions of 4x4 and 2x2 along the column direction. The second-level bisection then divides each sub-region of 4x4 and 2x2 along the row direction into two rectangular sub-regions of 2x2 and 2x2, and so on, layer by layer.

[0036] The goal of each round of binary search is to minimize the sum of the weights of hyperedges that span two vertex subsets, while simultaneously satisfying the balance constraint. A hyperedge spanning two vertex subsets refers to an edge whose vertices belong to two different vertex subsets. The source and destination tasks of the multicast communication relationship corresponding to this type of hyperedge are placed in two different rectangular sub-regions, and the distributed data needs to be transmitted across the boundary between these sub-regions. Minimizing the sum of the weights of hyperedges spanning two vertex subsets is equivalent to minimizing the amount of multicast data that needs to be transmitted across the sub-region boundary, thus confining as much large-volume multicast data as possible within the sub-region. The balance constraint means that the absolute value of the difference between the sum of the computational costs of all tasks within each vertex subset and the corresponding target computational cost is less than or equal to a preset balance tolerance. The corresponding target computational cost is equal to the sum of the computational costs of all tasks within the current vertex set multiplied by the proportion of the number of nodes in the corresponding rectangular sub-region to the total number of nodes in the two rectangular sub-regions. Setting a load balancing constraint ensures that the computational load of tasks placed in each rectangular sub-region matches the number of processing cores available in that sub-region. This prevents situations where nodes in one sub-region are fully utilized while nodes in another sub-region are idle. The target computational load is determined by the proportion of nodes in the corresponding rectangular sub-region, rather than simply dividing the computational load into two equal parts. This is because when the number of rows or columns in the grid is odd, the number of nodes in the two rectangular sub-regions obtained by halving may not be equal. Determining the target computational load by the proportion of nodes ensures that the allocation of computational load is proportional to the actual number of available processing cores, thus maintaining a balance between load and resources even when the number of nodes is unequal.

[0037] The above binary search is recursively performed on each subset of vertices and its corresponding rectangular subregion until each rectangular subregion contains only one node. When a rectangular subregion contains only one node, all tasks within the subset of vertices corresponding to that subregion are mapped to the processing core of that node, thus obtaining the initial mapping from task to processing core. The recursive binary search can progressively narrow down the placement range and ultimately determine the position of each task because each level of partitioning further constrains closely communicating tasks to smaller subregions based on the already concentrated tasks at the previous level. The more closely communicating tasks are separated at later levels, and their final distance on the mesh is also closer.

[0038] Each round of binary search is implemented using gain iteration. Starting from an initial binary partition, gain iteration repeatedly moves vertices between two subsets of vertices to gradually reduce the sum of the weights of the hyperedges crossing the two subsets. The reduction in the sum of the weights of the hyperedges crossing the two subsets caused by moving a vertex from its own subset to another subset is denoted as the vertex's movement gain. A positive movement gain indicates that moving the vertex reduces the sum of the weights of the hyperedges crossing the subset, while a negative movement gain indicates that moving the vertex increases the sum of the weights of the hyperedges crossing the subset. At each step, the vertex with the largest movement gain is selected from those satisfying the balance constraint and moved. Vertices that have already been moved are locked, preventing them from being moved again in this round of gain iteration to avoid the same vertex being repeatedly moved back and forth, which could prevent the iteration from converging. Once all vertices are locked, among the series of intermediate partition states experienced in this round, there exists an intermediate partition state with the smallest sum of the weights of the hyperedges crossing the two subsets. The partition is then reverted to this optimal intermediate partition state, which is taken as the result of this round of gain iteration. After locking all vertices, we backtrack to the intermediate optimal state. The reason for this is that allowing some moves with negative gains first allows the partition to temporarily bypass local unfavorable states, thus reaching a better partition in subsequent steps. Backtracking preserves the optimal result that occurred during this process. We repeat the above gain iteration until the sum of the weights of the hyperedges crossing two vertex subsets no longer decreases, at which point convergence is achieved.

[0039] Step 2 involves constructing a multicast routing tree for each multicast communication relationship based on the initial mapping. After obtaining the initial mapping, each task has been assigned to a specific node, thus the source and destination tasks of each multicast communication relationship are also mapped to specific nodes. The management core designates the node containing the source task of each multicast communication relationship as the source node, and the node containing the destination task as the destination node, and the source node and all destination nodes together are referred to as the endpoints of that multicast communication relationship. The multicast routing tree is used to define the data distribution path of that multicast communication relationship in the network; data starts from the source node and travels along the multicast routing tree to all destination nodes.

[0040] Before constructing the multicast routing tree, the management core first determines the bounding box and the nodes and links covered by the bounding box for each multicast communication relationship. The rectangular area enclosed by the minimum and maximum x-coordinates, and the minimum and maximum y-coordinates of all endpoints of a multicast communication relationship is denoted as the bounding box of that multicast communication relationship. All nodes whose x-coordinates and y-coordinates lie between the minimum and maximum x-coordinates are denoted as nodes covered by the bounding box. Nodes located at all four boundary coordinates are also included in the bounding box's coverage. Links between nodes whose endpoints are both covered by the bounding box are denoted as links covered by the bounding box. Nodes at all four boundary coordinates are also included in the bounding box's coverage, ensuring that the bounding box's coverage includes the endpoints on the rectangular boundaries and the links between them. This guarantees that when determining whether two bounding boxes cover a common link, links on the boundaries are correctly considered, avoiding ambiguity due to unclear boundary node affiliations.

[0041] For each multicast communication relationship with endpoints distributed across two or more nodes, the management core constructs a multicast routing tree connecting all endpoints. If all endpoints of a multicast communication relationship are located on the same node, the data for that multicast communication relationship is transmitted within that node without occupying a link in the network. Two methods are used to construct the multicast routing tree, depending on the number of endpoints.

[0042] When the number of endpoints is less than or equal to the preset upper limit, the management core uses a lookup table to construct a rectangular Steiner minimum tree connecting all endpoints, and uses this rectangular Steiner minimum tree as the multicast routing tree. A rectangular Steiner minimum tree is a tree on a grid that connects all endpoints using horizontal and vertical line segments, with the minimum total length of the line segments. In addition to endpoints, the tree may also contain Steiner points used to converge line segments. See also... Figure 4 , Figure 4Taking a source node and three destination nodes as an example, the constructed rectangular Steiner minimum tree is shown. Squares represent source nodes, circles labeled "destination" represent destination nodes, solid dots represent Steiner points, and bold polylines represent tree edges. The specific execution process of the lookup table method is as follows: The management core first sorts all endpoints by their x-coordinates from smallest to largest. If the x-coordinates are the same, they are sorted by their y-coordinates from smallest to largest. The ranking of each endpoint's y-coordinate among all endpoints is recorded, and these rankings are arranged sequentially to obtain the position sequence. The position sequence describes the relative vertical order of each endpoint, independent of the specific coordinates of the endpoints. Therefore, multiple sets of endpoints with the same number of endpoints and the same position sequence will have the same optimal tree topology. The management core uses the number of endpoints and the position sequence as indexes to retrieve a pre-constructed offline Steiner tree topology lookup table. Each index entry in the Steiner tree topology lookup table stores all potentially optimal Steiner tree topologies for the corresponding position sequence. The reason for pre-building the lookup table offline and directly retrieving it during deployment is that, for a given number of endpoints and position sequence, the potentially optimal set of topologies can be pre-enumerated and fixed. During deployment, there's no need to temporarily search all connection methods, thus transforming tree construction into a single table lookup and a few comparisons, reducing the computational load during deployment. The management core reconstructs each retrieved Steiner tree topology into a set of horizontal and vertical line segments on the grid based on the actual coordinates of all endpoints, calculates the total length of this set, and then selects the tree reconstructed from the Steiner tree topology with the smallest total length as the construction result. The reason for comparing the total length after reconstructing based on actual coordinates is that, while the position sequence determines the topology structure, the total length of line segments will differ for the same topology when different actual coordinates are substituted. Only by substituting actual coordinates can the tree with the smallest total length be selected from several potentially optimal topologies.

[0043] The rectangular Steiner minimum tree possesses a property crucial for subsequent steps in this invention: all its edges lie within the links covered by its own bounding box. This property arises because, to achieve the minimum total length, the horizontal and vertical line segments connecting all endpoints will not exceed the range defined by the minimum and maximum x-coordinates of the endpoints, nor will they exceed the range defined by the minimum and maximum y-coordinates of the endpoints. This is because any line segment exceeding the bounding box can be moved to the boundary of the bounding box without increasing, but rather decreasing, the bus length. Therefore, all edges of the rectangular Steiner minimum tree constructed using the lookup table method naturally fall within the links covered by the bounding box. This invention utilizes this property in subsequent steps to concisely characterize the spatial range occupied by the multicast routing tree in the network using the bounding box determined by the endpoint distribution.

[0044] When the number of endpoints exceeds the preset limit, directly looking up the table would cause the required Steiner tree topology lookup table to expand rapidly with the increase in the number of endpoints, making it difficult to pre-build and store. Therefore, the management core uses a divide-and-conquer approach based on common endpoints to build the multicast routing tree. See also... Figure 5 The management core first sorts all endpoints by their horizontal coordinates from smallest to largest. If the horizontal coordinates are the same, they are sorted by their vertical coordinates from smallest to largest. Then, the endpoint in the middle position after sorting is selected as the common endpoint. When the number of endpoints is even, there are two middle positions, and the endpoint with the higher position is selected as the common endpoint. The management core divides the common endpoint and all endpoints in the sorted order before the common endpoint into the first endpoint subset, and divides the common endpoint and all endpoints in the sorted order after the common endpoint into the second endpoint subset. That is, the common endpoint belongs to both endpoint subsets. By having the common endpoint belong to both endpoint subsets, the two trees built for each endpoint subset contain the common endpoint, and the two trees can be connected into a connected tree at the common endpoint without introducing additional connection nodes. The management core builds trees for the two endpoint subsets separately: when the number of endpoints in the endpoint subset is less than or equal to the preset upper limit of the number of endpoints, the aforementioned lookup table method is used for construction; when the number of endpoints in the endpoint subset is still greater than the preset upper limit of the number of endpoints, the above division and construction based on the common endpoint is recursively performed on the endpoint subset. The two trees constructed by the two endpoint subsets are connected at the common endpoint to form a multicast routing tree for this multicast communication relationship.

[0045] The multicast routing tree constructed by dividing and conquering based on common endpoints also satisfies the property that all tree edges are within the links covered by their own bounding boxes. This is because: the first and second endpoint subsets obtained after sorting by horizontal coordinates will not have their respective endpoint horizontal and vertical coordinate ranges exceeding the ranges of all endpoints. Therefore, the links covered by the bounding boxes of both endpoint subsets belong to the links covered by the bounding boxes of this multicast communication relationship. Furthermore, the tree edges of the two subtrees are located within the links covered by the bounding boxes of their respective endpoint subsets. Thus, after merging, all tree edges of the entire multicast routing tree remain within the links covered by the bounding boxes of this multicast communication relationship. Therefore, regardless of whether the number of endpoints exceeds the upper limit, the constructed multicast routing tree maintains the property that all tree edges are within their own bounding boxes, providing a consistent spatial characterization basis for subsequent steps.

[0046] After the multicast routing tree is constructed, the management core determines the forwarding method of data along the multicast routing tree. The management core uses the source node as the root and determines the direction of each tree edge as the direction away from the source node. For each node in the multicast routing tree, the tree edge extending from that node in the direction away from the source node is called the downstream tree edge of that node. The data forwarding process is as follows: The network interface corresponding to the source node submits the data packet to the router corresponding to the source node. The router corresponding to the source node sends the data packet along all downstream tree edges of the source node. Nodes with two or more downstream tree edges are designated as branch nodes. The router corresponding to the branch node configures a replication forwarding table entry. When a data packet arrives at a branch node, the router corresponding to the branch node replicates the data packet multiple times according to the replication forwarding table entry and forwards it along all downstream tree edges of the branch node. The router corresponding to a node with one downstream tree edge forwards the arriving data packet along that downstream tree edge. The router corresponding to the destination node delivers the arriving data packet to the processing core of the destination node via the network interface corresponding to the destination node. If the destination node also has downstream tree edges, it continues to forward the data packet along the downstream tree edges during delivery. By determining the direction of tree edges using the source node as the root and identifying branch nodes based on the number of downstream tree edges, this approach can uniformly handle two scenarios: the source node has no upstream tree edges, and the intermediate node has one upstream tree edge. When a node has more than two downstream tree edges, regardless of whether it is a source node or an intermediate node, the data needs to be copied multiple times and forwarded separately at that node. Data is only copied at the branch node, ensuring that the same data is transmitted only once on each link before reaching the branch node, avoiding duplicate occupation of the same multicast data on the link.

[0047] Step 3 involves constructing a conflict graph and performing colorized, conflict-free time slot allocation. After constructing multicast routing trees for all multicast communication relationships, different multicast routing trees may occupy the same links in the network. If these multicast routing trees occupying the same links are transmitted at the same time, data contention will occur on the common links. To stagger the multicast routing trees that are contending for links in time, the management core constructs a conflict graph using the multicast routing trees as objects and colors them.

[0048] When constructing the conflict graph, the management core uses each multicast routing tree as a vertex. When any two multicast routing trees occupy at least one identical link, an edge is connected between the corresponding two vertices in the conflict graph. See also... Figure 6 , Figure 6 The left side of the diagram shows a conflict graph constructed with 8 multicast routing trees as vertices. The lines connecting the vertices indicate that the corresponding two multicast routing trees occupy at least one of the same links. The conflict graph abstracts the link occupancy relationship between multicast routing trees into the adjacency relationship between vertices. Two vertices are adjacent if and only if the corresponding two multicast routing trees have a link occupancy conflict.

[0049] The management core colors the conflict graph, assigning a color number to each multicast routing tree and ensuring that the color numbers of the multicast routing trees corresponding to two vertices connected by an edge in the conflict graph are different. Two vertices connected by an edge in the conflict graph are considered adjacent vertices. The coloring process employs a saturation-first strategy: the number of color types used by a vertex's adjacent vertices is recorded as the vertex's saturation. Each time, the vertex with the highest saturation is selected from the uncolored vertices. If multiple vertices have the same saturation, the vertex with the largest transmitted data volume is selected. This selected vertex is assigned the smallest color number that is different from the colors used by all its adjacent vertices. This process is repeated until all vertices are colored. The saturation-first strategy prioritizes vertices with the highest saturation because their adjacent vertices have used the most color types, resulting in the fewest available colors. If these vertices are not colored first, they are likely to be forced to use larger color numbers as their adjacent vertices continue to be colored, thus increasing the total number of colors. Prioritizing these vertices helps keep the total number of colors at a low level. When the saturation is the same, the vertex with the larger amount of transmitted data is selected first, so that the multicast routing tree carrying the larger amount of transmitted data can obtain the smaller color number as early as possible, thus obtaining a better transmission opportunity when mapping the color number to the transmission time slot.

[0050] The management core records the total number of color codes used for coloring as the color count. A time-division multiplexing frame contains a number of time slots equal to the color count, with a one-to-one correspondence between color codes and time slots. Each multicast routing tree occupies a link for transmission within the time slot corresponding to its own color code in each time-division multiplexing frame. See also... Figure 6 On the right side of the graph, when the color number is 3, the time-division multiplexing frame contains 3 time slots. Multicast routing trees with the same color number are arranged for transmission in the same time slot. Since the coloring of the conflict graph ensures that adjacent vertices have different color numbers, and the two multicast routing trees corresponding to adjacent vertices occupy the same link, the multicast routing trees with the same color number that are arranged for transmission in the same time slot will not occupy the same link with each other. That is, the multicast routing trees transmitted in the same time slot occupy independent links with each other. Thus, transmission within the same time slot will not cause contention on any link, and the transmission timing is deterministic. The time-division multiplexing frame cycles through time; after each frame, all multicast routing trees get one transmission opportunity in the time slot corresponding to their color number.

[0051] In some applications, if link conflicts between multicast routing trees are dense, the resulting color number may exceed the preset frame length limit. The preset frame length limit restricts the number of time slots that a time-division multiplexed frame can accommodate. A color number exceeding the preset frame length limit means that the required number of transmission time slots exceeds the capacity of the time-division multiplexed frame. To compress the color number within the preset frame length limit, the management core performs a tree reconstruction iteration when the color number exceeds the preset frame length limit.

[0052] Each round of tree reconstruction iteration begins by selecting a reconstruction target. For each multicast routing tree, the management core sums the number of dissimilar multicast routing trees traversed by that tree on each link it occupies, thus obtaining the tree's sharing degree. A higher sharing degree indicates that more links occupied by that tree are shared by other multicast routing trees, and the degree of link conflict between that tree and other multicast routing trees is higher. The management core selects the multicast routing tree with the highest sharing degree as the reconstruction target for this round, because reconstructing the multicast routing tree with the most severe link conflict has the best chance of reducing adjacency relationships in the conflict graph, thereby reducing the chromatic number.

[0053] After identifying the targets for refactoring, the management core assigns a link cost to each link in the network. (See also...) Figure 7 , Figure 7 The left side shows the high-shared links that the object to be reconstructed traversed before the reconstruction, which were shared by multiple multicast routing trees. For each link, the number of multicast routing trees that are different from the object to be reconstructed traversed on that link is recorded as the shared quantity of that link. The link cost is determined by the following formula:

[0054]

[0055] In the formula, c represents the link cost, e represents the link, α represents the sharing penalty coefficient (α is greater than 0), and s represents the number of shares for link e. The link cost consists of two parts: a constant term 1 and a sharing penalty term. The constant term 1 ensures that each link traversal incurs a base cost, thus favoring the path with fewer links (shorter) when the number of shares is the same. The sharing penalty term is the product of the sharing penalty coefficient and the number of shares, resulting in higher costs for links occupied by more other multicast routing trees. The sharing penalty coefficient adjusts the impact of the number of shares on the link cost. A larger value of the sharing penalty coefficient indicates a greater tendency to avoid highly shared links during reconstruction, even if it means taking a longer detour; a smaller value of the sharing penalty coefficient indicates a greater tendency to choose a shorter path during reconstruction.

[0056] The management core employs a point-by-point access method to rebuild and reconstruct objects. See also... Figure 7The right side of the image shows that the reconstructed object bypasses highly shared links. The specific execution process of the point-to-point access method is as follows: The source node of the reconstructed object is used as the initial form of the current tree, which initially contains only the source node. For each destination node yet to be accessed, the weighted shortest path from that destination node to the current tree is calculated. The path weight of the weighted shortest path is the sum of the link costs of all links along the path, and the search range of the weighted shortest path is limited to the links covered by the bounding box of the reconstructed object. Among all destination nodes yet to be accessed, the destination node with the smallest path weight of the weighted shortest path is selected. All links along the weighted shortest path corresponding to that destination node are added to the current tree, and the destination node is marked as accessed. This access process is repeated until all destination nodes are accessed. The point-to-point access method accesses the destination node with the smallest current cost each time, allowing the already accessed portion to be reused by subsequent destination nodes, thereby avoiding highly shared links while suppressing the growth of the total path length. By limiting the search scope of the weighted shortest path to the links covered by the bounding box of the reconstructed object, all tree edges of the reconstructed multicast routing tree remain within the links covered by its own bounding box. This maintains the property that all tree edges of the multicast routing tree are within its own bounding box before and after reconstruction, providing a consistent basis for determining link independence by bounding box during the runtime phase.

[0057] After reconstructing the object, the management core updates the connection edges of the corresponding vertices in the conflict graph with the reconstructed multicast routing tree. Specifically, based on the link occupancy relationship between the reconstructed multicast routing tree and other multicast routing trees, it re-determines whether the vertex is adjacent to other vertices, and then re-colors the updated conflict graph. The management core repeats the above tree reconstruction iteration until the number of chromatic elements is less than or equal to the preset frame length limit. If the number of chromatic elements has not decreased to within the preset frame length limit when the number of iterations reaches the preset iteration limit, the coloring with the smallest number of chromatic elements from all previous coloring iterations is selected, and the coloring result corresponding to that coloring, along with all multicast routing trees at the time of that coloring, is adopted. The reason for selecting the coloring with the smallest number of chromatic elements from all previous iterations and adopting it along with all multicast routing trees at that time is that the multicast routing tree is continuously reconstructed between iterations, and the coloring result corresponds to the current multicast routing tree shape. Only by matching the coloring with the smallest number of chromatic elements with its corresponding multicast routing tree shape can the adopted coloring be guaranteed to be consistent with the actual link occupancy relationship.

[0058] The management core generates a timeslot table based on the final coloring result and all multicast routing trees. The timeslot table records the links occupied by each multicast routing tree and the timeslot it occupies within a time-division multiplexing frame. The management core then distributes the timeslot table to each router and network interface. Based on the timeslot table, each router and network interface forwards data within the corresponding timeslot and according to the corresponding multicast routing tree in each time-division multiplexing frame, thereby completing the task mapping and transmission scheduling during the application deployment phase.

[0059] The following describes the runtime incremental remapping process performed during the accelerator's operation phase. Steps 1 to 3 of the application deployment phase completed task mapping and transmission scheduling based on the known task set and multicast communication relationship set at the time of deployment. During the actual operation of the accelerator, the actual load on each processing core changes with the application's execution progress, and some processing cores may experience transmission congestion due to the actual amount of data generated by the tasks they are handling exceeding expectations. To quickly adjust local mappings without rearranging the entire transmission sequence, the management core performs a runtime incremental remapping process, migrating tasks on congested processing cores to nearby processing cores with lighter loads. The runtime incremental remapping process, as a runtime supplement to the deployment phase scheduling scheme, is also performed by the management core.

[0060] During operation, each network interface calculates the backlog of its corresponding processing core's send queue according to a statistical period and reports the backlog to the management core. The backlog reflects the degree of data accumulation awaiting transmission by the corresponding processing core; a larger backlog indicates less timely transmission and more severe congestion. When the backlog of any processing core exceeds the backlog threshold for a preset number of consecutive statistical periods, the management core designates that core as an overloaded core. The requirement that the backlog only be identified as overloaded when it consistently exceeds the backlog threshold for multiple consecutive statistical periods, rather than being identified immediately upon exceeding it in a single period, filters out instantaneous backlogs caused by short-term data bursts, avoids frequent task migrations triggered by occasional short-term fluctuations, and ensures that task migrations only occur when there is genuine and sustained congestion.

[0061] After identifying the overloaded core, the management core designates all tasks carried by the overloaded core as tasks to be migrated. Processing cores with a Manhattan distance greater than 0 and less than or equal to a preset distance threshold from the overloaded core are designated as candidate processing cores. The Manhattan distance is the sum of the absolute differences between the x-coordinates and y-coordinates of two nodes on the grid. A Manhattan distance greater than 0 excludes the overloaded core itself, while a Manhattan distance less than or equal to the preset distance threshold limits candidate processing cores to the vicinity of the overloaded core. Limiting candidate processing cores to the vicinity ensures that the migrated tasks remain near their original communication counterparts, preventing tasks from being migrated to excessively distant processing cores and significantly increasing communication distance.

[0062] The management core constructs a cost matrix where rows correspond to tasks to be migrated and columns correspond to candidate processing cores. Each element of the cost matrix represents the cost of assigning the corresponding task to the corresponding candidate processing core. When the number of tasks to be migrated is not equal to the number of candidate processing cores, the cost matrix is ​​padded to a square matrix using a virtual element whose value is equal to the largest element in the cost matrix. The reason for using the largest element for padding is that when solving for the minimum total cost assignment, the largest element is least likely to be selected in the optimal assignment, thus minimizing the impact of the virtual element introduced for padding on the actual assignment result.

[0063] The cost matrix elements for assigning tasks to candidate processing cores are calculated using the following formula:

[0064]

[0065] In the formula, C represents the cost matrix element for assigning the task i to be migrated to the candidate processing core j, i represents the task to be migrated, j represents the candidate processing core, f represents the multicast communication relationship in which the task i participates, traversing all multicast communication relationships in which the task i participates, w represents the amount of data transmitted in multicast communication relationship f, L represents the semi-perimeter of the bounding box of multicast communication relationship f after migrating the task i to be migrated to the candidate processing core j, β represents the time slot penalty coefficient, β is greater than 0, and Δ represents the estimated value of the time slot increment. After migrating the task i to be migrated to the candidate processing core j, the bounding box determined based on the coordinates of all endpoints of multicast communication relationship f is denoted as the post-migration bounding box. The semi-perimeter of the post-migration bounding box is the difference between the maximum and minimum values ​​of the horizontal coordinate of the post-migration bounding box plus the difference between the maximum and minimum values ​​of the vertical coordinate. The cost matrix element consists of the sum of the communication cost term and the time slot penalty term. The communication cost term is the sum of the products of the transmitted data volume of each multicast communication relationship in which the task i to be migrated participates and the half-perimeter of the corresponding bounding box after migration. The half-perimeter of the bounding box after migration describes the expansion range of the endpoints of the multicast communication relationship on the grid after migration. The half-perimeter is weighted by the transmitted data volume to ensure that the expansion range of multicast communication relationships with large transmitted data volumes accounts for a larger proportion of the cost, thereby guiding the migration to minimize the expansion range of large-volume multicasts. The slot penalty term is the product of the slot penalty coefficient and the estimated slot increment, used to account for the increase in the number of transmission slots that may be caused by migration in the cost. The method for determining the estimated slot increment is explained below.

[0066] The time slot increment estimate is used to estimate the number of additional time slots that may be needed to rearrange the transmission time slots for the multicast communication relationships involved in the migration after migrating the task to be migrated to the candidate processing core. To quickly estimate this increase, this invention utilizes the property that all tree edges of a multicast routing tree are within its own bounding box, using whether the bounding boxes are mutually separated as the basis for determining whether two multicast routing trees occupy mutually independent links. The case where the intersection of the link sets covered by two bounding boxes is an empty set is denoted as two bounding boxes being mutually separated. Since all tree edges of each multicast routing tree are within the links covered by its own bounding box, the two multicast routing trees corresponding to two mutually separated bounding boxes must occupy mutually independent links, and therefore can be arranged for transmission in the same time slot. In other words, the mutual separation of bounding boxes constitutes sufficient evidence that two multicast routing trees occupy mutually independent links. Accordingly, to determine whether a migrated multicast routing tree can reuse an existing time slot, it is only necessary to determine whether the bounding box after migration is mutually separated from the bounding boxes of the existing multicast routing trees in that time slot, without having to compare the specific occupied links one by one.

[0067] Whether two bounding boxes are separated can be quickly determined by coordinate comparison. The intersection of the horizontal coordinate intervals of the two bounding boxes is denoted as the horizontal overlapping interval, and the intersection of the vertical coordinate intervals is denoted as the vertical overlapping interval. When either the horizontal or vertical overlapping interval is empty, the number of nodes covered by the two bounding boxes is 0; when both overlapping intervals degenerate into a single coordinate value, the number of nodes covered by the two bounding boxes is 1. For a link to be covered by two bounding boxes, both ends of the link must be covered by nodes from both bounding boxes, meaning the number of nodes covered must be greater than or equal to 2. Therefore, when either overlapping interval is empty or both overlapping intervals degenerate into a single coordinate value, the number of nodes covered by the two bounding boxes is less than 2, and there is no link simultaneously belonging to both bounding boxes; thus, the two bounding boxes are considered separated. In other cases, the two bounding boxes are considered to overlap. The method of comparing the intersection of coordinate intervals to determine whether the bounding boxes are separated only requires one interval intersection calculation for the x-coordinate and y-coordinate. The number of comparisons required for the determination process is independent of the size of the bounding box, making it very fast.

[0068] Based on the bounding box separation criterion described above, the time slot increment estimate is determined as follows: For each multicast communication relationship in which the task to be migrated i participates, the reference routing tree under each color number is first determined: For each color number, the multicast routing tree that is different from the multicast routing tree corresponding to each multicast communication relationship in which the task to be migrated i participates among all multicast routing trees holding that color number is recorded as the reference routing tree under that color number. That is, the multicast routing tree corresponding to the multicast communication relationship in which the task to be migrated itself participates is excluded during the verification. If all endpoints of a multicast communication relationship are located in the same node after migration, the data of the multicast communication relationship is transmitted within the node without occupying the link, and its time slot increment is recorded as 0. For multicast communication relationships with endpoints distributed across two or more nodes after migration, they are examined one by one in ascending order of color number: When it is found that the bounding box after migration under a certain color number is separated from the bounding boxes of all reference routing trees under that color number, it indicates that the migrated multicast routing tree can reuse the time slot corresponding to that color number without adding a new time slot. Therefore, the time slot increment of this multicast communication relationship is recorded as 0, and the examination of this multicast communication relationship ends. When all color numbers have been examined and there is a reference routing tree that overlaps with the bounding box under each color number, it indicates that the migrated multicast routing tree may occupy the same link as the existing multicast routing tree in each existing time slot, making it difficult to reuse the existing time slot. Therefore, the time slot increment of this multicast communication relationship is recorded as 1. The sum of the time slot increments of all multicast communication relationships in which the task to be migrated i participates is used as the estimated value of the time slot increment. Since the separation of bounding boxes is only a sufficient basis for two multicast routing trees to occupy independent links, the time slot increment of a multicast communication relationship obtained according to the bounding box separation criterion is greater than or equal to the time slot increment obtained by performing a precise comparison of tree edge sets on the same reference routing tree. That is, the bounding box separation criterion will not underestimate the estimate of the new time slot, thus tending to avoid migrations that may cause an increase in time slots during the assignment phase.

[0069] The management core employs the Hungarian algorithm to solve for the minimum total cost one-to-one assignment of the cost matrix. The specific execution process of the Hungarian algorithm is as follows: First, subtract the minimum value of each row from all elements in the cost matrix. Then, subtract the minimum value of each column from all elements in the processed cost matrix. Next, cover all zero elements in the cost matrix with the fewest possible horizontal and vertical lines. When the number of covering lines equals the order of the cost matrix, one-to-one assignment is obtained by taking one zero element from each row and column. When the number of covering lines is less than the order of the cost matrix, find the minimum value among the elements not covered by the covering lines, subtract this minimum value from all uncovered elements, and add this minimum value to the elements at the intersection of the horizontal and vertical lines. Repeat the above covering and adjustment process until the number of covering lines equals the order of the cost matrix, thus obtaining the one-to-one assignment. The one-to-one assignment obtained by the Hungarian algorithm minimizes the sum of costs corresponding to the assigned elements, thereby minimizing the total migration cost while assigning each migration task to a different candidate processing core.

[0070] After receiving the assignment, the management core migrates each task to be migrated from the assignment results to its corresponding candidate processing core. For tasks assigned to virtual elements, since the virtual element does not correspond to an actual candidate processing core, the task remains in the overloaded core and is not migrated. The management core then updates and recolors the multicast routing trees involved in the migration. The management core records all multicast communication relationships involving the migrated tasks as routing trees to be rebuilt, removes all routing trees to be rebuilt from their corresponding color numbers, and releases all entries in the time slot table corresponding to the links occupied by the routing trees to be rebuilt. All remaining multicast routing trees after removing the routing trees to be rebuilt, along with the rebuilt multicast routing trees that have already been color-assigned, are collectively called the registered routing trees. The reason for removing the routing trees to be rebuilt before assigning colors to the rebuilt multicast routing trees is that the original occupancy of the routing trees to be rebuilt is that their rebuilt form will soon replace it; if they are not removed first, the rebuilt multicast routing trees will create false conflicts when compared with their original form.

[0071] The management core performs reconstruction and color assignment on each multicast communication relationship involved in the migration task, in descending order of transmitted data volume. Multicast communication relationships with larger transmitted data volumes are prioritized to receive smaller color numbers, i.e., earlier transmission time slots. For a multicast communication relationship, if all endpoints are located on the same node after migration, the corresponding data is transmitted within that node, without needing to rebuild the multicast routing tree or occupying time slots. If the endpoints are distributed across more than two nodes after migration, the multicast routing tree is reconstructed based on the migrated endpoints according to the construction process in step 2, resulting in a reconstructed multicast routing tree, and color numbers are assigned to each node.

[0072] When assigning color numbers to the reconstructed multicast routing tree, the management core checks each existing color number one by one, prioritizing the color number held by the multicast communication relationship before the migration, and then checking the remaining color numbers in ascending order. Prioritizing the color numbers held before the migration ensures that, where feasible, the reconstructed multicast routing tree can retain its pre-migration color number, thus maintaining the original time slot arrangement as much as possible and minimizing disruption to existing scheduling. The verification of a color number is divided into two levels. The first level of verification determines whether the bounding box of the reconstructed multicast routing tree is separated from the bounding boxes of all registered routing trees holding that color number through coordinate comparison. If all are separated, the color number can be reused. The reason for using the separation of bounding boxes as the criterion in the first level of verification is that the separation of bounding boxes is sufficient evidence of the independence of links; once all are separated, it can be determined that they do not occupy the same link, and there is no need for further comparison of specific links. When a registered route tree overlaps with the bounding box of the reconstructed multicast route tree in the Level 1 check, since the overlapping bounding boxes only indicate that the links covered by the two bounding boxes may intersect, and do not necessarily mean that they actually occupy the same links, the management core performs a Level 2 check on the color number: The tree edge set of the reconstructed multicast route tree is intersected with the tree edge set of each overlapping registered route tree. When all intersections are empty sets, it indicates that the reconstructed multicast route tree and these registered route trees do not actually occupy the same links, and the color number can be used. When any intersection contains at least one link, the color number is determined to be conflicting. The Level 2 check first uses bounding box separation for quick judgment, and then uses tree edge set intersection for precise judgment when bounding boxes overlap. This utilizes the speed of the bounding box criterion and avoids misjudgment conflicts due to bounding box overlap through precise comparison, thus reducing the workload of comparison while ensuring accurate judgment.

[0073] The management core determines the first usable color number found as the color number of the reconstructed multicast routing tree and includes it in the registered routing tree. Then, it ends the color assignment for that multicast communication relationship. When all existing color numbers conflict, the management core adds a new color number, increments the number of time slots in the time-division multiplexed frame by 1, and determines the new color number as the color number of the reconstructed multicast routing tree, also including it in the registered routing tree. Since the registered routing tree includes reconstructed multicast routing trees that have already undergone color assignment, when multiple multicast communication relationships migrated together need to be rebuilt, the reconstructed multicast routing tree that completed color assignment first will participate in the verification of subsequent reconstructed multicast routing trees as a registered routing tree. Therefore, link occupancy conflicts between the reconstructed multicast routing trees corresponding to multiple multicast communication relationships migrated together are also fully considered during the verification process.

[0074] After the reconstruction and color assignment are completed, when the reconstructed multicast routing tree uses the existing color codes, the management core distributes the updated timeslot table to the routers and network interfaces affected by the migration. When the reconstructed multicast routing tree uses the newly added color codes, because the number of timeslots in the time-division multiplexing frame has changed, the management core distributes the updated number of timeslots in the time-division multiplexing frame to all routers and all network interfaces, and distributes the updated timeslot table to the routers and network interfaces affected by the migration. The switching of the timeslot table takes effect at the boundary of the time-division multiplexing frame, that is, at the moment when the current time-division multiplexing frame ends and the next time-division multiplexing frame begins, each router and each network interface switches to the updated timeslot table, thereby ensuring that the ongoing transmission is not interrupted, and the transmission before and after the update is smoothly connected at the frame boundary. Thus, the runtime incremental remapping process alleviates the transmission congestion of the processing core by adjusting only the local mapping and local timeslot arrangement, without rearranging the transmission timing of all multicast communication relationships.

[0075] To further illustrate the implementation process and effects of this invention, a numerical example is given below. Assume a two-dimensional mesh on-chip network with 8 rows and 8 columns, totaling 64 nodes. The application to be deployed includes 60 tasks and several multicast communication relationships. The preset upper limit for the number of endpoints is 9, the preset upper limit for frame length is 16, the preset distance threshold is 2, and the preset number of consecutive statistical periods is 3. In step 1, an initial mapping is obtained through hypergraph partitioning corresponding to the 3-level recursive bisection of the mesh. In step 2, for multicast communication relationships with no more than 9 endpoints, a rectangular Steiner minimum tree is constructed using a lookup table method; for those with more than 9 endpoints, a multicast routing tree is constructed by divide and conquer using common endpoints. In step 3, a conflict graph is constructed using the multicast routing tree as vertices and colored using a saturation-first strategy.

[0076] See Figure 8 , Figure 8 Figure (a) shows a comparison of the number of chromatic elements in this method and the control method as the number of multicast communication relationships changes. The horizontal axis represents the number of multicast communication relationships, in units of rows, and the vertical axis represents the number of chromatic elements, in units of time slots. The control method does not constrain tree edges to be within the bounding box and does not perform tree reconstruction iteration. As can be seen from the figure, as the number of multicast communication relationships increases from 20 to 160, the number of chromatic elements in the control method rapidly increases from 6 time slots to 53 time slots, while the number of chromatic elements in this method only increases from 5 time slots to 22 time slots. The reason for this is that this method constrains the tree edges of the multicast routing tree to be within the bounding box, so that the spatial range of each multicast routing tree is limited by the endpoint distribution and does not expand arbitrarily, reducing unnecessary link occupation conflicts; and when the number of chromatic elements exceeds the preset frame length limit, tree reconstruction iteration is performed to actively avoid high-shared links, further compressing the number of chromatic elements.

[0077] Taking a scenario with a large number of multicast communication relationships as an example, the initial coloring of the conflict graph before the tree reconstruction iteration results in 26 time slots, exceeding the preset frame length limit of 16. Based on this, the management core executes the tree reconstruction iteration. In each iteration, the multicast routing tree with the highest sharing degree is selected and rebuilt point-by-point within its bounding box at link cost. After reconstruction, the conflict graph is updated and recolored. After several iterations, multicast routing trees occupying high-sharing links are successively rebuilt on links with fewer conflicts, and the number of colors gradually decreases to within 16 time slots, meeting the preset frame length limit. This process demonstrates that the tree reconstruction iteration can compress the required number of time slots by adjusting the paths of a few multicast routing trees without changing the task mapping.

[0078] Figure 8 Figure (b) shows a comparison of the average transmission delay of the proposed method and the control method as a function of the injection rate. The horizontal axis represents the injection rate, in units of data packets per node per cycle, and the vertical axis represents the average transmission delay, in units of cycles. As can be seen from the figure, the average transmission delays of the two methods are similar at low injection rates. However, as the injection rate increases, the average transmission delay of the control method rises sharply after the injection rate exceeds approximately 0.30, leading to congestion saturation earlier. In contrast, the proposed method, due to the multicast routing trees occupying independent links within the same time slot and the absence of transmission contention, shows a significantly smoother increase in average transmission delay, with the saturation point shifting later. This indicates that the proposed method can maintain low communication latency and a high tolerable injection rate when carrying dense multicast communication.

[0079] The above embodiment is one implementation of the present invention. Those skilled in the art can also adopt several optional implementations under the concept of the present invention.

[0080] In one optional implementation, task migration for an overloaded core does not involve migrating all tasks carried by the overloaded core at once. Instead, only the tasks carrying the largest amount of data transmitted are identified as the tasks to be migrated. When congestion on the overloaded core is mainly caused by a few tasks carrying large amounts of multicast data, migrating only these tasks can effectively alleviate congestion, while reducing the number of tasks being migrated and minimizing the disturbances caused by the migration.

[0081] In one optional implementation, the cost matrix elements, in addition to the communication cost term and the time slot penalty term, also include a computational load term for the candidate processing core. This computational load term increases as the current computational load on the candidate processing core increases. Including the computational load term during assignment avoids migrating tasks to candidate processing cores with already high computational loads, preventing computational overload on candidate processing cores while alleviating transmission congestion.

[0082] In one optional implementation, when coloring the conflict graph, multicast routing trees with transmission data volumes greater than a preset data volume threshold are assigned two or more color numbers, while multicast routing trees with transmission data volumes less than or equal to the preset data volume threshold are assigned one color number. The intersection of the two sets of color numbers held by the two multicast routing trees corresponding to two vertices connected by an edge in the conflict graph is an empty set. Each multicast routing tree occupies a link for transmission in the time slot corresponding to each of its color numbers within each time-division multiplexing frame. Assigning two or more color numbers to multicast routing trees with large transmission data volumes allows them to obtain two or more transmission time slots within each time-division multiplexing frame, thereby providing transmission opportunities commensurate with the data volume of large-volume multicasts and alleviating the situation where large-volume multicasts are not transmitted in a timely manner due to only one time slot per frame.

[0083] In one optional implementation, the duration of each time slot in the time-division multiplexing frame is set to be greater than or equal to the maximum value among the transmission completion times corresponding to each multicast routing tree. The transmission completion time corresponding to a multicast routing tree is the time required for one data packet to travel from the source node to all destination nodes along that multicast routing tree. Setting the time slot duration to the longest transmission completion time ensures that any multicast routing tree can complete one transmission from the source node to all destination nodes within its corresponding time slot, thus matching the time slot-based scheduling with the actual transmission time.

[0084] In one optional implementation, the management core periodically re-executes step 3 during the runtime phase to reconstruct and color the conflict graph for all multicast routing trees. Since runtime incremental remapping adds new color numbers when it becomes difficult to reuse existing color numbers, the number of colors may gradually increase after multiple migrations. Periodically re-executing step 3 can compress the number of colors back to a smaller level, keeping the length of time-division multiplexed frames compact.

[0085] The specific values ​​of the aforementioned preset parameters, as well as the number of rows and columns of the grid, can be adjusted according to the scale of the accelerator and the communication characteristics of the application. The above-described embodiments and their technical features can be combined with each other without conflict. The above descriptions are merely specific embodiments of the present invention; any changes or substitutions made by those skilled in the art within the scope of the technology disclosed in this invention should be included within the protection scope of this invention.

[0086] This invention is not limited to the specific embodiments described above. The invention extends to any new feature or combination disclosed in this specification, as well as any new method or process step or combination disclosed herein.

Claims

1. A task mapping and data transmission scheduling method for multi-core accelerators based on on-chip networks, applied to a multi-core accelerator containing a two-dimensional mesh on-chip network, wherein the two-dimensional mesh on-chip network contains multiple nodes arranged in multiple rows and columns, each node containing one processing core, one router, and one network interface, the routers of adjacent nodes are connected through bidirectional links, and one of the processing cores also serves as the management core; characterized in that, The method includes steps 1 to 3, which are executed by the management core during the application deployment phase: Step 1: Obtain the task set and multicast communication relationship set of the application to be deployed. Each task has a computational amount, and each multicast communication relationship includes one source task, at least one destination task, and the amount of data transmitted. Construct a task hypergraph with each task in the task set as a vertex, the task group consisting of the source task and all destination tasks of each multicast communication relationship as a hyperedge, and the amount of data transmitted as the hyperedge weight. Perform hypergraph partitioning on the task hypergraph corresponding to the recursive bisection of the two-dimensional mesh on-chip network to obtain the initial mapping from task to processing core; Step 2: Based on the initial mapping, the node where the source task of each multicast communication relationship is located is recorded as the source node, and the node where the destination task is located is recorded as the destination node. The source node and all destination nodes are collectively referred to as the endpoint. The rectangular region enclosed by the minimum and maximum x-coordinates, minimum and maximum y-coordinates of all endpoints of each multicast communication relationship is denoted as the bounding box. All nodes whose x-coordinates are between the minimum and maximum x-coordinates and whose y-coordinates are between the minimum and maximum y-coordinates are denoted as nodes covered by the bounding box. Nodes on all four boundary coordinates are also included in the nodes covered by the bounding box. Links whose two ends are both covered by the bounding box are denoted as links covered by the bounding box. For each multicast communication relationship with endpoints distributed across more than two nodes, a multicast routing tree connecting all endpoints is constructed. Each edge of the multicast routing tree corresponds to one link in the two-dimensional mesh on-chip network. All edges of each multicast routing tree belong to the links covered by its own bounding box. Data of each multicast communication relationship is transmitted from the source node to all destination nodes along the corresponding multicast routing tree. Step 3: Using each multicast routing tree as a vertex in the conflict graph, when any two multicast routing trees occupy at least one of the same links, connect the corresponding two vertices in the conflict graph with an edge; color the conflict graph, assigning a color number to each multicast routing tree. The color numbers of the multicast routing trees corresponding to two vertices connected by an edge in the conflict graph are different. Record the total number of color numbers used as the color number; when the color number is greater than the preset frame length limit, perform tree reconstruction iteration: for each multicast routing tree, sum the number of multicast routing trees that are different from itself on each link it occupies, obtain the sharing degree, and select the multicast routing tree with the largest sharing degree as the reconstruction object; reconstruct the reconstruction object. All tree edges of the reconstructed multicast routing tree still belong to the links covered by its own bounding box. Update the connecting edges of the corresponding vertices in the conflict graph with the reconstructed multicast routing tree and recolor; repeat the tree reconstruction iteration until the color number is less than or equal to the preset frame length limit or the number of iterations reaches the preset iteration limit; A time-division multiplexing frame contains a number of time slots equal to the number of colors. Each color number corresponds one-to-one with a time slot. Each multicast routing tree occupies a link for transmission in the time slot corresponding to its own color number within each time-division multiplexing frame. Each multicast routing tree transmitted in the same time slot occupies an independent link with each other. A time slot table is generated based on the coloring result and all multicast routing trees. The management core then distributes the time slot table to each router and each network interface.

2. The method according to claim 1, characterized in that, In step 1, each round of hypergraph partitioning divides the current vertex set into two vertex subsets and simultaneously divides the current subregion into two rectangular subregions. When the number of rows in the current subregion is greater than or equal to the number of columns, it is divided into two rectangular subregions with the smallest difference in the number of nodes (upper and lower) along the row direction. When the number of columns in the current subregion is greater than the number of rows, it is divided into two rectangular subregions with the smallest difference in the number of nodes (left and right) along the column direction. The two vertex subsets correspond one-to-one with the two rectangular subregions. The goal of each round of partitioning is to minimize the sum of the weights of the hyperedges that cross the two vertex subsets and satisfy the balance constraint. The balance constraint is that the absolute value of the difference between the sum of the computational cost of all tasks in each vertex subset and the corresponding target computational cost is less than or equal to the preset balance tolerance. The corresponding target computational cost is equal to the sum of the computational cost of all tasks in the current vertex set multiplied by the ratio of the number of nodes in the corresponding rectangular subregion to the total number of nodes in the two rectangular subregions. For each vertex subset and its corresponding rectangular subregion, perform binary search recursively until each rectangular subregion contains only one node, and all tasks within each vertex subset are mapped to the processing core of the corresponding node.

3. The method according to claim 2, characterized in that, In step 1, each round of binary search is implemented using gain iteration: the reduction in the sum of the weights of the super-edges spanning two vertex subsets caused by moving a vertex from its own subset to another vertex subset is recorded as the movement gain. Each time, the vertex that satisfies the balance constraint and has the largest movement gain is moved and the moved vertex is locked. After all vertices are locked, the process reverts to the intermediate partition state where the sum of the weights of the super-edges spanning two vertex subsets is the smallest. The gain iteration is repeated until the sum of the weights of the super-edges spanning two vertex subsets converges.

4. The method according to claim 1, characterized in that, In step 2, when the number of endpoints is less than or equal to the preset upper limit of the number of endpoints, a rectangular Steiner minimum tree connecting all endpoints is constructed as a multicast routing tree using a lookup table method: all endpoints are sorted by their horizontal coordinates from smallest to largest, and if the horizontal coordinates are the same, they are sorted by their vertical coordinates from smallest to largest. The ranking of the vertical coordinates of each endpoint after sorting is recorded to obtain the position sequence. The Steiner tree topology lookup table, which is constructed offline, is retrieved using the number of endpoints and the position sequence as indexes. Each index entry of the Steiner tree topology lookup table stores all the potential optimal Steiner tree topologies for the corresponding position sequence. Each Steiner tree topology retrieved is restored to a set of horizontal and vertical line segments on the grid based on the actual coordinates of all endpoints, and the bus length is calculated. The tree restored from the Steiner tree topology with the smallest bus length is selected as the construction result.

5. The method according to claim 4, characterized in that, In step 2, when the number of endpoints exceeds the preset upper limit, all endpoints are sorted by their horizontal coordinates from smallest to largest. If the horizontal coordinates are the same, they are sorted by their vertical coordinates from smallest to largest. The endpoint in the middle position after sorting is selected as the common endpoint. When the number of endpoints is even, the endpoint in the middle two positions is selected as the common endpoint. The common endpoint and all endpoints in the sorted sequence before the common endpoint are divided into the first endpoint subset. The common endpoint and all endpoints in the sorted sequence after the common endpoint are divided into the second endpoint subset. Trees are constructed for the two endpoint subsets respectively. When the number of endpoints in the endpoint subset is less than or equal to the preset upper limit, a lookup table method is used for construction. When the number of endpoints in the endpoint subset is greater than the preset upper limit, the endpoint subset is recursively partitioned and constructed. The two trees are connected at the common endpoint to form a single tree.

6. The method according to claim 1, characterized in that, In step 2, with the source node as the root, the direction of each tree edge is determined as the direction away from the source node. For each node in the multicast routing tree, the tree edge extending from the node along the direction away from the source node is the downstream tree edge of the node. The network interface corresponding to the source node submits the data packet to the router corresponding to the source node. The router corresponding to the source node sends the data packet along all the downstream tree edges of the source node. Nodes with two or more downstream tree edges are recorded as branch nodes. The router corresponding to the branch node is configured with a replication forwarding table entry. When the data packet arrives at the branch node, the router corresponding to the branch node replicates it according to the replication forwarding table entry and forwards it along all the downstream tree edges of the branch node. The router corresponding to the node with one downstream tree edge forwards the arriving data packet along the downstream tree edge. The router corresponding to the destination node delivers the arriving data packets to the processing core of the destination node through the network interface corresponding to the destination node. When the destination node has downstream tree edges, it forwards the data packets along the downstream tree edges.

7. The method according to claim 1, characterized in that, In step 3, two vertices connected by an edge in the conflict graph are considered adjacent vertices. The coloring of the conflict graph adopts a saturation priority strategy: the number of color types used by the adjacent vertices of a vertex is recorded as the saturation. Each time, the vertex with the highest saturation is selected. If the saturation is the same, the vertex with the larger amount of transmitted data is selected. The selected vertex is assigned the smallest color number that is different from the colors used by all its adjacent vertices, until all vertices are colored.

8. The method according to claim 1, characterized in that, In step 3, for each link, the number of multicast routing trees that are different from the reconstructed object in the multicast routing trees that the link passes through is recorded as the shared quantity. The link cost is equal to the sum of the product of the shared penalty coefficient and the shared quantity and 1. The shared penalty coefficient is greater than 0. The reconstruction of the reconstructed object adopts the point-to-point access method: with the source node as the initial form of the current tree, the weighted shortest path from the destination node to the current tree is calculated for each destination node that is yet to be accessed. The path weight is the sum of the link costs of the links that pass through. The search range of the weighted shortest path is limited to the links covered by the bounding box of the reconstructed object. The destination node with the smallest path weight is selected, and all links that the corresponding weighted shortest path passes through are merged into the current tree. The selected destination node is marked as accessed. The access process is repeated until all destination nodes are accessed. When the tree reconstruction iteration ends when the number of iterations reaches the preset iteration limit, the coloring with the smallest number of colors in all previous colorings is selected, and the coloring result corresponding to the selected coloring and all multicast routing trees at the time of the selected coloring are used. The time slot table is generated based on the final coloring result and all multicast routing trees.

9. The method according to claim 1, characterized in that, In step 3, the duration of each time slot in the time-division multiplexing frame is greater than or equal to the maximum value of the transmission completion duration corresponding to each multicast routing tree. The transmission completion duration corresponding to one multicast routing tree is the time required for one data packet to travel from the source node to all destination nodes along the multicast routing tree.

10. The method according to claim 1, characterized in that, In step 3, when coloring the conflict graph, multicast routing trees with a transmission data volume greater than a preset data volume threshold are assigned two or more color numbers, and multicast routing trees with a transmission data volume less than or equal to the preset data volume threshold are assigned one color number. The intersection of the two sets of color numbers held by the two multicast routing trees corresponding to the two vertices connected by an edge in the conflict graph is an empty set. Each multicast routing tree occupies the link for transmission in the time slot corresponding to each color number it holds in each time-division multiplexing frame.

Images