A method and system for guaranteeing hard real-time task deadline and optimizing soft real-time task response time in CGRA

Abstract

This invention discloses a method and system for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA (Current Real-Time Allocation). Belonging to the field of real-time task scheduling technology, it resolves the conflict between ensuring deadlines for hard real-time tasks and minimizing response times for soft real-time tasks. First, CGRA resources are statically allocated to different hard real-time tasks. Then, through mechanism analysis, an algebraic equation is derived to define the worst-case continuous preemption delay based on the resource allocation of each task. Finally, response time analysis is used to determine whether the hard real-time tasks can still meet their deadlines even under the worst-case continuous preemption scenario. This invention is applicable to scenarios such as flight control and automotive fault detection.

Description

Technical Field

[0001] This invention belongs to the field of real-time task scheduling technology, specifically relating to an optimization method for real-time task scheduling in coarse-grained reconfigurable architecture (CGRA). Background Technology

[0002] Currently, CGRA (Current Real-Time Response) is widely used in scenarios involving real-time tasks, such as flight control, automotive fault detection, and robot motion control. These scenarios simultaneously involve both hard real-time and soft real-time tasks. Hard real-time tasks must strictly meet deadlines, while soft real-time tasks need to minimize response time. Existing CGRA real-time task scheduling technologies suffer from two typical drawbacks, failing to balance the requirements of both:

[0003] (1) Static-AllShare mode: Allows soft real-time tasks to share all statically allocated resources of hard real-time tasks. Although it can reduce the response time of soft real-time tasks to a certain extent, it lacks clear modeling of the preemption delay of hard real-time tasks, especially the quantitative analysis of continuous preemption delay. In the worst case, multiple hard real-time tasks will fail to meet the deadline, which seriously affects the reliability of the real-time system. This problem is more prominent in sporadic hard real-time task (release time is uncertain) scenarios.

[0004] (2) Static-NoShare mode: Completely prohibits resource sharing between hard real-time tasks and soft real-time tasks. Although it can ensure the deadline of hard real-time tasks, the statically allocated resources are mostly idle due to the uncertain release time of hard real-time tasks. This results in insufficient available resources for soft real-time tasks, significantly extended response time, and extremely low resource utilization.

[0005] The core shortcoming of existing technologies lies in the lack of an effective preemption latency model for hard real-time tasks, which makes it impossible to achieve dynamic adaptive adjustment of resource sharing. This results in either sacrificing the deadline guarantee for hard real-time tasks or wasting resources and extending the response time of soft real-time tasks, making it difficult to adapt to the actual needs of CGRA real-time task scheduling. Summary of the Invention

[0006] This invention provides a method and system for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA. The purpose is to solve the problems in the prior art, such as hard real-time task deadlines being easily missed due to the static fully shared mode, resource idleness due to the static non-shared mode, long response times for soft real-time tasks, and the conflict between ensuring deadlines for hard real-time tasks and minimizing response times for soft real-time tasks.

[0007] Firstly, the purpose of this invention is to provide a method for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA, comprising the following steps:

[0008] S1. For multiple hard real-time tasks to be scheduled, calculate the minimum CGRA resource amount required for each hard real-time task to meet its deadline, and complete the CGRA mapping verification; sort all hard real-time tasks in descending order according to the leniency; allocate physical PE positions to each hard real-time task in order of the sorting results, with the allocation starting from the PE closest to the controller.

[0009] S2. Establish a CGRA preemption delay model based on the preset NoC deterministic service constraints; through the preemption delay model, calculate the transmission delay and total preemption delay of a single preemption when the PE position of a hard real-time task is shared, further calculate the upper bound of the merged preemption delay in the scenario where multiple hard real-time tasks continuously initiate preemption, and finally obtain the upper bound of the continuous preemption delay of hard real-time tasks.

[0010] S3. Initially mark the PE positions of all hard real-time tasks as shareable; based on the continuous preemption delay upper bound, calculate the worst-case execution time of each hard real-time task in the shareable state, and verify whether all hard real-time tasks in the shareable state meet the deadline requirements in combination with the response time. If there are hard real-time tasks that do not meet the deadline requirements, mark the PE position of the last hard real-time task in the sorting result as non-shareable, and repeat the worst-case execution time calculation and deadline verification steps until all hard real-time tasks in the shareable state meet the deadline requirements.

[0011] Furthermore, a preferred option is provided: the leniency is the ratio of the deadline to the execution time of a hard real-time task.

