A hash calculation scheduling method and device supporting multiple request concurrent response

Abstract

The application provides a hash calculation scheduling method and device supporting multiple request concurrent response, comprising the following steps: S1: receiving input data, splitting and / or padding the input data to obtain data segments with a target length, each data segment corresponding to a calculation request; S2: obtaining to-be-arbitrated calculation requests in a current period; S3: determining a flow water level according to the number of the to-be-arbitrated calculation requests in the current period, distributing calculation units to the to-be-arbitrated calculation requests based on the flow water level, the to-be-arbitrated calculation requests after distribution serving as to-be-calculated requests in the current period, and performing iterative calculation in the current period; S4: if the to-be-calculated requests complete iteration, outputting a hash calculation result, or taking the hash calculation result as a calculation initial value of a corresponding to-be-arbitrated calculation request in the next period; if the to-be-calculated requests do not complete iteration, entering the next period and repeating steps S2-S4. The calculation efficiency is improved.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to a hash calculation scheduling method and apparatus that supports concurrent responses to multiple requests. Background Technology

[0002] In security algorithm applications, hash algorithms are widely used to verify data integrity during transmission due to their strong avalanche effect—meaning that even slight changes in the input data can lead to significant differences in the output hash value. To improve the efficiency of hash operations, the industry typically adopts a hardware implementation that unfolds all 64 rounds of iterative computation logic, trading hardware area for computational speed. In this architecture, the result of the first data operation is output in the 65th clock cycle, and the result of the next data operation is output in the 66th clock cycle, achieving pipelined processing.

[0003] However, this scheme has the following limitations: when the input data length exceeds the single-processing capacity, it needs to be divided into blocks and subjected to multiple hash calculations, and the result of the previous 64 iterations needs to be used as the initial value for the next 64 iterations; if other pending data enters the pipeline simultaneously, it will cause hardware resource conflicts. Similarly, when multiple functional modules initiate hash calculation requests simultaneously, resource contention will occur, requiring the introduction of an arbitration mechanism; when the input data volume is too small to support the pipeline, the computing resources on the pipeline will become idle. In addition, if a calculation request that requires block division enters the pipeline before a request that does not require block division, even if the latter's calculation is completed earlier, to ensure the order of result return, it must wait for the former's entire block calculation to finish, resulting in additional waiting delays. The above problems are not essentially due to insufficient computing resources, but rather because the existing architecture lacks the ability to perform parallel scheduling and resource allocation for multiple requests, limiting the overall efficiency and resource utilization of computing resources.

[0004] To address the aforementioned issues, this invention provides a hash computation scheduling method and apparatus that supports concurrent responses to multiple requests. It can simultaneously respond to multiple computation requests, dynamically allocate computation units according to the current iteration stage of each request, and support out-of-order return of computation results, avoiding additional waiting delays caused by sequential output, thereby improving resource utilization and computation efficiency. Summary of the Invention

[0005] This invention addresses all or part of the problems in the prior art by providing a hash computation scheduling method and apparatus that supports concurrent responses to multiple requests. It arbitrates and pipelines multiple hash computation requests, enabling dynamic allocation and flexible scheduling of computation units, achieving a dynamic balance between computation speed and resource utilization. Furthermore, by introducing an identification mechanism, it supports result transfer and dependency unlocking between multiple requests with dependencies after splitting, and supports out-of-order return of computation results, avoiding additional waiting delays caused by sequential output and improving overall system computation efficiency.

