CN107832255A - The optimization method of dynamic requests reconfigurable core during a kind of operation - Google Patents

Abstract

The present invention discloses an optimization method for dynamically requesting a reconfigurable core during operation, comprising steps: S1, configuring a general reconfigurable core: configuring the general reconfigurable core on an FPGA; S2, dividing a reconfigurable task: Divide the reconfigurable task into reconfigurable subsystem and software subsystem. R is composed of m hardware modules, m≥1; the software subsystem is a part that must be executed by software, denoted as S, and the software subsystem S is composed of n software modules, n≥2; S3, on a general-purpose processor Execute reconfigurable tasks: schedule reconfigurable tasks to be executed on general-purpose processors, execute the first software module of reconfigurable tasks; S4, dynamically request reconfigurable cores during runtime: execute software modules of reconfigurable tasks , dynamically request reconfigurable cores. The invention can realize the optimal use of reconfigurable cores and improve the efficiency of reconfigurable task execution.

Description

An Optimization Method for Dynamically Requesting Reconfigurable Cores at Runtime

technical field

The invention relates to an optimization method for dynamically requesting a reconfigurable core during operation, and belongs to the technical field of reconfigurability.

Background technique

Reconfigurable computing is regarded as an effective solution that can combine the high flexibility of traditional processors with the high processing efficiency of ASIC (Application Specific Integrated Circuit). Due to the good adaptability of the reconfigurable architecture, the processing speed can be accelerated through different granularities of parallelism for different applications. Among reconfigurable devices, FPGA (Field-Programmable Gate Array) is the most widely used reconfigurable device. Dynamically rechargeable and configurable FPGA is an important basis for realizing hardware-level multitasking.

The scheduling management of reconfigurable hardware tasks needs to make optimal decisions on which tasks use hardware when and how many reconfigurable resources are allocated to each task. These decisions can be made at compile time based on static program information, at runtime based on the dynamic state of the system, or based on a combination of the two. The optimization goal of scheduling can be to maximize the performance of a single application or the overall system, minimize energy consumption, or meet the deadline of real-time tasks, etc. In addition, it also needs to consider reducing and scheduling and reconfiguration overhead.

Static scheduling relies on the analysis, profiling, and marking of program behavior to determine when a hardware task needs to be allocated. Through these analysis, profiling and marking, static scheduling can obtain more global task requirements and other information. Moreover, the static scheduler generally works offline, and some scheduling is even performed at compile time, so there is almost no need to consider the overhead of scheduling itself. Therefore, some scheduling algorithms with high complexity can be used for static scheduling, such as genetic algorithm.

Since static scheduling can grasp the global information of the program, the time required for a specific hardware task can be known according to the application flow graph (Application Flow Graph) obtained by static analysis, and then the prefetch instruction of the hardware task can be inserted. By overlapping the hardware configuration and other Task execution to hide the overhead of reconfiguration.

Generally speaking, static scheduling can achieve more optimal results, but its disadvantages are also obvious. In order to ensure the effectiveness of scheduling, static scheduling requires task sets (including arrival time, execution time, and task resource requirements) and resource availability must be predictable of. However, since the running state of the program and the system cannot be known, once the result of static prediction is wrong, the result of static scheduling will not only fail to achieve good performance, but will bring serious negative impact, and prefetching may also lead to additional reconfiguration cost.

Dynamic scheduling, also called runtime scheduling or online scheduling, makes scheduling decisions online based on system runtime information. Runtime information includes current system load, resource utilization status, task frequency and task performance in the previous stage, etc. Dynamic scheduling usually requires fast scheduling decisions to reduce system scheduling overhead, so the scheduling results may not be optimal.

Some dynamic scheduling methods determine which hardware tasks should be configured and executed according to the data flow graph (Dataflow Graph). In this method, only when all predecessor nodes of a node in the data flow graph have been executed, the node It is possible to be scheduled for execution. Other dynamic scheduling algorithms do not consider the flow graph of the program, but divide the time into "windows", take the window as an interval, and periodically execute the scheduling algorithm according to the system runtime state, and select the tasks that need to be configured and executed for the next window [127 , 150-151]. The main difference between these two methods is: the former makes scheduling decisions when tasks arrive, and the scheduling overhead is positively correlated with the number of task arrivals; while the latter makes scheduling decisions at intervals of "windows", and the scheduling overhead is fixed; the former schedules in a timely manner. , which is conducive to performance optimization, while the latter is beneficial to the control of scheduling overhead; but the former is only applicable to the scheduling scenarios of hardware tasks that are dependent on each other, while the latter is applicable to all scenarios.

