A sub-core level task collaborative scheduling method and scheduling management unit for heterogeneous data stream architectures

Abstract

This invention belongs to the field of computer dataflow architecture design technology, and relates to a sub-core-level task collaborative scheduling method and scheduling management unit for heterogeneous dataflow architectures. The method includes: splitting computational tasks into multiple operators, and further refining each operator into multiple sub-cores to construct sub-core waiting queues; clustering operators into different collaborative execution units based on data dependencies and sharing patterns, and constructing sub-core running queues; dynamically monitoring the availability status of the processing unit array during runtime, and dynamically allocating non-conflicting processing unit resources to multiple sub-cores using a resource masking mechanism; updating the status of a sub-core after its execution and releasing the corresponding processing unit resources; iterating the above process until all queues are empty, at which point scheduling ends. This invention, through a sub-core-level task collaborative scheduling mechanism combined with data reuse technology, simultaneously deploys multiple sub-cores to the processing unit array for execution, achieving efficient resource utilization and computational parallelization, and significantly improving the overall system performance.

Description

Technical Field

[0001] This invention belongs to the field of computer dataflow architecture design technology, and more specifically, relates to a sub-core level task collaborative scheduling method and scheduling management unit for heterogeneous dataflow architecture. Background Technology

[0002] The current computing technology is gradually shifting from general-purpose computing to domain-specific computing, and the integration of big data, graph computing and artificial intelligence has become the main development trend. This multi-domain integrated computing exhibits complex intertwined characteristics of data intensity, control intensity and memory access intensity, posing a huge challenge to computer systems with traditional single data flow or control flow architectures. The core problem is that the efficiency of multi-task mixed execution is low under various computing modes, specifically: (1) the traditional multi-task scheduling mechanism lacks dynamic flexibility and cannot effectively adapt to the diverse computing task resource requirements; (2) the operator execution order is relatively simple and lacks intelligent reordering and optimization capabilities based on data flow graphs; (3) under the static scheduling strategy, the development of spatiotemporal parallelism between operators is insufficient and the utilization rate of hardware resources is low. With the rapid development of artificial intelligence technologies such as neural networks and the rapid expansion of the scale of modern scientific application problems, the demand for computing power has shown explosive growth. Under the dual constraints of the "power wall" and the "memory wall", the traditional control flow architecture is difficult to effectively support such high-performance computing needs.

[0003] Compared to traditional control-flow architectures (such as the von Neumann architecture), dataflow architectures offer significant advantages. Their program execution does not depend on a program counter but rather operates through a data-driven model. Computational tasks are abstracted as dataflow graphs in the form of directed acyclic graphs (DAGs), where nodes represent computational operations and edges represent dependencies between data. Once all input data for a node is ready, the computational operation is triggered, and the result is passed along the dataflow graph to subsequent nodes, achieving efficient instruction-level and data-level parallelism. Representative dataflow models, such as the Codelet model and the EARTH dataflow computer, significantly improve the parallelism and resource utilization efficiency of the architecture by breaking down computational tasks into multiple smaller tasks and organizing them into a dataflow graph. Existing technologies have proposed a novel dataflow heterogeneous processor architecture, DFU. This architecture consists of a traditional CPU and a heterogeneous many-core processor DFU, which can improve task parallelism and reduce memory access latency. However, current DFU architectures lack an effective runtime system: in multi-tasking scenarios, each task is typically broken down into multiple different operators. While existing methods can support the parallel execution of multiple operators, they operate on an operator-by-operator basis, resulting in a large scheduling granularity and a relatively fixed scheduling pattern. This lack of flexibility makes it difficult to dynamically adjust the scheduling based on operator characteristics and system state. Furthermore, the lack of ability to dynamically adjust the operator scheduling order and resource allocation leads to high memory access overhead and limited execution efficiency during multi-task execution. Therefore, designing a high-efficiency, low-energy-consumption multi-task collaborative scheduling method and system on a novel heterogeneous dataflow (DFU) architecture, supporting collaborative scheduling of multiple operators to achieve dynamic operator selection, fully exploit hardware potential, and improve overall system performance, has become an urgent technical challenge. Summary of the Invention

[0004] To address the aforementioned deficiencies or improvement needs of existing technologies, this invention provides a sub-core level task collaborative scheduling method and scheduling management unit for heterogeneous data flow architectures. Its purpose is to solve the problems of limited parallel scheduling capabilities in current heterogeneous data flow architectures (DFU), large scheduling granularity due to the system being based on operators, and relatively fixed scheduling modes lacking flexibility and making it difficult to dynamically adjust according to operator characteristics and system state, resulting in low resource utilization and limited system performance improvement in multi-task parallel scenarios.

[0005] To achieve the above objectives, this invention provides a sub-core-level task collaborative scheduling method for heterogeneous data stream architectures, comprising: S1: The computation task is broken down into multiple operators, and each operator is further refined into multiple sub-cores to construct a sub-core waiting queue WQ; the resource allocation mask of all PEs in the PE array on the heterogeneous data flow architecture accelerator is initialized so that the initial state of all PEs is idle; S2: Construct a sub-core run queue (EQ) to schedule sub-cores in the WQ to the EQ; the scheduling principle is determined based on the data dependencies and sharing relationships between operators. S3: Dynamically monitor the status of the PE array, traverse the subcores in WQ, schedule the subcores whose required computing resources can be satisfied by the currently idle PEs from WQ to EQ according to the scheduling principle, and generate a corresponding resource allocation mask for the subcores to identify the occupied PEs; S4: Load computation instructions and input data into the corresponding PE for the subcore in EQ, so that the PE can execute the subcore computation task. During the execution of the subcore computation task, steps S3-S4 are repeated. Wherein, when the subcore of the current computation task to be executed and the subcore of the previous completed computation task belong to the same operator and the input data dimension and required computing resources are the same, the PE directly reuses the existing instructions in the instruction storage unit; when the operator corresponding to the subcore of the current computation task to be executed and the operator corresponding to the subcore of the previous completed computation task belong to the same operator with the same input data and no direct data dependency, the PE directly reuses the existing input data in SPM. S5: When the computation task of a certain subcore is completed, remove the subcore from the EQ, release the computation resources occupied by the subcore, and modify the resource allocation mask of the corresponding PE so that the corresponding PE is in an idle state. S6: Check if WQ and EQ are both empty. If not, jump to step S3. If yes, end the scheduling.