[0006] This invention provides a hash computation scheduling method supporting concurrent responses to multiple requests, comprising the following steps: S1: receiving input data, splitting and / or padding the input data to obtain data segments of a target length, each data segment corresponding to a computation request; S2: obtaining the computation requests to be arbitrated in the current period; S3: determining the pipeline level based on the number of computation requests to be arbitrated in the current period, allocating computation units to each computation request to be arbitrated based on the pipeline level, and using the allocated computation requests to be arbitrated as computation requests to be computed in the current period for iterative computation in the current period; S4: if the computation request to be computed completes the iteration, outputting the hash computation result, or using the hash computation result as the initial value for the next corresponding computation request to be arbitrated; if the iteration is not completed, proceeding to the next period and repeating steps S2-S4. By performing unified arbitration and pipeline level planning for multiple hash computation requests, dynamic allocation and flexible scheduling of computation units are achieved, and computation units are rationally allocated to achieve a dynamic balance between computation speed and resource utilization; improving the overall computation efficiency of the system in multi-data scenarios.

[0007] In step S2, the process of obtaining the computation request to be arbitrated is as follows: The lock signal LOCK and the valid signal VALID of the computation request to be arbitrated are recorded; computation requests with a high valid signal VALID and a low lock signal LOCK are selected as the computation requests to be arbitrated in the current period; a low lock signal LOCK indicates that the data on which the current computation request depends has been calculated. This avoids invalid requests or requests that depend on incomplete requests from consuming computational resources and improves arbitration efficiency.

[0008] The process for determining the flow chart level is as follows: The number of requests to be arbitrated is counted as n; when n ≥ 64, a flow chart of level 64 is used; when 32 ≤ n < 64, some of the requests to be arbitrated use a flow chart of level 32, and the remaining requests use a flow chart of level 64; when 16 ≤ n < 32, some of the requests to be arbitrated use a flow chart of level 16, and the remaining requests use a flow chart of level 32 or higher; when 8 ≤ n < 16, some of the requests to be arbitrated use a flow chart of level 8, and the remaining requests use a flow chart of level 16 or higher; when 4 ≤ n < 8, some of the requests to be arbitrated use a flow chart of level 4, and the remaining requests use a flow chart of level 8 or higher; when 2 ≤ n < 4, some of the requests to be arbitrated use a flow chart of level 2, and the remaining requests use a flow chart of level 4 or higher; when n = 1, a flow chart of level 1 is used. The pipeline level is dynamically adjusted adaptively according to the changes in the number of requests, avoiding the problem of idle or over-saturated computing units caused by using a uniform pipeline level for all pending arbitration computing requests, thus ensuring the utilization rate of computing units.

[0009] The number of computing units required for each level of the pipeline is as follows: 1 computing unit for level 64, 2 computing units for level 32, 4 computing units for level 16, 8 computing units for level 8, 16 computing units for level 4, 32 computing units for level 2, and 64 computing units for level 1. This defined resource allocation ensures real-time scheduling decisions, and switching between different pipeline levels can be achieved through rerouting configuration.

[0010] The pipeline level and computing unit allocation of the computational requests to be arbitrated satisfy the following relationship: x + y = m, px + q(yz) + Σ(ri*zi) ≤ 64, where x is the number of computational requests to be arbitrated that occupy more computing units, p is the number of computing units occupied by the corresponding pipeline level; y is the number of computational requests to be arbitrated that occupy fewer computing units, q is the number of computing units occupied by the corresponding pipeline level, and y contains the number of computational requests to be arbitrated that occupy even fewer computing units; zi is the i-th request occupying fewer computing units, with a count value of 1, ri is the number of computing units occupied by the i-th higher-level pipeline, 0 ≤ i ≤ z; m is the number of computational requests to be arbitrated that obtain computing units after arbitration, m ≤ n. By incorporating pipeline level classification, the number of computing units occupied, and the number of computational requests to be arbitrated into the resource allocation considerations, and given the number of computational requests to be arbitrated, a feasible allocation scheme that meets the resource limit can be quickly obtained through the relationship.

[0011] The arbitration process is a priority-based round-robin arbitration. By introducing a priority determination mechanism, calculation units are allocated reasonably.

[0012] Requests awaiting arbitration with a remaining number of iterations greater than or equal to the number of iterations available in the current pipeline level have higher priority. Requests with higher priority are allocated more computing units. This ensures that requests with more remaining iterations receive more resources, preventing resource waste due to slow progress and guaranteeing computational efficiency.