The overhead of the dynamic scheduling algorithm directly affects the performance of the system and is one of the important factors to be considered. Some studies use traditional dynamic scheduling methods, such as First Come First Serve (FCFS), Shortest Task First (SJF), Shortest Remaining Processing Time First (SRPT), Recently Most Frequently Used First (MRU), Maximum Speed Up First (HS ) and Earliest Deadline First (EDF), etc. These traditional scheduling methods have simple algorithms, fast running speed, and low overhead. However, because hardware tasks are different from traditional software tasks on general-purpose processors, the performance benefits brought by hardware tasks and the required reconfigurable resources vary from task to task. And task loading/switching (reconfiguration) costs are high, so these simple scheduling algorithms may not be able to obtain better scheduling results.

Therefore, some dynamic scheduling adopts a more complex priority-based method. The priority comprehensively considers factors such as reconfigurable resources required by the task, performance improvement, execution time, current resource configuration status, and even execution frequency.

In order to provide more program information to the scheduling algorithm, and reduce runtime scheduling overhead, make more efficient scheduling decisions. Some studies use a hybrid scheduling approach that combines design-time and run-time. Resano et al.'s research adopts a hybrid scheduling method that combines design time and runtime, and completes the computationally intensive part of the scheduling algorithm at design time, while dealing with non-deterministic dynamic behavior with less overhead at runtime. Based on TCM, they proposed a hybrid scheduling method for reconfigurable multi-tasks, which generates a feasible approximate optimal scheduling sequence set for each task at design time; selects from the scheduling sequence set for each task according to dynamic information at runtime. A best fit schedule. However, in the case of a large number of tasks and many different situations, the cost of generating all feasible approximately optimal scheduling sequences is very high. Therefore, they proposed an improved heuristic hybrid scheduling method. The identification of subtasks on the critical path is completed in the design stage. The scheduling result will be used as the scheduling input in the running phase; and when the runtime resources are not enough to configure all the key subtasks, the runtime scheduling only needs to reconfigure the subtasks according to the loading order calculated at design time to ensure that the key subtasks are in the Already configured when execution starts.

Generally speaking, under the premise that all task information is known, static scheduling can provide the most efficient results, but in the case of uncertain tasks and resources, the real task sequence and dynamic resource status can only be determined at runtime, so Static scheduling does not apply in this case. Although dynamic scheduling can make scheduling decisions online based on system runtime information, its overhead is too high, and hybrid scheduling can usually achieve a better compromise between performance and overhead.

Contents of the invention

In order to overcome the shortcomings of the above technologies, the present invention provides an optimization method for dynamically requesting reconfigurable cores during runtime.

The technical scheme that the present invention overcomes its technical problem adopts is:

An optimization method for dynamically requesting a reconfigurable core during runtime, comprising the following steps:

S1. Configure a general reconfigurable core

Configure the general-purpose reconfigurable core on the FPGA;

S2. Segment reconfigurable tasks

Divide the reconfigurable task into two parts: the reconfigurable subsystem and the software subsystem: the reconfigurable subsystem is a part that can be constructed as a reconfigurable core and executed by hardware, denoted as R, and the reconfigurable The subsystem R is composed of m hardware modules, wherein m≥1; the software subsystem is a part that must be executed by software, denoted as S, and the software subsystem S is composed of n software modules, wherein n≥1;

S3, Execute reconfigurable tasks on general-purpose processors

Scheduling the reconfigurable task to the general-purpose processor to execute the first software module of the reconfigurable task;

S4. Dynamically request reconfigurable cores at runtime

When the software module of the reconfigurable task is executed, the reconfigurable core is dynamically requested.

Preferably in the present invention, in the step S1, the general reconfigurable core refers to a reconfigurable core that completes general computing tasks and can be used by different reconfigurable tasks; the general reconfigurable core is composed of The implementation of the flow file corresponding to the construction core, configuring the general reconfigurable core on the FPGA is to program the corresponding flow file to the FPGA.