[0006] Furthermore, scheduling principles are determined based on the data dependencies and sharing relationships between operators, including: The data dependency and sharing relationships between operators are analyzed based on the operator data flow graph; wherein, the nodes in the operator data flow graph represent operators, and the edges represent the data dependency relationships between operators; Based on the data dependencies and sharing relationships between operators, the multiple operators are clustered into dependent cooperative units, shared cooperative units, and independent cooperative units. Specifically, operators in the dependent cooperative units have direct data dependencies; operators in the shared cooperative units have identical input data and no direct data dependencies; operators in the independent cooperative units have no direct data dependencies and no shared input data; the subkernel granularity and required computational resources are consistent for operators in the shared cooperative units. In the dependent coordination unit, the sub-cores corresponding to the operators are scheduled from WQ to EQ in sequence according to the data dependency relationship of their corresponding operators; when executing the sub-core computing task, the intermediate computing data generated by the sub-cores corresponding to the operators in the dependent coordination unit is directly transmitted through SPM; In the shared collaborative unit, sub-cores with the same input data corresponding to different operators are continuously scheduled from WQ to EQ as a scheduling group, so that when executing sub-core computing tasks, subsequent sub-cores in the same scheduling group can reuse the input data that the previous sub-core has been loaded into SPM; The order in which the sub-cores corresponding to the operators in the independent collaborative unit are scheduled from WQ to EQ is unrestricted. When executing sub-core computing tasks, the sub-cores corresponding to the operators in the independent collaborative unit can independently and in parallel execute sub-core computing tasks.

[0007] Furthermore, in S5, when the computation tasks of the sub-kernel corresponding to a certain operator are all completed, it also includes: according to the data dependency and sharing relationship between operators, removing the data dependency relationship between the successor operators associated with the operator whose computation task has been completed; when the computation tasks of all predecessor operators corresponding to the successor operator are all completed, adding the sub-kernel corresponding to the successor operator to WQ. When a subcore completes its computational task, the process also includes moving the completed subcore into the completion queue.

[0008] Furthermore, initially, the sub-kernels corresponding to operators with an in-degree of 0 in the operator data flow graph are scheduled from WQ to EQ.

[0009] Furthermore, in S4, when the subcore of the current computation task to be executed does not belong to the same operator as the subcore of the previous completed computation task, the input data dimensions of the two are inconsistent, or the computational resources required by the two are consistent, the computational instructions of the subcore are loaded from main memory to the instruction storage unit. If the operator corresponding to the subcore of the current computation task to be executed is not an operator with the same input data as the operator corresponding to the subcore of the previous completed computation task, the input data of the subcore is loaded from main memory into SPM.

[0010] Furthermore, based on the total amount of input data INPUT for operator i i Operator i is refined into several sub-kernels of uniform size, and the input data size of the sub-kernels divided by operator i is SK_INPUT. i = INPUT i / SK_NUM i ;SK_NUM i This represents the number of subkernels partitioned by operator i.

[0011] The present invention also provides a sub-core level task collaborative scheduling and management unit for heterogeneous data stream architecture, including a computer-readable storage medium and a processor; The computer-readable storage medium is used to store executable instructions; The processor is used to read executable instructions stored in the computer-readable storage medium and execute the subcore-level task cooperative scheduling method for heterogeneous data flow architecture described above.

[0012] This invention also provides an accelerator for heterogeneous data stream architectures, comprising: The scheduling management unit is used to perform sub-core level task collaborative scheduling; wherein, the scheduling management unit is the sub-core level task collaborative scheduling management unit for heterogeneous data flow architecture described above. Main memory is used to store subcore loading computation instructions and corresponding input data; The instruction storage unit is used to store the computation instructions when the PE executes sub-core computing tasks; SPM is used to store the input data when PE performs sub-core computing tasks; PE arrays are used to perform sub-core computing tasks.

[0013] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the subcore-level task cooperative scheduling method for heterogeneous data flow architecture as described in any of the preceding claims.

[0014] The present invention also provides a computer program product, including a computer program that, when the computer program is run on a computer, causes the computer to execute the sub-core level task cooperative scheduling method for heterogeneous data flow architecture described above.

[0015] In summary, the above-described technical solutions conceived in this invention can achieve the following beneficial effects: (1) This invention addresses the characteristic of processing unit arrays (PE arrays) that can simultaneously support the parallel execution of multiple sub-cores. By dynamically analyzing the data dependencies and sharing relationships between operators, employing a masking mechanism to allocate computing resources, and combining data reuse technology, it effectively reduces the number of memory accesses and significantly improves the parallelism of multi-task computing and the overall performance of the system. Specifically, this invention further refines operators into smaller-granularity sub-cores, using sub-cores as the scheduling granularity, thus achieving finer-grained scheduling. During scheduling, the PE array can receive and execute multiple sub-cores in parallel at the same time. Through the masking mechanism, multiple sub-cores can simultaneously be allocated non-overlapping (non-conflicting) processing unit array resources and enter a parallel execution state. This method achieves fine-grained automatic decomposition and collaborative mapping of tasks, simplifies the manual configuration process, and greatly improves the resource utilization and flexibility of complex tasks on the PE array. For subcores corresponding to operators with identical input data and no direct data dependencies, shared data is reused across multiple subcores via SPM (Service Management Process). When the subcore of the current computation task to be executed belongs to the same operator as the subcore of the previous completed computation task, and both have the same input data dimension and required computational resources, the PE (Executable Processor) directly reuses existing instructions in the instruction storage unit without reloading. This invention significantly reduces transmission overhead through this reuse mechanism, thereby effectively improving the overall system efficiency. During the execution of subcore computation tasks by the PE, the preparation and scheduling of other subcores are continuously monitored, thus achieving overlapping execution between computation, data transmission, and task scheduling, improving the overall system efficiency and hardware resource utilization.

[0016] (2) Further, by clustering operators into three different types of cooperative execution units, for operators in dependent cooperative units, sub-core computing tasks are executed sequentially according to data dependencies, and intermediate computing data is directly transmitted through SPM, avoiding unnecessary DRAM write-back operations; for operators in shared cooperative units, multiple operators have the same input data source, and data only needs to be loaded from main memory to SPM once for reuse by multiple sub-cores corresponding to multiple operators, reducing data transmission overhead between main memory and PE array, and effectively reducing performance loss caused by frequent sub-core switching; for operators in independent cooperative units, there is no data interaction relationship between operators, and sub-core computing tasks can be executed completely independently and in parallel. This invention, through a dependency-driven cooperative scheduling mechanism and data reuse optimization technology, effectively reduces the number of memory accesses, significantly improves the parallelism of operator execution and the utilization rate of computing resources, and is suitable for various heterogeneous fusion computing scenarios.

[0017] (3) Furthermore, the heterogeneous data flow architecture DFU of the present invention enables dynamic collaborative scheduling and execution of multiple subcores at the same time in the processing unit array, breaking through the serial or coarse-grained execution limitations of traditional heterogeneous data flow accelerators. The system can be widely applied to high-concurrency and heavy-load fusion computing scenarios such as neural networks, graph computing, and big data, and has significant advantages in improving PE resource utilization, reducing memory access overhead, and optimizing computing efficiency.