[0012] Furthermore, a preferred solution is provided: In S2, the NoC deterministic service constraint includes:

[0013] The controller is the sole source for NoC command injection, and command propagation uses unicast and deterministic routing.

[0014] The controller's command injection rate shall not exceed the forwarding rate of the router in the NoC.

[0015] Furthermore, a preferred solution is provided: In S2, during a single preemption process, the number of transmission clock cycles for a single command is calculated using the following formula:

[0016] ,

[0017] in, The number of PEs statically allocated to the current hard real-time task; The number of hops required for the controller to send a command to the i-th preempted PE; The number of clock cycles required per hop; The number of chips per command.

[0018] Furthermore, a preferred solution is provided: In S2, a single preemption includes: context recording, state clearing, and task execution, with each step consisting of:

[0019] ,

[0020] in, The number of cycles required to process commands for PE.

[0021] Furthermore, a preferred embodiment is provided: In S3, the worst-case execution time of a hard real-time task with shareable state is the sum of the execution time of the hard real-time task at its PE position and the upper bound of the continuous preemption delay.

[0022] Furthermore, a preferred solution is provided: during system runtime, soft real-time tasks use PE resources marked as shareable.

[0023] Secondly, the purpose of this invention is to propose a system for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA. The system is implemented based on a method for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA, as described in any one or more of the above-mentioned schemes. The system includes:

[0024] Static resource partitioning module: For multiple hard real-time tasks to be scheduled, it calculates the minimum CGRA resource amount required for each hard real-time task to meet its deadline and completes CGRA mapping verification; it sorts all hard real-time tasks in descending order according to the leniency; and it allocates physical PE positions to each hard real-time task in order of the sorting results, with the allocation starting from the PE closest to the controller.

[0025] The continuous preemption delay upper bound calculation module is used to establish a CGRA preemption delay model based on the preset NoC deterministic service constraints. Through the preemption delay model, the transmission delay and total preemption delay of a single preemption when the PE position of a hard real-time task is shared are calculated. The module further calculates the combined preemption delay upper bound in the scenario where multiple hard real-time tasks continuously initiate preemption, and finally obtains the continuous preemption delay upper bound of the hard real-time task.

[0026] Resource sharing marking module: used to initially mark the PE position of all hard real-time tasks as shareable; based on the continuous preemption delay upper bound, calculate the worst-case execution time of each hard real-time task in the shareable state, and verify whether all hard real-time tasks in the shareable state meet the deadline requirements in combination with the response time. If there are hard real-time tasks that do not meet the deadline requirements, mark the PE position of the hard real-time task at the end of the sorting result as non-shareable, and repeat the worst-case execution time calculation and deadline verification steps until all hard real-time tasks in the shareable state meet the deadline requirements.

[0027] Thirdly, the present invention aims to provide a computer device, the computer device including a memory and a processor, the memory storing a computer program, and when the processor runs the computer program stored in the memory, the processor executes a method for ensuring the deadline of hard real-time tasks and optimizing the response time of soft real-time tasks in CGRA according to any one or more of the above-described schemes.

[0028] Fourthly, the present invention aims to provide a computer-readable storage medium for storing a computer program that executes a method for ensuring the deadline of hard real-time tasks and optimizing the response time of soft real-time tasks in CGRA, as described in any one or more of the above-described schemes.

[0029] Compared with the prior art, the advantages of the present invention are:

[0030] 1. Hard real-time task guarantee: All hard real-time tasks can strictly meet the deadline, with no deadline missed, which solves the problem of unreliability of hard real-time tasks in the existing static full-shared mode;

[0031] 2. Soft real-time task optimization: Soft real-time tasks can utilize the shareable resources of hard real-time tasks, reducing response time by 20.8%~74.3% compared to the static non-shared mode (74.3% reduction in 8×8 CGRA scenarios and 20.8% reduction in 10×10 CGRA scenarios).

[0032] 3. Economic benefits: Without additional hardware costs, the real-time scheduling performance of CGRA can be improved simply by optimizing the software scheduling strategy, reducing system failure losses caused by missed deadlines of hard real-time tasks, while improving the processing efficiency of soft real-time tasks and reducing the overall operating cost of the system.