Preferably in the present invention, in the step S2, the reconfigurable subsystem R={RH1, RH2, ..., RHm}, any module RHi in R can be separately constructed as a reconfigurable core module, and the module RHi is also It can be realized by software, and the module RHi implemented by software is denoted as S(RHi), where 1≤i≤m; the software subsystem S={SS1, SS2,...,SSn}, any module SSj in S can and Can only be executed by software, where 1≤j≤n; for any reconfigurable task, the first executed module in the reconfigurable task execution sequence is a software module.

Preferably in the present invention, in the step S2,

Each hardware module includes the following attributes: 1) The configuration time WCRT of the reconfigurable core indicates the time required for this hardware module to be reconfigured into hardware on the FPGA; 2) The execution time WCET1 of the reconfigurable core indicates the execution time The maximum time required for the task to be completed by this hardware module; 3) The software execution time WCST indicates the maximum time required for the software corresponding to this hardware module to implement the task required to be completed by this hardware module;

Each software module includes the following attributes: The execution time WCET2 of the software module indicates the maximum time required by the software module to complete the task.

Preferably in the present invention, for any reconfigurable core RHi, if WCRT (RHi) + WCET1 (RHi) > WCST (RHi), S (RHi) is preferred to complete the calculation task during execution; if WCRT (RHi) + WCET1 (RHi) ≤ WCST (RHi), RHi is given priority to complete computing tasks during execution.

Preferably in the present invention, in the step S4, the dynamic request to the reconfigurable core includes two types:

The first category, requests for general reconfigurable cores;

The second category is a request for a reconfigurable core corresponding to a hardware module.

Further, in the first category, for the request for the general reconfigurable core, if the general reconfigurable core is available, the general reconfigurable core is used to complete the calculation; if the general reconfigurable core is not available, then:

1) If there is enough FPGA space, calculate the waiting time WT = WCRT of the general reconfigurable core + WCET1 of the general reconfigurable core; if WT > WCST of the general reconfigurable core, use the corresponding software of the general reconfigurable core The module completes the calculation task; if WT≤WCST of the general reconfigurable core, reconfigure a general reconfigurable core on the FPGA and use the general reconfigurable core to complete the calculation task;

2) If there is not enough FPGA space, use the software module corresponding to the general reconfigurable core to complete the computing task.

Further, in the second category, the request for the reconfigurable core corresponding to the hardware module,

1) If the reconfigurable core corresponding to the hardware module has been configured on the FPGA and is available, use the corresponding reconfigurable core to complete the corresponding computing task;

2) If the reconfigurable core corresponding to the hardware module has been configured on the FPGA but is unavailable, calculate: waiting time WT=WCET1*2 of the reconfigurable core, then:

a) If WT > WCST of the reconfigurable core, use the software module corresponding to the reconfigurable core to complete the computing task;

b) If WT≤WCST of the reconfigurable core, wait for the reconfigurable core to complete the current computing task, and then use the reconfigurable core to complete the computing task;

3) If the reconfigurable core corresponding to the hardware module is not configured in the FPGA, then:

a) If there is not enough FPGA space, use the software module corresponding to the reconfigurable core to complete the computing task;

b) If there is enough FPGA space, calculate the waiting time WT = WCRT of the reconfigurable core + WCET1 of the reconfigurable core, then:

i) If WT>WCST of the reconfigurable core, use the software module corresponding to the reconfigurable core to complete the computing task;

ii) If WT ≤ WCST of the reconfigurable core, configure the reconfigurable core to the FPGA to complete the computing task.

The beneficial effects of the present invention are:

The invention separates the hardware modules in the reconfigurable task, and establishes a dynamic request method for the execution of the reconfigurable task. Regardless of whether it is a general-purpose reconfigurable core or a reconfigurable core, the available or configurable conditions are dynamically judged at runtime, so that the optimized use of the reconfigurable core can be realized, and the efficiency of reconfigurable task execution can be improved. Its main features are as follows:

(1) Efficiency: When traditional reconfigurable tasks are executed, the part using the reconfigurable core will be directly configured on the FPGA and executed at runtime, and there is a lot of waiting time; and the present invention is based on runtime The situation can be dynamically arranged, so that the execution of reconfigurable tasks can be completed more efficiently.