[0018] In summary, this invention enables multiple tasks to be flexibly scheduled and run in parallel within the PE array through mechanisms such as sub-core-level automatic decomposition of operators, dynamic construction of cooperative execution units, masked resource allocation, and data reuse. This maximizes the release of hardware potential and effectively adapts to the high-concurrency computing needs of technologies such as big data and artificial intelligence. This architecture significantly improves the system's parallelism, resource utilization, and throughput, and substantially alleviates the performance bottlenecks of traditional heterogeneous data stream accelerators. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the hardware structure of the heterogeneous data flow architecture DFU provided in an embodiment of the present invention; Figure 2 This is a flowchart of a sub-core-level task collaborative scheduling method for a heterogeneous data stream architecture provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the multi-operator data multiplexing function provided in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the execution of the sub-core level task collaborative scheduling method for heterogeneous data stream architecture provided in this embodiment of the invention; Figure 5 This is an operator data flow graph of the ResNet18 network provided in this embodiment of the invention; Figure 6 This is a schematic diagram of operator group clustering of the ResNet18 network provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the sub-core level task collaborative scheduling process of the ResNet18 network provided in the embodiments of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0021] To facilitate a clear and accurate understanding of the content and implementation methods of this invention, some terms used in the embodiments of this invention are explained below: Heterogeneous dataflow architecture: Heterogeneous dataflow architecture is a computing architecture that combines different types of processing units (PEs) (such as general-purpose processors and dedicated processors). This architecture can decompose and parallelize computing tasks by constructing an operator dataflow graph, achieving efficient data-driven parallel computing. The core of heterogeneous architecture lies in utilizing the collaborative work of various processors to fully leverage the strengths and performance advantages of different hardware units.

[0022] Runtime System: The runtime system is the software environment that provides the underlying support for the dynamic scheduling and resource allocation of operators. Its main functions include task scheduling, memory management, concurrency control, and dependency tracking, ensuring the efficient, correct, and safe operation of the entire parallel scheduling process. The runtime system provides a coordination interface between the PE array and the host system, and is responsible for complex management functions such as task switching and exception handling.

[0023] Multitask parallelism: Multitask parallelism refers to a technique that allows multiple tasks to be scheduled and executed simultaneously in a heterogeneous data flow architecture. By breaking down large-scale computing tasks into several subtasks that can be executed independently in parallel, multitask parallelism greatly improves the overall throughput and resource utilization efficiency of the system.

[0024] Subcore: A subcore is the smallest computational unit obtained by dividing an operator according to the input data and computational granularity. Each subcore is independent and processes different data blocks, but the functions performed by each subcore of the same operator are completely identical. Subcore-level task partitioning helps to achieve higher computational parallelism and flexibility, and is the core foundation of scheduling in the embodiments of this invention.

[0025] CBUF: CBUF stands for Instruction Buffer Unit, used to store the instruction content of a single operator. The PE array directly obtains the instruction of the currently executed operator through CBUF, ensuring that instructions can be efficiently and continuously delivered to each PE unit to meet the requirements of high-concurrency computing.

[0026] PE Array: A PE array consists of multiple processing units (PEs). Each PE can independently accept tasks, access SPMs, and execute operator-related instructions. Through dynamic scheduling and mask allocation mechanisms, the PE array can support the parallel execution of multiple operators, greatly improving the overall computing power of the system.

[0027] SPM: SPM is a high-speed on-chip data cache module, typically used to temporarily store intermediate data during data stream processing. Proper configuration and management of SPM space plays a crucial role in the efficient execution of operators.

[0028] Data dependency: Data dependency refers to the computational dependency formed when the output of one operator serves as the input of another operator in a computational task.

[0029] Data Flow Graph: A data flow graph is a directed acyclic graph structure that describes the data dependencies between multiple operators. Nodes in the graph represent operators, and edges represent the data dependencies between operators. By analyzing the data flow graph, the system can automatically determine the execution order and parallel opportunities of operators, achieving intelligent scheduling and dependency decoupling.

[0030] Scheduling queue: A scheduling queue is a data structure used to dynamically maintain information about operators to be scheduled and executed during multi-task scheduling. Based on operator states and dependency analysis results, scheduling queues can be divided into subcore waiting queues (WQ), running queues (EQ), and completion queues (CQ). The running queue provides dynamic support for task scheduling algorithms.

[0031] Average PE utilization: Average PE utilization refers to the average workload rate of the PE array over a period of time, and is an important indicator for evaluating the efficiency of computing resource utilization. A high average PE utilization means that the system hardware resources are fully utilized, and the overall system performance is higher.

[0032] To address the shortcomings of existing heterogeneous dataflow accelerators (DFUs) in parallel scheduling, low data reuse efficiency, and limited computational resource utilization in multi-task environments, this invention proposes a sub-core-level task collaborative scheduling method for heterogeneous dataflow architectures. This method specifically targets the capability of processing unit arrays to simultaneously support the parallel execution of multiple sub-cores. By dynamically analyzing data dependencies and sharing relationships between operators, employing a masking mechanism to allocate computational resources, and combining data reuse techniques, it effectively reduces the number of memory accesses, significantly improving the parallelism of multi-task computation and the overall system performance.

[0033] Example 1 like Figure 1 As shown, this embodiment is geared towards a heterogeneous data flow architecture (DFU), whose hardware structure includes the following core components: The scheduling and management unit, mounted on the host, is configured with a high-performance RISC-V processor core and serves as the system's control center. It is responsible not only for initializing the operator queues (subcore waiting queue, running queue, and completion queue) and the processing unit (PE) array state, but also for complex task management functions, including: decomposing computational tasks into multiple operators; constructing a data relationship graph based on data dependencies and sharing relationships; real-time monitoring of PE array resource utilization; and executing multi-subcore dynamic scheduling and resource allocation strategies through a resource masking mechanism. For specific implementation details, please refer to the specific implementation method of the scheduling method in Example 2.

[0034] DMA: Connected to the memory controller and scheduling management unit via a high-speed bus, it is specifically responsible for efficient data transfer between main memory (DRAM) and on-chip cache (SPM). It can independently manage the transfer of large-scale data without the intervention of the RISC-V core, reducing the processing burden of the scheduling management unit and realizing the parallelization of computation and transmission.

[0035] Main memory (DRAM): Provides a large amount of storage space for programs and data. It is used not only to store initial input data and final calculation results, but also to store configuration information for various operators and various parameters required for system operation.

[0036] On-chip cache (SPM): Stores data that can be directly accessed by the PE (Programmer). SPM is used to temporarily store input data needed for the current calculation, intermediate calculation results, and data to be written back. Its core function is to confine data access within the chip as much as possible, thereby greatly reducing the frequency and latency of accessing external DRAM. Through a data reuse check mechanism, duplicate data transmission can be effectively avoided.

[0037] Processing Unit (PE) Array: A computing array consisting of 16 independently addressable processing units (PEs). This array possesses flexible masking and partitioning capabilities, and can be dynamically divided into computing blocks of different sizes (such as 1x1, 1x2, 2x2, 2x4, 4x4) to simultaneously handle sub-core tasks from multiple cooperating execution units. A key feature of this array is its hardware architecture, which supports multiple sub-cores being mapped to different regions of the array for parallel execution, truly achieving fine-grained task-level parallel computing. PEs load instructions through the instruction store unit (CBUF) and obtain computational data from the SPM.

[0038] Instruction Buffer Unit (CBUF): This is a high-speed instruction cache specifically designed for the PE array. It is responsible for receiving and temporarily storing operator instruction sets loaded from main memory via DMA. When a subcore is scheduled for execution, the system first performs an instruction reuse check: if the current subcore's call instruction belongs to the same operator and has the same configuration as the previous subcore, the PE directly reuses the existing instruction in the CBUF; otherwise, a new instruction (the current subcore's call instruction) is loaded from main memory (DRAM). This ensures low latency and high throughput for instruction transmission, preventing the PE from being idle while waiting for instructions.