[0033] The method described in this invention is applicable to critical real-time scenarios such as flight control and vehicle fault detection, improving the reliability and efficiency of system operation, reducing safety hazards caused by real-time task scheduling errors, and promoting the widespread application of CGRA in the field of real-time systems. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0035] Figure 1 This is a flowchart of a method for ensuring the deadline of hard real-time tasks and optimizing the response time of soft real-time tasks in CGRA as described in this invention;

[0036] Figure 2 This is a diagram illustrating continuous capture.

[0037] Figure 3 A comparison chart of response times for 8 hard real-time tasks;

[0038] Figure 4 A comparison chart of response times for 8 software real-time tasks. Detailed Implementation

[0039] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0040] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0041] Many specific details are set forth in the following description in order to provide a full understanding of this application. However, this application may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of this application. Therefore, this application is not limited to the specific embodiments disclosed below.

[0042] Implementation Method 1

[0043] This implementation proposes a method for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA. By establishing a preemptive delay model and achieving adaptive resource sharing, it maximizes the use of idle resources and significantly shortens the response time of soft real-time tasks, thereby improving CGRA resource utilization and real-time task scheduling performance, while ensuring that all hard real-time tasks strictly meet their deadlines.

[0044] like Figure 1 As shown, this method consists of three steps. First, CGRA resources are statically allocated to different hard real-time tasks. Then, through mechanism analysis, an algebraic equation is derived to define the worst-case continuous preemption latency based on the resource allocation of each task. Finally, response time analysis is used to determine whether the hard real-time tasks can still meet their deadlines even under the worst-case continuous preemption. Specifically, the method includes:

[0045] S1. For multiple hard real-time tasks to be scheduled, calculate the minimum CGRA resource amount required for each hard real-time task to meet its deadline, and complete the CGRA mapping verification; sort all hard real-time tasks in descending order according to the leniency; allocate physical PE positions to each hard real-time task in order of the sorting results, with the allocation starting from the PE closest to the controller.

[0046] This step calculates the minimum CGRA resource amount required for a hard real-time task to meet its deadline based on a manually set resource partitioning granularity (e.g., 1x4 CGRA PEs), and verifies this through CGRA mapping. Subsequently, tasks are arranged in descending order of leniency and assigned physical PE locations sequentially, starting with the processing unit (PE) closest to the controller. Here, leniency = deadline / execution time.

[0047] This prioritization is based on two interrelated considerations. First, tasks with lower preemption tolerance are more likely to miss their deadlines under consecutive preemption, and therefore are often marked as unshareable in subsequent adaptive resource sharing marking steps. Second, the upper bound of consecutive preemption latency increases with the distance to the furthest assigned PE. Therefore, assigning tasks with lower preemption tolerance to more distant PEs reduces this upper bound when they are marked as unshareable, thereby increasing the likelihood that other tasks will meet their deadlines.

[0048] After this step, each hard real-time task is assigned a fixed set of CGRA resources, which can be used directly or preempted when the task is launched.

[0049] S2. Establish a CGRA preemption delay model based on the preset NoC deterministic service constraints; through the preemption delay model, calculate the transmission delay and total preemption delay of a single preemption when the PE position of a hard real-time task is shared, further calculate the upper bound of the merged preemption delay in the scenario where multiple hard real-time tasks continuously initiate preemption, and finally obtain the upper bound of the continuous preemption delay of hard real-time tasks.

[0050] If a hard real-time task's statically allocated resources are shared by a soft real-time task, then the hard real-time task must preempt these resources upon deployment. The CGRA preemption mechanism is typically initiated by the controller and involves three steps:

[0051] a. The controller sends the CMD_RECORD command through the on-chip network (NoC); after the preempted PE receives the command, it records the context of the soft real-time task currently being executed on it.

[0052] b. The controller sends the CMD_CLEAR command; upon receiving it, the preempted PE clears its own state and switches its memory access address range to the address range used by the hard real-time task.

[0053] c. The controller sends the CMD_LAUNCH command; upon receiving it, the preempted PE begins executing the hard real-time task.

[0054] The above three steps must be executed sequentially; otherwise, the context cannot be recorded correctly, or the hard real-time task cannot be executed correctly.

[0055] It can be seen that the transmission delay of commands on the NoC is the main overhead of CGRA preemption. To obtain accurate preemption delay, command transmission must have deterministic delay; therefore, the NoC of CGRA satisfies the following deterministic service constraint:

[0056] The controller is the sole source for NoC command injection, and command propagation uses unicast and deterministic routing.