[0013] Each computation request is assigned a local data ID, and the local data ID, the dependent data ID of the next computation request with a dependency relationship, the tail signal LAST, and the iteration number CNT are recorded. The tail signal LAST indicates whether the current computation request still has a dependency relationship. In step S4, when the computation request completes the iteration: if the tail signal LAST is low, the computation result is sent to the recorded dependent data ID, and the lock signal LOCK of the computation request corresponding to the dependent data ID is pulled low, repeating steps S2-S4; if the tail signal LAST is high, the hash computation result is output. The tail signal LAST is used to confirm whether the request is the last piece of the dependency chain, and the correct subsequent operation is taken. An identification mechanism is introduced to support the out-of-order return of computation results, avoiding additional waiting delays caused by sequential output.

[0014] A hash calculation scheduling device supporting concurrent responses to multiple requests is also provided, comprising: a hash calculation scheduler for scheduling multiple calculation requests and allocating calculation units; and calculation units for performing hash iterative calculations. This achieves dynamic allocation and flexible scheduling of calculation units, effectively solving the resource contention problem in scenarios with concurrent multiple requests.

[0015] The hash calculation scheduler includes: a splitting and filling module, an ID distribution module, a channel coordination module, an iteration judgment module, and a result output module. The splitting and filling module receives input data, splits and / or fills the input data to obtain data segments of a target length, each data segment corresponding to a calculation request. The ID distribution module receives the requests to be calculated, assigns an ID to each request, and records the ID of the next request with a dependency relationship. The channel coordination module arbitrates the requests to be calculated, filters out those that meet the arbitration conditions, determines the pipeline level based on the number of requests to be arbitrated, and allocates calculation units to the requests based on the pipeline level. The iteration judgment module determines, based on the iteration count and dependencies of each calculation request, whether to return requests that have not completed iterations to the channel coordination module, pass the calculation result of completed iteration requests to the next request with a dependency relationship, or pass the calculation result of completed iteration requests to the result output module. The result output module outputs the final calculation result. By using arbitration and adaptive pipeline level configuration, computing units are dynamically allocated, supporting out-of-order request returns, reducing computing latency in multi-request scenarios, and improving the system's computing efficiency and resource utilization.

[0016] Compared with existing technologies, the beneficial effects of this invention mainly include the following: By uniformly arbitrating and pipeline planning multiple hash calculation requests, dynamic allocation and flexible scheduling of computing units are achieved, effectively solving the resource contention problem in scenarios with multiple concurrent requests; Based on pipeline levels, multiple computing units are re-routed, accelerating the completion speed of a single request with more computing units when the number of requests is small, and serving more requests with fewer computing units when the number of requests is large, achieving a dynamic balance between computing speed and resource utilization; By introducing an identification mechanism, result transfer and dependency unlocking between multiple requests with dependencies after splitting are supported, while allowing requests without dependencies to directly output results after computation, achieving out-of-order return of computation results and avoiding additional waiting delays caused by sequential output; The scheduler records and monitors the iteration count of each request in real time, and incomplete requests can return to the scheduling step to re-participate in arbitration, ensuring that computing tasks under any number of requests can proceed in an orderly manner and eventually be completed. Attached Figure Description

[0017] 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 recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 The flowchart of the hash calculation scheduling method supporting concurrent responses for multiple requests is provided in Example 1.

[0019] Figure 2 This is a schematic diagram of a hash calculation scheduling device that supports concurrent responses to multiple requests, provided in Embodiment 2.

[0020] Figure 3 This is a schematic diagram of the hash calculation scheduler provided in Example 2. Detailed Implementation

[0021] The following description and accompanying drawings fully illustrate specific embodiments of the invention to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Some portions and features of some embodiments may be included in or replace portions and features of other embodiments.

[0022] Example 1