[0039] Multi-Instance Control Unit (MICC): Responsible for maintaining and managing the execution context of multiple parallel subcores. When the system executes multiple subcores simultaneously, the MICC allocates independent management resources and control states to each subcore instance, ensuring that they are isolated from each other and do not interfere with each other when running on the same processing unit array, and can be correctly initialized, executed, and terminated.

[0040] The implementation methods of the relevant core components are described in the steps of the sub-core level task collaborative scheduling method for heterogeneous data flow architecture in Example 2, and will not be repeated here.

[0041] Example 2 like Figure 2 As shown, the sub-core level task cooperative scheduling method for heterogeneous data flow architectures of the present invention includes the following steps: S1: Initialize the operator queue and processing unit (PE) array, and generate the corresponding subcore waiting queue according to the operator task.

[0042] S2: Based on the operator data flow graph, analyze the data dependency and sharing relationships, and construct the sub-core running queue.

[0043] S3: Dynamically check the availability status of the PE array to determine if there are enough idle PE resources to allocate to ready subcores.

[0044] S4: Based on the configuration, load instructions into the CBUF (Instruction Buffer Unit) and perform data transfer between main memory and SPM. This process includes instruction and data reuse checks to optimize efficiency; when both data and instructions are ready, PE begins executing sub-core computing tasks.

[0045] S5: When a subcore's computational task is completed, update its status to "completed," remove it from the run queue, and release the PE resources it occupies. Simultaneously, remove the dependency constraints of its successor operators, causing their corresponding subcores to potentially enter a waiting state.

[0046] S6: After processing is complete, proceed to the next scheduling cycle. At the beginning of the scheduling cycle, check if both the subcore waiting queue and the subcore running queue are empty. If yes, end the scheduling; otherwise, return to step S3 and repeat the scheduling cycle. The entire scheduling process ends when all subcore computation tasks are completed.

[0047] The following is combined Figure 4 Each step is explained in detail.

[0048] Step S1: Upon system startup, the scheduling and management unit first parses the computation task, decomposing it into multiple basic operator units. It then constructs an operator queue to store operator configuration files, including the required PE size, input / output data addresses, subcore call instruction storage location (the subcore call instruction corresponding to the operator is stored in CBUF), and the number of subcore partitions. Simultaneously, the processing unit array is initialized, with all PE units set to idle. Precise resource management is achieved through a masking mechanism. The PE unit masks are initialized; initially, in this embodiment, all PE masks are set to 1, indicating complete idleness.

[0049] Based on the data size of each operator, the scheduling management unit employs an intelligent partitioning strategy to further divide it into multiple sub-cores, thus forming a structured sub-core waiting queue (WQ). Specifically, for each operator i, the system calculates its input data based on the total amount of INPUT... i Calculate the complexity of operator i and the constraints of operator i on hardware resources (the number of PEs required), and dynamically determine its optimal number of sub-core partitions SK_NUM. i In this embodiment of the invention, the total amount of input data INPUT is used. i Operator i is refined into several sub-kernels of uniform size, with each sub-kernel having an input data size of SK_INPUT. i The result is obtained through calculation (SK_INPUT) i =INPUT i / SK_NUM i The ' / ' operator represents division, ensuring a uniform data distribution. This step ensures that the computational task receives sufficiently fine-grained partitioning, laying the foundation for subsequent parallel scheduling. The system allocates appropriate computational resources to each operator, i.e., determines the required number of processing units PE_NUM. i This value is determined based on the computational density of the operator, and the output data size of operator i is OUTPUT. i .

[0050] Step S2: The scheduling management unit analyzes the data dependencies and sharing relationships between operators based on the pre-built operator data flow graph. In the operator data flow graph, nodes represent operators, and edges represent data dependencies between operators. By identifying the producer-consumer relationship and data sharing pattern between operators, the system constructs a sub-core run queue (EQ) with a clear execution order. For sub-core nodes whose preceding sub-core computation tasks have been completed and whose computational resources meet the requirements, they are scheduled from the waiting queue to the run queue. This process not only considers data flow dependencies but also incorporates the runtime characteristics of each operator, realizing a dynamic scheduling strategy. The system maintains the sub-core waiting queue (WQ), run queue (EQ), and completion queue (CQ) through the RISC-V core, and during initialization, the sub-cores corresponding to operators with an in-degree of 0 in the operator data flow graph are scheduled from the waiting queue (WQ) to the run queue (EQ).

[0051] Based on the analysis of the operator data flow graph, the system adopts a clustering strategy to cluster multiple operators corresponding to the computation task into three different types of collaborative execution units, so as to achieve optimal scheduling efficiency and resource utilization of sub-cores in the sub-core waiting queue, that is, to clarify the order of sub-core scheduling in the sub-core waiting queue: (1) Dependent collaborative units: The system identifies operators with direct data dependency relationships, that is, the output of the predecessor operator (the operator before the current operator) is directly used as the input of the successor operator (the current operator). These operators are clustered into dependent collaborative units, which are characterized by: there is a clear producer-consumer relationship chain between operators; the successor operator is triggered to execute immediately after the predecessor operator is completed. Correspondingly, the sub-core execution of these operators must strictly follow the data flow order; in the sub-core computation, the intermediate data (the data generated by each sub-core computation) is directly transmitted through SPM to avoid unnecessary DRAM write-back operations. (2) Shared Cooperative Unit: The system identifies operators that share the same input data source but have no direct dependency relationship and clusters them into shared cooperative units. The characteristics are: multiple operators have the same input data source; the data only needs to be loaded from main memory to SPM once for multiple operators to reuse; these operators are executed as a whole in a continuous manner (without interspersing other types of operators). Correspondingly, for the sub-cores of these operators, they are continuously scheduled according to the shared input data blocks. That is, sub-cores with the same input data corresponding to different operators are continuously scheduled from WQ to EQ as a scheduling group, so that subsequent sub-cores in the same scheduling group can reuse the input data that the previous sub-core has been loaded into SPM. (3) Independent Cooperative Unit: The system clusters operators that have no data dependency and do not share data source into independent cooperative units. The characteristics are: there is no data interaction relationship between operators, and they can be executed completely independently in parallel. In the sub-core waiting queue, the scheduling order of the sub-cores corresponding to these operators is not constrained. In the subsequent sub-core calculation, the sub-cores corresponding to these operators can be executed in parallel, and the execution order is only constrained by resource availability.

[0052] The scheduling and management unit maps the data flow graph onto the PE array. The PE array can receive and execute multiple subcores in parallel at the same time, allocating an independent PE resource block to each subcore, thus achieving efficient parallel execution of tasks. This approach enables fine-grained automatic decomposition and collaborative mapping of tasks, simplifies the manual configuration process, and greatly improves the resource utilization and flexibility of complex tasks on the PE array.