[0057] The controller's command injection rate does not exceed the forwarding rate of the router in the NoC, thus enabling the network to provide non-blocking pipelined forwarding of commands.

[0058] Under these constraints, the number of clock cycles for transmitting a command The order in which commands are issued and the number of hops (i.e., the number of routers) required for the command to reach the preempted PE in a given network topology are determined solely by the order in which the commands are issued. To minimize... Commands for each PE should be issued in descending order of hop count. It is given by the following formula:

[0059] , (1)

[0060] in, The number of PEs statically allocated to the current hard real-time task; The number of hops required for the controller to send a command to the preempted PE; The number of clock cycles required per hop depends on the router's microarchitecture; The number of flits per command depends on the command length and the on-chip network bit width;

[0061] Therefore, the number of cycles required for PE processing commands. The number of clock cycles for each step is:

[0062] , (2)

[0063] Therefore, the total preemption latency of a single hard real-time task is the sum of three steps:

[0064] (3)

[0065] in, The number of clock cycles required for the PE to process CMD_RECORD. The number of clock cycles required for the PE to process CMD_CLEAR. The number of clock cycles required for the PE to process CMD_LAUNCH, all three depend on the PE microarchitecture.

[0066] When one hard real-time task is being preempted, other hard real-time tasks may successively issue preemption requests. For example... Figure 2 As shown, while Task 1 is being preempted, Tasks 2 and 3 may send requests sequentially, but the controller is busy processing Task 1. The controller must wait for Task 1 to complete its preemption, then merge the requests from Tasks 2 and 3 before proceeding with the next preemption. Let... A collection of hard real-time tasks. Let be the set of PEs statically allocated to these tasks. Then the upper bound of the merged preemption delay is:

[0067] (4)

[0068] It can be seen that the merged preemption latency is not a linear sum of the individual preemption latencies of each task, because... The transmission process of commands sent by different PEs overlaps.

[0069] Therefore, the upper bound of the continuous preemption latency for a set of hard real-time tasks This is equal to the upper bound of the previous preemption delay (which may be single or merged), plus the upper bound of the merged preemption delay that includes the task itself:

[0070] , (5)

[0071] In summary, given a set of hard real-time tasks, static resource allocation, and NoC architecture, the exact calculation can be performed. .

[0072] S3. Initially mark the PE positions of all hard real-time tasks as shareable; based on the continuous preemption delay upper bound, calculate the worst-case execution time of each hard real-time task in the shareable state, and verify whether all hard real-time tasks in the shareable state meet the deadline requirements in combination with the response time. If there are hard real-time tasks that do not meet the deadline requirements, mark the PE position of the last hard real-time task in the sorting result as non-shareable, and repeat the worst-case execution time calculation and deadline verification steps until all hard real-time tasks in the shareable state meet the deadline requirements.

[0073] This step combines response time analysis and utilizes... This determines whether resources statically allocated to each hard real-time task can be shared by soft real-time tasks. Specifically:

[0074] S3.1: Mark the statically allocated resources of all hard real-time tasks sorted in S1 as shareable. Perform computation based on the marked statically allocated resources of the hard real-time tasks.

[0075] S3.2: For any hard real-time task whose resource is marked as shareable. Its worst-case execution time (WCET) is calculated as the sum of the upper bound of the consecutive preemption delay and its own execution time:

[0076] , (6)

[0077] in, and These are hard real-time tasks. The startup interval and critical path length after mapping is completed under its statically allocated resources. This is the number of iterations for the task.

[0078] S3.3: Verify whether the hard real-time task with all resources that can be shared satisfies the requirement. If the condition is not met, mark the last task in the sort as non-shareable and repeat step S3.2; otherwise, terminate the marking process.

[0079] During system operation, shareable resources can be used by soft real-time tasks, thereby shortening the response time of soft real-time tasks while ensuring that all hard real-time tasks meet their deadlines.

[0080] Implementation Method 2

[0081] This embodiment is a further illustrative example of the method for ensuring the deadline of hard real-time tasks and optimizing the response time of soft real-time tasks in CGRA as described in Embodiment 1.

[0082] TACLeBench is a widely used benchmark suite for evaluating worst-case execution time of real-time systems. This implementation selects eight hard real-time tasks from TACLeBench: deg2rad, matrix1, bitcount, countnegative, cubic, fft, complex, and rad2deg. It also selects eight soft real-time tasks: jfdctint, filterbank, fir2dim, isqrt, iir, lms, ludcmp, and minver. For each task, computationally intensive affine loops are extracted from its C++ source code, a data flow graph is generated, and then mapped onto the target CGRA architecture. The deadlines for the hard real-time tasks are based on critical path length, node execution time, and a user-defined slack (slack = deadline / execution time), generated using the TGFF tool.