[0023] This embodiment provides a hash calculation scheduling method that supports concurrent responses to multiple requests, such as... Figure 1 As shown, it includes the following steps: S1: Receive input data, split and / or pad the input data to obtain data segments of the target length, each data segment corresponding to a calculation request; taking SHA-256 as an example, any data request is input to the scheduler. The scheduler first judges the length of the input data. When the length of the input data exceeds 448 bits, it is split into multiple data segments with data dependencies according to the SHA-256 calculation rules. The split data segments are then padded according to the SHA-256 padding rules; when the length of the input data does not exceed 448 bits, it is padded according to the SHA-256 padding rules.

[0024] S2: Obtain the computation requests to be arbitrated in the current period; assign a local data ID to each computation request, and record the local data ID of the next request that the computation request with dependencies points to; simultaneously record the association information of each computation request, including the lock signal LOCK, the tail signal LAST, the iteration count CNT, and the valid signal VALID. A low LOCK indicates that the current computation request can participate in arbitration; a high LOCK indicates that the previous data that the current computation request depends on has not been calculated, and the computation request will be skipped during arbitration. The tail signal LAST indicates whether the current computation request still has dependencies; for unsplit computation requests, the tail signal LAST is always high; for split computation requests, only the last computation request raises the tail signal LAST. The iteration count CNT is the current number of iterations, and together with the tail signal LAST, it serves as a marker for determining the completion of hash calculation. The computation requests with a high valid signal VALID and a low LOCK are selected as the computation requests to be arbitrated in the current period.

[0025] S3: Determine the pipeline level based on the number of pending arbitration requests in the current cycle. Assign computation units to the pending arbitration requests based on the pipeline level. The assigned pending arbitration requests become the pending computation requests for the current cycle, and iterative computation is performed for the current cycle. The number of pending arbitration requests is counted as n, and the pipeline level is determined based on n. Processing is performed according to the following preset pipeline levels: 64-level pipeline occupies 1 computation unit, 32-level pipeline occupies 2 computation units, 16-level pipeline occupies 4 computation units, 8-level pipeline occupies 8 computation units, 4-level pipeline occupies 16 computation units, 2-level pipeline occupies 32 computation units, and 1-level pipeline occupies 64 computation units. The established rules are as follows: when n ≥ 64, a 64-level pipeline is used; when 32 ≤ n < 64, some requests use a 32-level pipeline and some use a 64-level pipeline; when 16 ≤ n < 32, some requests use a 16-level pipeline and some use a 32-level pipeline or higher; when 8 ≤ n < 16, some requests use an 8-level pipeline and some use a 16-level pipeline or higher; when 4 ≤ n < 8, some requests use a 4-level pipeline and some use an 8-level pipeline or higher; when 2 ≤ n < 4, some requests use a 2-level pipeline and some use a 4-level pipeline or higher; when n = 1, a 1-level pipeline is used. In this embodiment, there are 10 requests currently iterating in the system: 4 requests have been iterated for 16 rounds, 4 requests have been iterated for 32 rounds, and 2 requests have been iterated for 62 rounds. The number of requests currently awaiting arbitration is 10. The channel coordination module counts the number of pending arbitration requests, n=10. According to the pipeline level determination rules, when 8≤n<16, some requests use level 8 pipeline, and some requests use level 16 pipeline or higher. The correspondence between each pipeline level and the number of computing units occupied is as follows: level 8 pipeline occupies 8 computing units, level 16 pipeline occupies 4 computing units, level 32 pipeline occupies 2 computing units, and level 64 pipeline occupies 1 computing unit.