[0053] For shared collaborative units, the system employs an efficient data reuse strategy to reduce the number of system memory accesses. Shared data is cached in the SPM (System-Level Processing) for multiple operators to access. To achieve data reuse, it is necessary to ensure that operators reusing data have the same input data dimension, the same subkernel partitioning granularity, and the same PE (Preinstallation Environment) resource configuration. Figure 3As shown, both Operator 1 and Operator 2 belong to the shared collaborative unit, and both operators are divided into sub-cores 0 and 1 with the same input data dimension, computational granularity, and PE resource configuration. To achieve direct reuse of input data, the sub-cores of the two operators should not be executed in the order of first executing Operator 1 completely, then executing Operator 2 completely. Instead, the computation should be organized by alternating executions of the same sub-core granularity, i.e., the execution order is: sub-core 0 of Operator 1, sub-core 0 of Operator 2, sub-core 1 of Operator 1, and sub-core 1 of Operator 2. In this way, after sub-core 0 of Operator 1 completes its computation, sub-core 0 of Operator 2 can directly reuse the input data already loaded by sub-core 0 of Operator 1; similarly, after sub-core 1 of Operator 1 completes its computation, sub-core 1 of Operator 2 can also directly reuse the corresponding loaded input data.

[0054] Step S3: The scheduling management unit first checks the current state of the processing unit array. Specifically, the scheduling management unit determines the availability of PE resources by maintaining a PE status mask (PE_Mask), where each bit of the PE status mask corresponds to a PE unit, used to indicate whether it is currently idle (e.g., "0" indicates idle, "1" indicates occupied). Subsequently, the scheduling management unit sequentially traverses all subcores in the waiting state in the WQ, checking one by one whether their resource requirements can be satisfied by the currently idle PE resources. Only when the required PE resource scale of a certain subcore can be satisfied will the scheduling management unit move it from the WQ to the EQ and generate a corresponding resource allocation mask (Alloc_Mask) for it, identifying the PE array that will be occupied. Multiple subcores can be allocated non-overlapping (non-conflicting) processing unit array resources simultaneously and enter a parallel execution state; priority is given to selecting ready subcores whose dependent de-escalated data requirements do not exceed the SPM capacity. When there are multiple ready subcores, the best fit operator can be used to select the subcore that can be allocated PE resources. If the currently available resources are insufficient to satisfy any waiting subcores, the scheduling management unit will not allocate resources temporarily and will retry scheduling after the PE resources are released. By precisely matching memory and computing resources, the PE array can support the simultaneous scheduling and execution of multiple subcores within the same cycle, effectively avoiding cache overflow, reducing waiting and blocking, and improving data flow efficiency and multi-task processing capabilities.

[0055] Step S4: Responsible for optimizing the instruction and data transfer processes required for subcore execution. By optimizing the loading of instructions from the instruction cache unit to the instruction storage unit (CBUF) and the data transfer process between main memory (DRAM) and on-chip cache (SPM), the data reuse function is fully utilized to minimize memory access overhead. After the subcore is successfully allocated computing resources and added to the run queue, the scheduling management unit first processes its instruction loading requirements: the system checks whether the current CBUF already contains the instructions of the operator to which the subcore belongs. If the currently ready subcore belongs to the same operator as the previous subcore that has already been executed, and the data size and PE configuration of the two are exactly the same, then the PE directly reuses the existing instructions in the CBUF without reloading from main memory (DRAM), thereby avoiding the latency caused by repeated transmission; if there is a miss, the required instructions (subcore calculation instructions) are reloaded from main memory (DRAM) to the CBUF. Meanwhile, the system performs a reuse check on the data in SPM: by analyzing the data dependencies and the current data status of SPM, it determines whether the input data of the currently ready subcore can be reused from the existing data in SPM. If the operators corresponding to the currently ready subcore and its previous completed subcore belong to the operators in the shared cooperative unit, they can be reused. If they can be reused, there is no need to reload. Otherwise, the required data is loaded from main memory to the designated area of ​​SPM via DMA.