(2) Flexibility: Traditional reconfigurable task execution often completely limits the execution of hardware modules to use reconfigurable cores, which makes the execution of reconfigurable tasks depend on the availability of reconfigurable cores and FPGA space available conditions, etc.; while the present invention provides a software module execution solution, which is flexibly arranged according to the runtime state, so as to realize the flexibility of reconfigurable task execution.

Description of drawings

FIG. 1 is a schematic diagram of the implementation flow of this embodiment.

FIG. 2 is a schematic diagram of reconfigurable task segmentation in this embodiment.

FIG. 3 is a schematic diagram of specific segmentation of the reconfigurable task P in this embodiment.

Detailed ways

In order to facilitate those skilled in the art to better understand the present invention, the present invention will be described in further detail below in conjunction with the accompanying drawings and specific embodiments. The following is only exemplary and does not limit the protection scope of the present invention.

An optimization method for dynamically requesting a reconfigurable core at runtime according to the present invention, as shown in Figure 1, includes the following steps:

S1. Configure a general reconfigurable core

Configure the general-purpose reconfigurable core on the FPGA. The general-purpose reconfigurable core refers to the reconfigurable core that completes the general-purpose computing task and can be used by different reconfigurable tasks; the general-purpose reconfigurable core is composed of the general-purpose The implementation of the flow file corresponding to the reconfigurable core, configuring the general reconfigurable core on the FPGA is to program the corresponding flow file to the FPGA. Each general reconfigurable core has a corresponding software module to realize the function completed by this general reconfigurable core. If the general reconfigurable core is not available, the corresponding software module can be used to complete the corresponding function.

For the general reconfigurable core SP1 and the general reconfigurable core SP2, SP1 realizes the function of fast Fourier transform, and SP2 realizes the function of array transformation, both of which are commonly used computing functions. SP1 is realized by the stream file File (SP1) corresponding to SP1, and SP2 is realized by the stream file File (SP2) corresponding to SP2. Program the stream file File (SP1) and stream file (SP2) to the FPGA, and the software modules corresponding to SP1 and SP2 are S (SP1) and S (SP2) respectively.

S2. Segment reconfigurable tasks

Divide the reconfigurable task into two parts: the reconfigurable subsystem and the software subsystem: the reconfigurable subsystem is a part that can be constructed as a reconfigurable core and executed by hardware, denoted as R, and the reconfigurable The subsystem R is composed of m hardware modules, where m≥1, the reconfigurable subsystem R={RH1, RH2,...,RHm}, any module RHi in R can be separately constructed as a reconfigurable core module, At the same time, the module RHi can also be realized by software, and the module RHi realized by software is denoted as S(RHi), where 1≤i≤m. The software subsystem is a part that must be executed by software, denoted as S, and the software subsystem S is composed of n software modules, wherein n≥1, the software subsystem S={SS1, SS2, ..., SSn}, S Any module SSj in can and can only be executed by software, where 1≤j≤n. For any reconfigurable task, the first executed module in the reconfigurable task execution sequence is a software module.

As shown in Figure 2, the left side of Figure 2 is a complete reconfigurable task execution sequence. After segmentation, it is divided into 4 software modules for software execution and 3 hardware modules for hardware execution, as shown in Figure 2 shown on the right. The 4 software modules executed by software constitute the software subsystem of the reconfigurable task, and the 3 hardware modules capable of hardware execution constitute the reconfigurable subsystem of the reconfigurable task. "Hardware-executable" in hardware-executable hardware modules means that the module can be constructed as a reconfigurable core on the FPGA, executed by hardware, or directly executed by software.

Each hardware module described in this embodiment includes the following attributes:

1) The configuration time WCRT of the reconfigurable core indicates the time required for this hardware module to be reconfigured into hardware on the FPGA;

2) The execution time WCET1 of the reconfigurable core indicates the maximum time required to execute the tasks required by this hardware module;

3) The software execution time WCST indicates the maximum time required by the software corresponding to the hardware module to execute the tasks required by the hardware module;

For any reconfigurable core RHi, if WCRT (RHi) + WCET1 (RHi) > WCST (RHi), S (RHi) is preferred to complete the computing task during execution; if WCRT (RHi) + WCET1 (RHi) ≤ WCST (RHi), it is preferred to use RHi to complete computing tasks during execution.

Each software module includes the following attributes: The execution time WCET2 of the software module indicates the maximum time required by the software module to complete the task.