[0026] The allocation scheme is calculated using the resource allocation formula x + y = m, where px + q(yz) + Σ(ri*zi) ≤ 64. Here, x represents the number of pending computational requests occupying more computational units, y represents the number of pending computational requests occupying fewer computational units, z represents the number of pending computational requests using a higher-level pipeline, p and q represent the number of computational units occupied by the corresponding pipeline level, ri represents the number of computational units occupied by the i-th higher-level pipeline (0 ≤ i ≤ z), m represents the number of requests actually allocated to computational units in the current period (m ≤ n), and n represents the total number of pending computational requests. The arbitration process uses a priority-based approach. The polling arbitration method prioritizes requests with remaining iterations greater than or equal to the current pipeline level, allocating more computing units to them. Specifically, during the solution process, the allocation is determined sequentially based on the number of computing units required: first, requests (x) occupying the most units, then requests (y) occupying fewer units, and finally requests (z) using a higher pipeline level. Requests with more remaining iterations are allocated more computing units, while those with fewer are allocated a smaller, more appropriate number, avoiding assigning more units to requests nearing completion than they actually need. This approach aims to maximize the utilization of the 64 computing units while ensuring fairness in the polling process. If all pending requests cannot simultaneously obtain computing units in the current round, only a subset of these requests are selected for the current round, while the remaining requests remain valid and await the next round of arbitration.

[0027] In this embodiment, two requests that have already iterated 62 times have only 2 remaining iterations, which is less than the 2 iterations provided by the current 32-stage pipeline. Therefore, their priority is reduced. n is 10, p is 8 computational units, q is 4 computational units, and r0 and r1 are both 0-2 computational units. The optimal allocation scheme is: 7 requests use an 8-stage pipeline (4 requests have iterated 16 times, and 3 requests have iterated 32 times), 1 request uses a 16-stage pipeline (1 request has iterated 32 times), and 2 requests use a 32-stage pipeline (2 requests have iterated 62 times). In this iteration, all 64 computational units are fully utilized, while also ensuring polling fairness among requests. The scheduler reroutes the computational units according to the above allocation scheme, assigns the configured computational units to the corresponding computational requests, and performs iterative computation for the current cycle. During the iterative computation process, intermediate computation results are stored in the storage unit in clock cycles, and the iteration count (CNT) of the corresponding request is updated. After the operation is completed, each request is stored in the storage unit according to its data ID as the storage address, and the number of iterations is increased accordingly according to the number of pipeline stages used.

[0028] S4: The scheduler determines whether each pending arbitration computation request has completed its iteration. If the iteration is complete, the hash calculation result is output, or the hash calculation result is used as the initial value for the next corresponding pending arbitration computation request. That is, if the tail signal LAST is low, the calculation result is sent to the corresponding dependency data ID of the computation request record, and the lock signal LOCK of the computation request corresponding to the dependency data ID is pulled low, repeating steps S2-S4; if the tail signal LAST is high, the hash calculation result is output; if the computation request has not completed its iteration, the next cycle begins, and steps S2-S4 are repeated.

[0029] In this embodiment, four requests that have undergone 16 iterations use an 8-level pipeline, increasing the iteration count by 8 rounds to 24 rounds; three requests that have undergone 32 iterations use an 8-level pipeline, increasing the iteration count to 40 rounds; one request that has undergone 32 iterations uses a 16-level pipeline, increasing the iteration count by 4 rounds to 36 rounds; and two requests that have undergone 62 iterations use a 32-level pipeline, increasing the iteration count by 2 rounds to 64 rounds. After this round of 32-level pipeline calculation, the two requests that have undergone 62 iterations reach 64 iterations and complete the iteration. The scheduler further determines the tail signal LAST of these two requests: if LAST is low, it indicates that the request has a dependency relationship, so the calculation result is sent to the next request pointed to by the dependency data ID recorded in the request record, and the lock signal LOCK corresponding to the next request is pulled low, so that the next request is eligible to participate in arbitration, and the process returns to step S2 to enter the next cycle; if LAST is high, it indicates that the request does not have a dependency relationship, so the hash calculation result is output with the ID of the request. The remaining 8 requests have not yet completed 64 iterations. Their intermediate calculation results are stored in the storage unit and then returned to step S2 to enter the next cycle to continue iterating. The above process continues to loop until all requests have completed all iterations and output the results.