[0056] The system triggers subcore execution via MICC only when the subcore computation instructions have been successfully loaded into the CBUF and the required data (the subcore's input data) is located in the SPM. The scheduling management unit issues an execution command to the PE array, which locates the specific PE set according to the pre-allocated resource mask (Alloc_Mask). These designated PE units then read the instructions from the CBUF and the input data from the predetermined address in the SPM, and begin executing the computation task of the currently ready subcore. If there are multiple currently ready subcores, the computation of multiple subcores is executed in parallel. During this process, the scheduling management unit is not in a waiting state, but continuously monitors the execution status of the processing unit array and continues to manage the preparation and scheduling of other subcores in the subcore waiting queue. This achieves overlapping execution between computation and data transmission, and task scheduling, improving the overall system efficiency and hardware resource utilization.

[0057] Step S5: Manage the parallel execution, state update, resource release, and dependency resolution of subcores on the PE array to ensure the reclamation and reuse of computing resources. When a subcore completes execution on the processing unit array, the system immediately initiates a post-processing update mechanism to ensure timely reclamation of computing resources and the continued execution of subsequent tasks. Upon receiving a task completion signal from the PE array, the scheduling management unit first updates the subcore's state to "completed" and moves it from the run queue (EQ) to the completion queue (CQ) for recording. Subsequently, the system releases all PE resources occupied by the subcore and modifies the occupancy status of the corresponding PE bit in the resource allocation mask (Alloc_Mask), remarking it as idle. Furthermore, once an operator has finished executing (and all the computational tasks of the sub-cores corresponding to that operator have been completed), the system will dynamically remove the data dependency constraints of all direct successor nodes (operators) of this operator based on the predefined operator data flow graph. That is, the unfinished predecessor counter of each successor operator will be decremented by one. If the counter of a successor node becomes zero as a result, it means that all its predecessor tasks have been completed and the data is ready. The system will then add the sub-cores corresponding to these successor operators to the waiting queue (WQ) to wait for selection and execution in subsequent scheduling cycles.

[0058] Step S6: After completing the current subcore's completion status update, resource release, and dependency removal, the next scheduling cycle begins. The system continuously monitors and checks the status of the subcore waiting queue (WQ) and running queue (EQ) to determine whether the scheduling process has ended. At the beginning of each scheduling cycle, the scheduling management unit checks whether both WQ and EQ are empty: if both are empty, it indicates that all subcore computation tasks have been executed (computation in the PE array) and the system ends the entire scheduling process and releases related resources; if either WQ or EQ is not empty, it indicates that there are still subcores waiting to be scheduled or tasks currently executing subcore computations, and the system returns to step S3 to continue executing the next scheduling cycle. This design allows the system to continuously perform closed-loop operations of "queue status monitoring (S6) -> resource checking and allocation (S3) -> instruction and data transmission (S4) -> execution, status update, and resource release (S5)" until the final termination condition is met, i.e., confirming that both the waiting queue (WQ) and running queue (EQ) are empty. Only when both of these core queues are empty does the scheduling task officially end.

[0059] Throughout the scheduling process, the resource utilization of the PE array is monitored, and once an available PE resource becomes available, it is immediately allocated to the ready subcore.

[0060] like Figure 4As shown, according to the data flow diagram between operators 1 to 8, after the sub-core (sub-1) corresponding to operator 1 finishes execution, the sub-cores (sub-2-sub-5) corresponding to operators 2 to 5 can be executed in parallel (when computing resources allow), the sub-cores (sub-6 and sub-8) corresponding to operators 6 and 8 can be executed in parallel, and the sub-cores (sub-7 and sub-8) corresponding to operators 7 and 8 can be executed in parallel.

[0061] The subcore-level task collaborative scheduling method for heterogeneous dataflow architecture (DFU) in this invention fully leverages the unique advantages of the novel heterogeneous dataflow architecture, particularly its ability to support the parallel execution of multiple subcores simultaneously by the PE array. Through fine-grained task partitioning, dependency-driven collaborative management, masked resource allocation, and efficient instruction and data reuse techniques, it significantly improves the system's parallelism, resource utilization, and computational efficiency, providing robust runtime support for high-concurrency, computationally intensive, and memory-intensive application scenarios. The system decomposes complex computational tasks into multiple operators, further refines them into subcores, and constructs a dynamic scheduling queue based on the dataflow graph, achieving fine-grained parallel mapping of tasks. The scheduling management unit dynamically allocates PE resources by monitoring the processing unit array status and SPM capacity in real time, using resource masking and optimal adaptation algorithms to ensure conflict-free parallel execution of multiple subcores on the processing unit array. The efficient reuse mechanism of SPM significantly reduces DRAM access overhead. Compared to traditional control flow architectures or static scheduling methods, this invention achieves significant breakthroughs in the following aspects: 1) It greatly improves hardware utilization and system throughput through multi-subcore collaborative execution and dynamic PE partitioning; 2) Dependency-driven collaborative management optimizes the execution order of subcore computing tasks, maximizing parallel opportunities; 3) An efficient data reuse mechanism significantly reduces memory access overhead; 4) A masked resource allocation and fast release mechanism ensures full utilization of computing resources. This method is particularly suitable for fusion computing scenarios requiring high parallelism and low latency, such as neural network computing, graph computing, scientific computing, and big data processing. It provides an efficient, flexible, and scalable runtime support system for heterogeneous dataflow architectures, breaking through the performance bottlenecks of traditional architectures under the "power wall" and "memory wall," and providing an innovative solution for modern high-performance computing applications.

[0062] The following section uses some operators of the ResNet18 network as examples to demonstrate the specific application of the sub-core-level task cooperative scheduling method of this invention for novel heterogeneous data flow architectures (DFU). The following will combine... Figure 5 The ResNet18 network data flow diagram shown describes the scheduling process in detail. This embodiment fully demonstrates the practical value and performance advantages of the sub-kernel-level task cooperative scheduling method for heterogeneous data flow architectures in complex neural networks, providing a referable solution for optimizing networks with similar structures.

[0063] Step S1: Initialization and sub-kernel partitioning.

[0064] During the system initialization phase, the scheduling and management unit first parses the computational tasks in the ResNet18 network, decomposing them into basic operator units such as Conv, ReLU, Add, AvgPool, Flatten, and GEMM. For each operator, it generates a corresponding configuration file containing PE resource requirements, data size, and instruction addresses. Simultaneously, the scheduling and management unit initializes the 16 processing units on the DFU accelerator, setting all PE states to idle and performing fine-grained resource management through a masking mechanism.

[0065] Based on the computational characteristics and data scale of each operator, the scheduling management unit employs an intelligent partitioning strategy to refine these operators into multiple sub-cores, enabling fine-grained collaborative scheduling. For example, the Conv1 operator with an input data size of 256x256 is divided into four sub-cores (Conv1-1 to Conv1-4), each processing 128x128 data points and allocated eight processing units (PEs). Similarly, the Conv3 operator is divided into four sub-cores (Conv3-1 to Conv3-4) and allocated eight PEs to process data, facilitating data reuse with the Conv1 operator. This is achieved by calculating SK_INPUT. i = INPUTi / SK_NUM i The size of each subcore data fragment is determined, and a structured subcore waiting queue (WQ) is finally constructed. Subcores without prerequisite dependencies are added to this queue.

[0066] Step S2: Dependency analysis and runtime queue construction.

[0067] The system is based on the ResNet18 network operator data flow graph. The scheduling management unit analyzes the data dependencies and sharing relationships between operators, identifies producer-consumer relationships and data sharing patterns, and thus constructs a sub-core execution queue with a clear execution order. This process combines the topology of the data flow graph and the runtime characteristics of the operators to ensure that the scheduling strategy satisfies dependency constraints while maximizing parallelism.

[0068] like Figure 6 As shown, the system employs a specific clustering strategy to cluster the operators of the data flow graph into three types of cooperative execution units to optimize scheduling efficiency and computational resource utilization: Dependency-based cooperating units: Relu3, Conv4, Relu4, Conv5, Add2, AvgPool1, Flatten1, GEMM1. These operators form explicit dependency chains; for example, the output of Relu3 serves as the input of Conv4, and the output of Conv4 serves as the input of Relu4, ultimately completing the computation through GEMM1. The system identifies these producer-consumer relationships, constructs dependency sequences, and ensures that subsequent operations are triggered only after the predecessor operator has completed its task. Intermediate data can be directly transferred via SPM, avoiding unnecessary DRAM write-backs.

[0069] Shared cooperating units: Relu1, Conv1, and Conv3. These operators share the same input data source; for example, Conv1 and Conv3 process the output data of the same preceding operator, Relu1. The system recognizes this characteristic and prioritizes loading the shared data from DRAM to the SPM at once for reuse by multiple subcores. To achieve efficient reuse, the system ensures that the input data dimensions of the reused operators are consistent, the subcore partitioning granularity is the same (e.g., Conv1 and Conv3 are both divided into four subcores), and the PE resource configuration is matched (e.g., Conv1 and Conv3 both use 8 PEs).

[0070] Independent coordinating units: Relu1 and Relu2. These operators have no data interaction relationship and can be executed completely independently and in parallel. The system treats these operators as independent tasks and can flexibly schedule them to make full use of PE resources.

[0071] In its implementation, the system dynamically constructs scheduling queues based on the data flow graph of the ResNet18 network. The scheduling management unit employs a dynamic coordination strategy, placing Conv1 and Conv3 of shared coordination units at the same scheduling priority to share data in the SPM; operators dependent on coordination units are arranged in dependency order, initially adding only Relu3 without prior dependencies to the EQ. Relu1 and Relu3 of independent coordination units, having no dependencies, can be moved from the WQ to the EQ at any time to utilize remaining PE resources. Furthermore, the system adjusts the priority of subcores based on runtime characteristics, and the RISC-V core updates the queue status in real time to ensure that subcores with de-dependencies enter the EQ promptly, maximizing the parallel utilization of the PE array.

[0072] Step S3: Dynamic resource allocation.

[0073] During the current scheduling cycle, the scheduling management unit first checks the current resource status of the PE array to ensure efficient allocation of computing resources. The system monitors the availability of the PE array in real time through the scheduling management unit and maintains a PE status mask (PE_Mask), where each bit corresponds to a PE unit, with "0" indicating idle and "1" indicating occupied. For example, an initial PE_Mask of 1111111111111111 indicates that the array is completely idle. Assuming the current status is 1111111100000000, it indicates that the first 8 PEs (PE 0–7) are idle, and the last 8 PEs (PE 8–15) are occupied.

[0074] The scheduling management unit traverses all ready subcores in WQ and checks their resource requirements (PE_NUM) one by one. i The scheduling management unit generates a resource allocation mask (Alloc_Mask) for each ready subcore and matches it with the current number of idle PEs. When resource demand is met, the scheduling management unit generates a resource allocation mask (Alloc_Mask) for each ready subcore, identifying the specific PE unit occupied, and moves it from WQ to EQ. The system uses bitwise operations to ensure that Alloc_Masks do not overlap, avoiding resource conflicts. For example, assuming there are currently 12 idle PEs (PE_Mask000000000001111), the host allocates 2x4 PE blocks (PE 0–PE 7, Alloc_Mask1111111100000000) to Conv2, and the remaining 8 PEs (PE 8–PE 11) can continue to be allocated. Conv3 is allocated 1x2 PE blocks (PE 8-PE 9, Alloc_Mask 000000011000000), and can continue to allocate 1x2 PE blocks (PE 10–PE 11, Alloc_Mask 0000000000110000) for Conv5. The system uses bitwise operations to ensure that Alloc_Masks do not overlap, avoiding resource conflicts, and adds Conv2, Conv3, and Conv5 to the EQ (Intelligent Queuing) for parallel execution. The flexible partitioning mechanism of the PE array supports multiple operators running in parallel at the same time, and also supports multiple operators performing data reuse operations to reduce memory access frequency.

[0075] If the current idle PEs are insufficient to meet the needs of any subcore (for example, there are only 2 PEs left while Conv5 requires 4 PEs), the host will not allocate resources for the time being, and will wait for the subsequent subcores to be completed before re-checking PE_Mask and continuing scheduling.

[0076] Step S4: Instruction and data transmission and sub-core computing task execution.

[0077] After a subcore is successfully allocated PE resources and added to the run queue (EQ), the system immediately initiates the instruction and data transfer process. The system first handles instruction loading requests: by querying the configuration of the scheduled subcore, if the current subcore belongs to the same operator as the previous subcore, the instructions already stored in the CBUF can be directly reused to avoid the overhead of duplicate instruction transfer. Otherwise, the corresponding instructions are loaded from main memory into the CBUF.

[0078] In terms of data transmission, the system fully utilizes the caching characteristics of SPM to achieve data reuse. If the ReLU1 output data is already cached in SPM, and Conv1 and Conv3 process the same input data, they can be scheduled alternately at the subcore granularity. For example, subcore 0 of Conv1, subcore 0 of Conv3, subcore 1 of Conv1, and subcore 1 of Conv3 can be executed sequentially. In this way, the corresponding subcore of Conv3 can directly reuse the ReLU1 output data block that has been loaded into SPM during the execution of Conv1, avoiding the repeated loading of the same input data from DRAM. Figure 7 As shown, once the instruction has been successfully loaded into the CBUF and the required data is located in the SPM, the system triggers the parallel execution of multiple subcores simultaneously via the MICC. The scheduling management unit issues execution commands to the PE array, and each PE unit locates the specific computing resource according to the pre-allocated resource mask (Alloc_Mask) and executes the corresponding subcore task in parallel: first, Relu1 and Relu2 run in parallel on 8 PEs respectively; after completion, they proceed to the next step. If the queue is not empty, they return to step S3, and then Conv1 executes on PEs 0–PE 8, while Conv4 executes in parallel on PEs 9–PE 11.

[0079] Step S5: Release resources and remove dependencies.

[0080] Once a subcore completes execution, the PE array sends a task completion signal to the scheduling management unit, triggering the post-processing update mechanism. The scheduling management unit immediately updates its status to "completed," removes it from the run queue (EQ), and moves it to the completion queue (CQ) for recording.

[0081] Subsequently, the system releases the PE resources occupied by these sub-cores, clears the corresponding resource allocation mask (Alloc_Mask), and marks the corresponding bits of the PE status mask (PE_Mask) as free, making these PE units available for subsequent tasks. Specifically, when Relu1 finishes execution, the system releases PEs 0-7 (updates Alloc_Mask from 111111110000000 to 00000000000000000) and marks the corresponding bits of the PE status mask (PE_Mask) as free, making these PE units available for subsequent tasks.

[0082] Furthermore, the system dynamically removes the successor dependencies of completed operators based on the operator data flow graph of the ResNet18 network. The scheduling management unit checks the incomplete predecessor counter of each successor subcore. If the counter is decremented by one and becomes zero, the subcore is set to ready and added to the subcore waiting queue (WQ). For example, after Relu1 completes execution, the predecessor counters of Conv1 and Conv3 are decremented by one. If their predecessor counters are updated to 0 at this time, the scheduling management unit will add the corresponding subcore to the WQ, waiting for PE resources to be allocated in subsequent scheduling cycles.

[0083] Step S6: Scheduling loop and termination.

[0084] After the scheduling management unit completes the resource release and dependency removal for the current subcore, the system continuously monitors and maintains the status of the subcore waiting queue (WQ) and running queue (EQ) through the RISC-V control core to determine the progress of the scheduling process. At the beginning of each scheduling cycle, the system checks the status of WQ and EQ: if WQ contains subcores in a ready state such as Relu1 and Relu2, or if EQ contains tasks such as Conv3 being executed, it indicates that the computation task has not yet been completed, and the system will continue to return to step S3 for the next scheduling cycle. For example, when Conv1 and Conv4 are added to the waiting queue (WQ), the system immediately detects that WQ is not empty in the next cycle, then performs resource allocation and starts the corresponding instruction and data transmission; only when both queues are empty at the same time does it indicate that all computation tasks have been completed. At this time, the system terminates the entire scheduling process and releases the occupied PE array and storage resources. By continuously executing the closed-loop operation of "queue monitoring → resource allocation → data transmission → execution update", the system realizes pipelined scheduling of computation tasks. Finally, when all subcores have completed execution, that is, when WQ and EQ are both empty, the scheduling process of the entire ResNet18 network computation task ends.

[0085] This example demonstrates the complete application flow of a sub-core-level task cooperative scheduling method for heterogeneous dataflow architectures (DFU) in a ResNet18 network. This method achieves efficient parallel execution of operators such as Conv, ReLU, and Add through dynamic construction of cooperative execution units, masked resource allocation, and dataflow-driven scheduling. Simultaneously, the system significantly reduces data transmission overhead and computational idle time by utilizing SPM data reuse, CBUF instruction sharing, and PE array masked resource management. While improving hardware resource utilization, it accelerates the ResNet18 feature extraction and fusion tasks, providing a practical example for efficient scheduling of complex neural networks.

[0086] Example 3 This invention provides a subcore-level task collaborative scheduling management unit for heterogeneous data flow architecture, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the subcore-level task collaborative scheduling method for heterogeneous data flow architecture in Embodiment 2 above.

[0087] The relevant technical solutions are the same as above, and will not be repeated here.

[0088] Example 4 This invention provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the steps of the sub-core level task cooperative scheduling method for heterogeneous data flow architecture described in Embodiment 2 above.

[0089] Specifically, the memory may include high-speed random access memory, as well as non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital (SD) cards, flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0090] The relevant technical solutions are the same as above, and will not be repeated here.