Specifically, for a reconfigurable task P, split p into two parts, which are divided into four software modules that can be executed by software and three hardware modules that can be executed by hardware. As shown in Figure 3, after splitting, the Reconfigurable subsystem R _p and software subsystem S _p are respectively:

_Rp = {RH1, RH2, RH3}

S _p = {SS1, SS2, SS3, SS4}

Among them, for the hardware modules RH1, RH2 and RH3, respectively:

1) WCRT (RH1) = rt1, WCET1 (RH1) = et1, WCST (RH1) = st1

2) WCRT (RH2) = rt2, WCET1 (RH2) = et2, WCST (RH2) = st2

3) WCRT (RH3) = rt3, WCET1 (RH3) = et3, WCST (RH3) = st3

Among them, for the software modules SS1, SS2 and SS3, there are respectively:

WCET2(SS1)=dt1

WCET2 (SS2) = dt2

WCET2 (SS3) = dt3

WCET2 (SS4) = dt4

S3, Execute reconfigurable tasks on general-purpose processors

Scheduling the reconfigurable task to the general-purpose processor to execute the first software module of the reconfigurable task;

Specifically, for the reconfigurable task P, if P is scheduled to be executed on a general-purpose processor, then the first software module SS1 of P is executed on the general-purpose processor.

S4. Dynamically request reconfigurable cores at runtime

When the software module of the reconfigurable task is executed, the reconfigurable core is dynamically requested.

In this embodiment, dynamic requests to the reconfigurable core include two types:

The first category, requests for general reconfigurable cores;

The second category is a request for a reconfigurable core corresponding to a hardware module.

Further, in the first category, for the request for the general reconfigurable core, if the general reconfigurable core is available, the general reconfigurable core is used to complete the calculation; if the general reconfigurable core is not available, then:

1) If there is enough FPGA space, calculate the waiting time WT = WCRT of the general reconfigurable core + WCET1 of the general reconfigurable core; if WT > WCST of the general reconfigurable core, use the corresponding software of the general reconfigurable core The module completes the calculation task; if WT≤WCST of the general reconfigurable core, reconfigure a general reconfigurable core on the FPGA and use the general reconfigurable core to complete the calculation task;

2) If there is not enough FPGA space, use the software module corresponding to the general reconfigurable core to complete the computing task.

In the second category, the request for the reconfigurable core corresponding to the hardware module,

1) If the reconfigurable core corresponding to the hardware module has been configured on the FPGA and is available, use the corresponding reconfigurable core to complete the corresponding computing task;

2) If the reconfigurable core corresponding to the hardware module has been configured on the FPGA but is unavailable, calculate: waiting time WT=WCET1*2 of the reconfigurable core, then:

a) If WT > WCST of the reconfigurable core, use the software module corresponding to the reconfigurable core to complete the computing task;

b) If WT≤WCST of the reconfigurable core, wait for the reconfigurable core to complete the current computing task, and then use the reconfigurable core to complete the computing task;

3) If the reconfigurable core corresponding to the hardware module is not configured in the FPGA, then:

a) If there is not enough FPGA space, use the software module corresponding to the reconfigurable core to complete the computing task;

b) If there is enough FPGA space, calculate the waiting time WT = WCRT of the reconfigurable core + WCET1 of the reconfigurable core, then:

i) If WT>WCST of the reconfigurable core, use the software module corresponding to the reconfigurable core to complete the computing task;

ii) If WT ≤ WCST of the reconfigurable core, configure the reconfigurable core to the FPGA to complete the computing task.

The above only describes the basic principle and preferred implementation of the present invention, and those skilled in the art can make many changes and improvements according to the above description, and these changes and improvements should belong to the protection scope of the present invention.

Claims (8)

1. the optimization method of dynamic requests reconfigurable core during a kind of operation, it is characterised in that as follows including step：

S1, the general reconfigurable core of configuration

General reconfigurable core is configured on FPGA；

S2, cutting reconfigurable task

It is restructural subsystem and software subsystem two parts by reconfigurable task cutting：The restructural subsystem is to build The part performed for reconfigurable core, by hardware, is designated as R, if restructural subsystem R is made up of m hardware module, wherein m >=1； The software subsystem is the part that must be performed by software, is designated as S, if software subsystem S is made up of n software module, its Middle n >=1；

S3, reconfigurable task is performed on aageneral-purposeaprocessor