[0030] Throughout the calculation process, requests that have not completed the iteration are continuously returned to participate in arbitration again, and are coordinated with other requests to be calculated in the system to allocate computing units. The device ensures that each request can proceed in an orderly manner through arbitration mechanism and pipeline level adaptive configuration. Requests without dependencies can output results directly without waiting for other requests after completion. Requests with dependencies are assigned an introduction flag to realize the out-of-order return of computing results and reduce waiting delay.

[0031] Example 2

[0032] This embodiment provides a hash calculation scheduling device that supports concurrent responses to multiple requests, such as... Figure 2 As shown, it includes: a hash calculation scheduler, used to schedule multiple calculation requests and allocate calculation units; and a calculation unit, which packages the calculation logic of intermediate hash values ​​a and e into a calculation unit and performs hash iteration calculation.

[0033] like Figure 3As shown, the hash calculation scheduler includes: a splitting and filling module, an ID distribution module, a channel coordination module, an iteration judgment module, and a result output module; The splitting and filling module receives input data, splits and / or fills the input data to obtain data segments of a target length, each data segment corresponding to a computation request; the ID distribution module assigns an ID to each computation request and records the ID of the next request with a dependency; the channel coordination module arbitrates computation requests, determines the pipeline level based on the number of computation requests to be arbitrated, adaptively plans the cascading method between computation units, and assigns computation units to the computation requests to be arbitrated based on the pipeline level; the iteration judgment module is used to decide, based on the iteration number and dependency of each computation request, whether to return requests that have not completed iterations to the channel coordination module, pass the computation result of completed iteration requests to the next request with a dependency, or pass the computation result of completed iteration requests to the result output module; the result output module is used to output the final computation result.

[0034] Dynamic allocation of computing units is achieved through arbitration and adaptive pipeline level configuration. An identification mechanism is introduced to support out-of-order return of requests, shorten the computing latency in multi-request scenarios, and improve the computing efficiency and resource utilization of the system.

[0035] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A hash calculation scheduling method supporting concurrent responses to multiple requests, characterized in that, include: S1: Receive input data, split and / or pad the input data to obtain data segments with a target length, and each data segment corresponds to a calculation request; S2: Obtain the arbitration calculation request for the current period; S3: Determine the pipeline level based on the number of pending arbitration calculation requests in the current cycle, allocate calculation units to the pending arbitration calculation requests based on the pipeline level, and use the allocated pending arbitration calculation requests as pending calculation requests in the current cycle for iterative calculation in the current cycle. S4: If the request to be calculated completes the iteration, output the hash calculation result, or use the hash calculation result as the initial value for the next corresponding request to be arbitrated. If the iteration is not completed, proceed to the next cycle and repeat steps S2-S4.

2. The hash calculation scheduling method supporting concurrent responses to multiple requests according to claim 1, characterized in that, In step S2, the process of obtaining the arbitration calculation request is as follows: Record the lock signal LOCK and the valid signal VALID of the arbitration calculation request; The computation requests with a high valid VALID signal and a low LOCK signal are selected as the computation requests to be arbitrated in the current period; the low LOCK signal indicates that the data on which the current computation request depends has been computed.

3. The hash calculation scheduling method supporting concurrent responses to multiple requests according to claim 2, characterized in that, The process for determining the flow grade is as follows: The number of requests to be arbitrated is n. When n≥64, a flow rate of 64 levels is adopted; When 32≤n<64, some of the requests to be arbitrated adopt a 32-level pipeline, and the remaining requests to be arbitrated adopt a 64-level pipeline; When 16≤n<32, some of the requests to be arbitrated are processed using a 16-level pipeline, while the remaining requests are processed using a 32-level pipeline or a higher level pipeline. When 8 ≤ n < 16, some of the requests to be arbitrated are processed using an 8-level pipeline, while the remaining requests are processed using a 16-level pipeline or a higher level pipeline. When 4≤n<8, some of the requests to be arbitrated are processed using a 4-level pipeline, while the remaining requests are processed using an 8-level pipeline or a higher level pipeline. When 2≤n<4, some of the requests to be arbitrated are processed using a 2-level pipeline, while the remaining requests are processed using a 4-level pipeline or a higher level pipeline. When n=1, a level 1 flow is used.