[0091] Example 5 This invention provides a computer program product, including a computer program that, when run on a computer, causes the computer to execute the steps of the sub-core level task cooperative scheduling method for heterogeneous data flow architecture described in Embodiment 2 above.

[0092] The relevant technical solutions are the same as above, and will not be repeated here.

[0093] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A sub-core-level task collaborative scheduling method for heterogeneous dataflow architectures, characterized in that, include: S1: The computation task is broken down into multiple operators, and each operator is further refined into multiple sub-cores to construct a sub-core waiting queue WQ; the resource allocation mask of all PEs in the PE array on the heterogeneous data flow architecture accelerator is initialized so that the initial state of all PEs is idle; S2: Construct a sub-core run queue (EQ) to schedule sub-cores in the WQ to the EQ; the scheduling principle is determined based on the data dependencies and sharing relationships between operators. S3: Dynamically monitor the status of the PE array, traverse the subcores in WQ, schedule the subcores whose required computing resources can be satisfied by the currently idle PEs from WQ to EQ according to the scheduling principle, and generate a corresponding resource allocation mask for the subcores to identify the occupied PEs; S4: Load computation instructions and input data into the corresponding PE for the subcore in EQ, so that the PE can execute the subcore computation task. During the execution of the subcore computation task, steps S3-S4 are repeated. Wherein, when the subcore of the current computation task to be executed and the subcore of the previous completed computation task belong to the same operator and the input data dimension and required computing resources are the same, the PE directly reuses the existing instructions in the instruction storage unit; when the operator corresponding to the subcore of the current computation task to be executed and the operator corresponding to the subcore of the previous completed computation task belong to the same operator with the same input data and no direct data dependency, the PE directly reuses the existing input data in SPM. S5: When the computation task of a certain subcore is completed, remove the subcore from the EQ, release the computation resources occupied by the subcore, and modify the resource allocation mask of the corresponding PE so that the corresponding PE is in an idle state. S6: Check if WQ and EQ are both empty. If not, jump to step S3. If yes, end the scheduling.