Reconfigurable task is dispatched on general processor and performed, performs the first software module of reconfigurable task；

Dynamic requests reconfigurable core when S4, operation

When the software module of reconfigurable task performs, dynamic requests reconfigurable core.

2. optimization method according to claim 1, it is characterised in that in the step S1, general reconfigurable core has referred to Into the reconfigurable core of versatility calculating task, can be used by different reconfigurable tasks；General reconfigurable core is by general with this Stream file corresponding to reconfigurable core is realized, general reconfigurable core is configured on FPGA, exactly arrived corresponding stream file programming On FPGA.

3. optimization method according to claim 1, it is characterised in that in the step S2, restructural subsystem R=RH1, RH2 ..., RHm }, any one module RHi in R can individually be configured to the module of reconfigurable core, while module RHi also may be used To be realized using software, the module RHi realized with software is designated as S（RHi）, wherein 1≤i≤m；Software subsystem S=SS1, SS2 ..., SSn }, any one module SSj in S can and can only be performed by software, wherein 1≤j≤n；For any restructural Task, the module of first execution in reconfigurable task Perform sequence is software module.

4. optimization method according to claim 3, it is characterised in that in the step S2,

Each hardware module is included with properties：1）The setup time WCRT of reconfigurable core, represent that this hardware module exists The time being reconstructed on FPGA required for hardware；2）The execution time WCET1 of reconfigurable core, represent to perform this hardware module institute The maximum time that the required by task that need to be completed is wanted；3）Software performs time WCST, represents the software corresponding to this hardware module Realize and perform the maximum time that the required by task completed needed for this hardware module is wanted；

Each software module includes following attribute：The execution time WCET2 of software module, represent that this software module completes task Required maximum time.

5. optimization method according to claim 4, it is characterised in that for any one reconfigurable core RHi, if WCRT （RHi）+WCET1（RHi）＞ WCST（RHi）, preferentially use S upon execution（RHi）Complete calculating task；If WCRT（RHi）+ WCET1（RHi）≤WCST（RHi）, preferentially complete calculating task using RHi upon execution.

6. optimization method according to claim 1, it is characterised in that, please to the dynamic of reconfigurable core in the step S4 Ask including two classes：

The first kind, the request to general reconfigurable core；

Second class, the request to the reconfigurable core corresponding to hardware module.

7. optimization method according to claim 6, it is characterised in that in the first kind, asked to general reconfigurable core Ask, if general reconfigurable core can use, complete to calculate using general reconfigurable core；If general reconfigurable core is unavailable,：

1）If enough FPGA spaces, the general reconfigurable cores of WCRT+ of stand-by period WT=general reconfigurable core are calculated WCET1；If the WCST of the general reconfigurable cores of WT ＞, complete to calculate using software module corresponding to general reconfigurable core and appoint Business；If the WCST of WT≤general reconfigurable core, a general reconfigurable core is configured on FPGA again and uses this general Reconfigurable core completes calculating task；

2）If without enough FPGA spaces, calculating task is completed using software module corresponding to general reconfigurable core.

8. according to the optimization method described in claim 6, it is characterised in that in second class, to corresponding to hardware module can The request of core is reconstructed,

1）If the reconfigurable core corresponding to hardware module has been configured on FPGA and can use, can be weighed corresponding to use Calculating task corresponding to the completion of structure core；

2）If the reconfigurable core corresponding to hardware module has been configured on FPGA but unavailable, calculate：During wait Between WT=reconfigurable core WCET1*2, then：

a）If the WCST of WT ＞ reconfigurable cores, calculating task is completed using software module corresponding to reconfigurable core；

b）If the WCST of WT≤reconfigurable core, wait reconfigurable core to complete current calculating task, it is complete to reuse reconfigurable core Into calculating task；

3）Reconfigurable core corresponding to hardware module is configured without FPGA, then：

a）If without enough FPGA spaces, calculating task is completed using software module corresponding to reconfigurable core；

b）If enough FPGA spaces, the WCET1 of the WCRT+ reconfigurable cores of stand-by period WT=reconfigurable core is calculated, then：

ⅰ）If the WCST of WT ＞ reconfigurable cores, calculating task is completed using software module corresponding to reconfigurable core；

ⅱ）If the WCST of WT≤reconfigurable core, reconfigurable core is configured on FPGA and completes calculating task.