[0083] Considering the complexity of the above tasks, this implementation selects two CGRA sizes: 8×8 CGRA for resource-constrained scenarios and 10×10 CGRA for resource-sufficient scenarios. Each PE in the leftmost and rightmost columns has an independent 2KB storage block. The data NoC between PEs adopts a KingMesh topology, while the configuration NoC between the controller and PEs adopts a Ring topology. and PE is a scalar, isomorphic interface that supports arithmetic operations, memory access, and logical operations. CGRA operates at a frequency of 400MHz.

[0084] First, static scheduling is performed for the eight hard real-time tasks. On an 8×8 CGRA, each task is allocated one or more 1×4 PE blocks based on its complexity, occupying a total of 52 PEs (13 blocks), while soft real-time tasks run on the remaining 12 PEs. On a 10×10 CGRA, each task uses one or more 1×5 blocks, occupying a total of 55 PEs (11 blocks), while soft tasks run on the remaining 45 PEs.

[0085] The scheduler issues 8 soft tasks simultaneously in cycle 0. In Static-NoShare mode, soft tasks cannot share any resources statically allocated for hard tasks, thus limiting them to 12 or 45 PEs, thereby restricting parallelism. In Static-AllShare mode, soft tasks occupy all remaining PEs and can further share resources of hard tasks to improve parallelism. The method described in this invention determines which portion of the hard resources can be shared based on an adaptive strategy using a preemptive latency model.

[0086] To simulate worst-case continuous preemption, the scheduler simultaneously issues eight hard tasks in cycle 1000, preempting their statically allocated resources. The evaluation assesses whether these three methods can meet the deadlines of all hard tasks under continuous preemption while effectively reducing the response time of soft tasks.

[0087] like Figure 3 As shown, static non-sharing guarantees that all hard real-time tasks meet their deadlines because it conservatively prohibits resource sharing. However, Figure 4 The results show that, due to the limitation of parallelism, the response time of soft tasks is the longest under this method: 35,346 ns on 8×8 CGRA and 7,380 ns on 10×10 CGRA.

[0088] Static full sharing aggressively shares all resources. It achieves the shortest soft task response time. Figure 4 The latency was 7,816 ns and 5,205 ns respectively, but due to continuous preemption delays, a large number of hard tasks missed their deadlines. Figure 3 As shown, on 8×8 and 10×10 CGRA, when the relaxation (relaxation = deadline / execution time) is 1.25 and 1.5, static full sharing results in 5, 3, 5 and 5 missed deadlines, respectively, which is unacceptable in practical applications.