4. The hash calculation scheduling method supporting concurrent responses to multiple requests according to claim 3, characterized in that, The number of computing units occupied by each level of the pipeline is as follows: 1 computing unit for the 64-level pipeline, 2 computing units for the 32-level pipeline, 4 computing units for the 16-level pipeline, 8 computing units for the 8-level pipeline, 16 computing units for the 4-level pipeline, 32 computing units for the 2-level pipeline, and 64 computing units for the 1-level pipeline.

5. The hash calculation scheduling method supporting concurrent responses to multiple requests according to claim 4, characterized in that, The flow level and calculation unit allocation of the arbitration calculation request satisfy the following relationship: x+y=m px+q(yz)+Σ(ri*zi)≤64, x represents the number of pending computation requests that occupy more computation units, p represents the number of computation units occupied by the corresponding pipeline level; y represents the number of pending computation requests that occupy fewer computation units, q represents the number of computation units occupied by the corresponding pipeline level, z represents the number of pending computation requests that occupy even fewer computation units in y; zi represents the i-th request that occupies fewer computation units, with a count value of 1; ri represents the number of computation units occupied by the i-th higher-level pipeline, 0≤i≤z; m represents the number of pending computation requests that obtain computation units after arbitration, m≤n.

6. The hash calculation scheduling method supporting concurrent responses to multiple requests according to claim 1, characterized in that, The arbitration process is a priority-based round-robin arbitration.

7. The hash calculation scheduling method supporting concurrent responses to multiple requests according to claim 6, characterized in that, The computational requests to be arbitrated that have a remaining required number of iterations greater than or equal to the number of iterations that the current pipeline level can provide have a higher priority, and the computational requests to be arbitrated with a higher priority are allocated a larger number of computational units.

8. The hash calculation scheduling method supporting concurrent responses to multiple requests according to claim 1, characterized in that, Assign a local data ID to each computation request, and record the local data ID, the dependent data ID of the next computation request with a dependency relationship, the tail signal LAST, and the iteration number CNT; the tail signal LAST indicates whether the current computation request still has a dependency relationship; In step S4, when the request to be calculated completes the iteration: If the tail signal LAST is low, the calculation result is sent to the recorded dependency data ID, and the lock signal LOCK corresponding to the calculation request of the dependency data ID is pulled low, and steps S2-S4 are repeated. If the tail signal LAST is high, the hash calculation result is output.

9. A hash calculation scheduling device supporting concurrent responses to multiple requests, characterized in that, include: The hash calculation scheduler is used to schedule and allocate computing units for multiple computing requests and determine whether the iteration is complete. A computational unit used for hash iteration calculations.

10. The hash calculation scheduling device supporting concurrent responses to multiple requests according to claim 9, characterized in that, The hash calculation scheduler includes: The module includes a splitting and filling module, an ID distribution module, a channel coordination module, an iterative judgment module, and a result output module. The splitting and filling module receives input data, splits and / or fills the input data to obtain data segments with a target length, and each data segment corresponds to a calculation request. The ID distribution module assigns an ID to each computation request and records the ID of the next computation request that has a dependency relationship. The channel coordination module arbitrates the computational requests to be arbitrated, determines the flow level based on the number of computational requests to be arbitrated, and allocates computational units to the computational requests to be arbitrated based on the flow level. The iteration judgment module is used to determine, based on the iteration number and dependency relationship of each calculation request, whether to return the request that has not completed the iteration to the channel coordination module, or to pass the calculation result of the completed iteration request to the next request with a dependency relationship, or to pass the calculation result of the completed iteration request to the result output module. The result output module is used to output the final calculation result.

Images