2. The sub-core level task collaborative scheduling method for heterogeneous data flow architecture according to claim 1, characterized in that, Scheduling principles are determined based on data dependencies and sharing relationships between operators, including: The data dependency and sharing relationships between operators are analyzed based on the operator data flow graph; wherein, the nodes in the operator data flow graph represent operators, and the edges represent the data dependency relationships between operators; Based on the data dependencies and sharing relationships between operators, the multiple operators are clustered into dependent cooperative units, shared cooperative units, and independent cooperative units. Specifically, operators in the dependent cooperative units have direct data dependencies; operators in the shared cooperative units have identical input data and no direct data dependencies, and the subkernel granularity and required computational resources are consistent; operators in the independent cooperative units have no direct data dependencies and no shared input data. In the dependent coordination unit, the sub-cores corresponding to the operators are scheduled from WQ to EQ in sequence according to the data dependency relationship of their corresponding operators; when executing the sub-core computing task, the intermediate computing data generated by the sub-cores corresponding to the operators in the dependent coordination unit is directly transmitted through SPM; In the shared collaborative unit, sub-cores with the same input data corresponding to different operators are continuously scheduled from WQ to EQ as a scheduling group, so that when executing sub-core computing tasks, subsequent sub-cores in the same scheduling group can reuse the input data that the previous sub-core has been loaded into SPM; The order in which the sub-cores corresponding to the operators in the independent collaborative unit are scheduled from WQ to EQ is unrestricted. When executing sub-core computing tasks, the sub-cores corresponding to the operators in the independent collaborative unit can independently and in parallel execute sub-core computing tasks.

3. The sub-core level task collaborative scheduling method for heterogeneous data flow architecture according to claim 2, characterized in that, In S5, when the computation tasks of the sub-kernel corresponding to a certain operator are all completed, it also includes: according to the data dependency and sharing relationship between operators, removing the data dependency relationship between the successor operators associated with the operator whose computation task has been completed; when the computation tasks of all predecessor operators corresponding to the successor operator are all completed, adding the sub-kernel corresponding to the successor operator to WQ. When a subcore completes its computational task, the process also includes moving the completed subcore into the completion queue.

4. The sub-core level task collaborative scheduling method for heterogeneous data flow architecture according to claim 3, characterized in that, Initially, the sub-kernels corresponding to operators with an in-degree of 0 in the operator data flow graph are scheduled from WQ to EQ.

5. The sub-core level task collaborative scheduling method for heterogeneous data flow architecture according to any one of claims 1-3, characterized in that, In S4, when the subcore of the current computation task to be executed does not belong to the same operator as the subcore of the previous completed computation task, the input data dimensions of the two are inconsistent, or the computational resources required by the two are consistent, the computational instructions of the subcore are loaded from the main memory to the instruction storage unit. If the operator corresponding to the subcore of the current computation task to be executed is not an operator with the same input data as the operator corresponding to the subcore of the previous completed computation task, the input data of the subcore is loaded from main memory into SPM.

6. The sub-core-level task collaborative scheduling method for heterogeneous data flow architecture according to any one of claims 1-3, characterized in that, Based on the total amount of input data INPUT for operator i i Operator i is refined into several sub-kernels of uniform size, and the input data size of the sub-kernels divided by operator i is SK_INPUT. i = INPUT i / SK_NUM i ;SK_NUM i This represents the number of subkernels partitioned by operator i.

7. A sub-core-level task collaborative scheduling and management unit for heterogeneous data flow architectures, characterized in that, Includes computer-readable storage media and processors; The computer-readable storage medium is used to store executable instructions; The processor is used to read executable instructions stored in the computer-readable storage medium and execute the subcore-level task cooperative scheduling method for heterogeneous data flow architecture as described in any one of claims 1-6.

8. An accelerator for heterogeneous data flow architectures, characterized in that, include: A scheduling management unit is used to perform sub-core level task collaborative scheduling; wherein, the scheduling management unit is the sub-core level task collaborative scheduling management unit for heterogeneous data flow architecture as described in claim 7; Main memory is used to store subcore loading computation instructions and corresponding input data; The instruction storage unit is used to store the computation instructions when the PE executes sub-core computing tasks; SPM is used to store the input data when PE performs sub-core computing tasks; PE arrays are used to perform sub-core computing tasks.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the subcore-level task cooperative scheduling method for heterogeneous data flow architecture as described in any one of claims 1-6.

10. A computer program product, characterized in that, The method includes a computer program that, when run on a computer, causes the computer to execute the sub-core level task cooperative scheduling method for heterogeneous data flow architecture as described in any one of claims 1-6.

Images