[0089] like Figure 3 As shown, this invention completely disables sharing to protect hard tasks when the relaxation is 1.25, but allows soft tasks to share the statically allocated resources of the four hard tasks when the relaxation is 1.5. This adaptive resource sharing based on a preemptive latency model ensures that all hard tasks on the 8×8 CGRA meet their deadlines, while effectively reducing the response time of soft tasks to 9,082 ns, a 74.3% reduction compared to static non-sharing. Figure 4 As shown in (a). On a 10×10 CGRA, soft tasks already have sufficient resources, so the benefits of sharing are limited, but this invention still achieves a 20.8% reduction ( Figure 4(b) decreased from 7,380 ns to 5,843 ns.

[0090] It is understood that the present invention has been described through some embodiments, and those skilled in the art will recognize that various changes or equivalent substitutions can be made to these features and embodiments without departing from the spirit and scope of the invention. Furthermore, under the teachings of the present invention, these features and embodiments can be modified to adapt to specific situations and materials without departing from the spirit and scope of the invention. Therefore, the present invention is not limited to the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of this application are within the protection scope of the present invention.

Claims

1. A method for ensuring deadlines for hard real-time tasks and optimizing response time for soft real-time tasks in CGRA, characterized in that, Includes the following steps: S1. For multiple hard real-time tasks to be scheduled, calculate the minimum CGRA resource amount required for each hard real-time task to meet its deadline, and complete the CGRA mapping verification; sort all hard real-time tasks in descending order according to the leniency; allocate physical PE positions to each hard real-time task in order of the sorting results, with the allocation starting from the PE closest to the controller. S2. Establish a CGRA preemption delay model based on the preset NoC deterministic service constraints; through the preemption delay model, calculate the transmission delay and total preemption delay of a single preemption when the PE position of a hard real-time task is shared, further calculate the upper bound of the merged preemption delay in the scenario where multiple hard real-time tasks continuously initiate preemption, and finally obtain the upper bound of the continuous preemption delay of hard real-time tasks. S3. Initially mark the PE positions of all hard real-time tasks as shareable; based on the continuous preemption delay upper bound, calculate the worst-case execution time of each hard real-time task in the shareable state, and verify whether all hard real-time tasks in the shareable state meet the deadline requirements in combination with the response time. If there are hard real-time tasks that do not meet the deadline requirements, mark the PE position of the last hard real-time task in the sorting result as non-shareable, and repeat the worst-case execution time calculation and deadline verification steps until all hard real-time tasks in the shareable state meet the deadline requirements.

2. The method for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA according to claim 1, characterized in that, The leniency is the ratio of the deadline to the execution time of a hard real-time task.

3. The method for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA according to claim 1, characterized in that, In S2, the NoC deterministic service constraints include: The controller is the sole source for NoC command injection, and command propagation uses unicast and deterministic routing. The controller's command injection rate shall not exceed the forwarding rate of the router in the NoC.

4. The method for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA according to claim 3, characterized in that, In S2, during a single preemption process, the number of transmission clock cycles for a single command is calculated using the following formula: ， in, The number of PEs statically allocated to the current hard real-time task; The number of hops required for the controller to send a command to the i-th preempted PE; The number of clock cycles required per hop; The number of chips per command.

5. The method for ensuring deadlines for hard real-time tasks and optimizing response time for soft real-time tasks in CGRA according to claim 4, characterized in that, In step S2, a single preemption includes: context recording, state clearing, and task execution, with each step consisting of: ， in, The number of cycles required to process commands for PE.

6. The method for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA according to claim 1, characterized in that, In S3, the worst-case execution time of a hard real-time task with shareable state is the sum of the execution time of the hard real-time task at its PE position and the upper bound of the continuous preemption delay.

7. The method for ensuring deadlines for hard real-time tasks and optimizing response times for soft real-time tasks in CGRA according to claim 1, characterized in that, During system runtime, soft real-time tasks use PE resources marked as shareable.

8. A system for ensuring deadlines for hard real-time tasks and optimizing response time for soft real-time tasks in CGRA, characterized in that, The system is implemented based on a method for ensuring the deadline of hard real-time tasks and optimizing the response time of soft real-time tasks in CGRA as described in any one of claims 1-7. The system includes: Static resource partitioning module: For multiple hard real-time tasks to be scheduled, it calculates the minimum CGRA resource amount required for each hard real-time task to meet its deadline and completes CGRA mapping verification; it sorts all hard real-time tasks in descending order according to the leniency; and it allocates physical PE positions to each hard real-time task in order of the sorting results, with the allocation starting from the PE closest to the controller. The continuous preemption delay upper bound calculation module is used to establish a CGRA preemption delay model based on the preset NoC deterministic service constraints. Through the preemption delay model, the transmission delay and total preemption delay of a single preemption when the PE position of a hard real-time task is shared are calculated. The module further calculates the combined preemption delay upper bound in the scenario where multiple hard real-time tasks continuously initiate preemption, and finally obtains the continuous preemption delay upper bound of the hard real-time task. Resource sharing marking module: used to initially mark the PE position of all hard real-time tasks as shareable; based on the continuous preemption delay upper bound, calculate the worst-case execution time of each hard real-time task in the shareable state, and verify whether all hard real-time tasks in the shareable state meet the deadline requirements in combination with the response time. If there are hard real-time tasks that do not meet the deadline requirements, mark the PE position of the hard real-time task at the end of the sorting result as non-shareable, and repeat the worst-case execution time calculation and deadline verification steps until all hard real-time tasks in the shareable state meet the deadline requirements.

9. A computer device, characterized in that, The computer device includes a memory and a processor. The memory stores a computer program. When the processor runs the computer program stored in the memory, the processor executes a method for ensuring the deadline of hard real-time tasks and optimizing the response time of soft real-time tasks in CGRA according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that executes a method for ensuring the deadline of hard real-time tasks and optimizing the response time of soft real-time tasks in CGRA according to any one of claims 1-7.

Images