Hash and symmetric cryptography hybrid hardware acceleration system capable of dynamically switching
By using a dynamically switching hardware acceleration system that combines hashing and symmetric cryptography, and leveraging a unified state register and adaptive timing constraint logic, the system addresses the performance bottleneck caused by static timing constraints in logic folding, achieving efficient reuse of hardware resources and matching peak performance for high-speed tasks.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-12
- Publication Date
- 2026-03-20
AI Technical Summary
When existing data processing architectures achieve hardware reuse through logical folding, the peak performance of high-speed tasks is constrained by the physical path of low-speed tasks due to static timing constraints, making it impossible to simultaneously meet hardware resource utilization and performance requirements.
A hybrid hardware acceleration system combining hashing and symmetric cryptography with dynamic switching is adopted. Through a unified state register, a reconfigurable unified computing data path, a microcode configuration and control unit, and adaptive timing constraint logic, the logical functions and timing constraints of the data path are dynamically adjusted to adapt to the current task type, thereby achieving efficient task switching and performance matching.
Without increasing hardware resources, the system clock frequency can be set based on the fastest task, dynamically switching the execution path constraints of different tasks, avoiding the problem of being dragged down by static timing, and improving the reusability and peak performance of hardware resources.
Smart Images

Figure CN121711084A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to a hardware acceleration system that dynamically switches between hash and symmetric cryptography, belonging to the field of data processing technology. Background Technology
[0002] Currently, to meet the stringent limitations on chip area and power consumption for specific application scenarios, the use of dedicated hardware accelerators has become a common technical approach. In such designs, to further optimize resource utilization, integrating the hardware logic of various computing tasks, such as symmetric cryptography processing and hash verification, into a single shared computing data path through reuse or logic folding is a common design choice. However, this general approach, adopted at the logic design level for the sake of simplicity, is constrained at the physical implementation level by a fundamental engineering constraint derived from the static timing principle in digital circuit design. Specifically, the maximum power consumption of a hardware module... The clock frequency is statically determined by the critical path with the longest signal propagation delay among all internal logic paths. When a person skilled in the art folds a fast task with a shorter critical path (such as AES-like operations) and a complex task with a longer critical path (such as SHA-3-like operations) onto the same shared data path, the overall clock frequency of that data path must be set according to the longest critical path to meet the timing requirements of the slowest task. This design limitation causes the peak throughput performance of the system to be unnecessarily limited when executing the fast task that should be faster, resulting in a loss of hardware performance.
[0003] To avoid this problem, reverting to configuring a separate dedicated hardware pipeline for each task would increase chip area and static power consumption, which is unacceptable in many cost-sensitive applications. Therefore, existing technologies generally face the following mutually constraining design challenges in practice: 1. Using a time-sharing shared pipeline introduces time delays when switching between different tasks due to the saving and restoring of the computation state; 2. Using a parallel approach with independent pipelines, the hardware resource overhead is directly related to the number of tasks supported, making it difficult to meet low-cost constraints; 3. Using a logically folded unified data path is also limited by static timing constraints, causing the peak performance of high-speed tasks to be limited by the physical path of low-speed tasks.
[0004] To minimize hardware area in logical folding, existing research often focuses on reusing algorithms at the computational primitive level (such as the substitution box S-box). For example, Chinese invention patent CN109565438B discloses a hardware accelerator and system for hybrid encryption algorithms. This scheme proposes a hardware accelerator that combines AES and SMS4. Its core lies in sharing the inverse computation (S-box) logic with the largest area overhead between the two algorithms at the Galois field (GF) composite field level by selecting common base and extension field polynomials, thereby achieving hardware reuse and area saving. However, this design approach is still limited to area optimization at the logical function level. It does not solve, and even reflects, the performance bottleneck at the physical implementation level mentioned in the third difficulty above: that is, algorithms like AES and SMS4 have different computational complexities and critical path durations. Forcibly folding them into the same data path and using uniform static timing constraints inevitably leads to the clock frequency of the entire system being limited to the slowest task, and the peak performance of high-speed tasks is still severely hampered. Therefore, the technical problem to be solved by this invention is how to design a data processing architecture that can achieve high reuse of hardware logic while decoupling the fixed binding relationship between logical function selection and static physical timing constraints, so that different tasks can match their optimal performance when running on the same hardware. Summary of the Invention
[0005] This invention provides a dynamically switching hardware acceleration system that combines hashing and symmetric cryptography. Its main purpose is to solve the problem in existing data processing architectures where, when hardware reuse is achieved through logical folding, the peak performance of high-speed tasks is constrained by the physical path of low-speed tasks due to static timing constraints.
[0006] To achieve the above objectives, the present invention provides a dynamically switching hardware acceleration system combining hashing and symmetric cryptography, the system comprising: A unified state register is configured to store the computational state of a currently active cryptographic task; A reconfigurable unified computation data path is connected to the input and output of a unified state register. The reconfigurable unified computation data path physically integrates a computation logic with a first critical path duration for a first cryptographic task type and a computation logic with a second critical path duration for a second cryptographic task type, wherein the second critical path duration is longer than the first critical path duration. A microcode configuration and control unit is configured to store a configuration state indicating the type of currently active cryptographic task; An adaptive timing constraint logic, the microcode configuration and control unit is also configured to, in response to a change in configuration state, collaboratively perform the following operations: generate a functional reconfiguration signal to reconfigure the internal logic function of the reconfigurable unified computing data path to adapt it to the cryptographic task type corresponding to the configuration state; generate a timing pattern signal in parallel, the timing pattern signal corresponding to the critical path duration of the cryptographic task type corresponding to the configuration state; and the adaptive timing constraint logic is configured to: receive the timing pattern signal and, based on the timing pattern signal, set the execution path constraint of the reconfigurable unified computing data path in the data processing clock cycle to a first execution path constraint corresponding to a first critical path duration, or a second execution path constraint corresponding to a second critical path duration.
[0007] Preferably, the configuration state further includes state width information required for the cryptographic task; the microcode configuration and control unit is also configured to: generate a state boundary masking signal based on the state width information; and use the state boundary masking signal to gate the write enable logic of the unified state register to prevent data of a cryptographic task with a narrow state width from being written into the area of the unified state register reserved for cryptographic tasks with a wide state width.
[0008] Preferably, the system further includes a configuration stream cross-validation module, which is configured to: receive a first task type identifier corresponding to the configuration state from the microcode configuration and control unit; receive a second task type identifier associated with the input data stream from the system's data input interface; and determine a mismatch condition. Whether it is true or not, among which, , This serves as the identifier for the first task type. It serves as the identifier for the second task type; and, when the mismatch condition is met, it generates a control signal to abort the input data stream processing of the reconfigurable unified computing data path.
[0009] Preferably, the microcode configuration and control unit further includes a hardware-implemented execution context stack; the microcode configuration and control unit is also configured to: upon receiving a preemption request signal, suspend the currently active cryptographic task, which is defined as a low-priority task; push an execution context of the low-priority task onto the execution context stack, the execution context including the task type and an execution round number of the low-priority task; switch to executing a high-priority task associated with the preemption request signal; and after the high-priority task completes, pop the execution context from the execution context stack to resume the execution of the low-priority task.
[0010] Preferably, the system further includes a command packet detector located at the system's data input interface and configured to: monitor the input data stream and identify a command packet by comparing the packet header of the input data stream with a preset command packet identifier; when a command packet is identified, intercept the command packet and extract a new configuration state from the payload of the command packet; and directly write the new configuration state into the microcode configuration and control unit to trigger a change in the configuration state.
[0011] Preferably, the reconfigurable unified computational data path includes: a shared linear path containing logic circuits configured to perform linear computational primitives common to multiple cryptographic tasks; and a dedicated nonlinear path containing logic circuits configured to perform nonlinear computational primitives specific to each of the multiple cryptographic tasks; wherein the microcode configuration and control unit is further configured to: store a configuration state for a basic integrity check; and, in the configuration state of the basic integrity check, reconfigure the logic circuits in the shared linear path to functionally perform the computation of the basic integrity check, while gating the operation of the dedicated nonlinear path.
[0012] Preferably, the microcode configuration and control unit is further configured to: store a configuration state for generating a pseudo-random number; and, in the configuration state for generating the pseudo-random number, reconstruct the logic circuit in the shared linear path so that it functionally implements the calculation of a linear feedback shift register, thereby generating a pseudo-random number; wherein the unified state register is used to store the current state of the linear feedback shift register.
[0013] Preferably, the microcode configuration and control unit is further configured to: when the configuration state indicates a first cryptographic task type, the clock in the gated dedicated nonlinear path is used only for the logic circuit of the second cryptographic task type; when the configuration state indicates a second cryptographic task type, the clock in the gated dedicated nonlinear path is used only for the logic circuit of the first cryptographic task type.
[0014] Preferably, the system further includes a data interface module, which is configured to: receive external data packets; compare the task type identifier contained in the metadata of the external data packets with the configuration status; and when the task type identifier and the configuration status are inconsistent, send a switching request signal to the microcode configuration and control unit to change the configuration status.
[0015] Preferably, the first execution path constraint is a single-cycle path constraint, and the second execution path constraint is a multi-cycle path constraint.
[0016] Compared with the prior art, the beneficial effects of the present invention are: 1. The data processing architecture provided by this invention uses a microcode configuration and control unit to coordinate a unified state register and a reconfigurable unified computing data path. The configuration state stored in the control unit is used to dynamically reconfigure the internal logic function of the data path to adapt it to the current task type. On the other hand, the configuration state also synchronously controls the state boundary masking logic in the unified state register. This built-in mechanism that binds functional configuration with state isolation enables the system to complete task switching within a single clock cycle while automatically gating the unauthorized area of the register using the state width signal. This avoids the data pollution problem caused by the incompatibility of state widths between different tasks (such as 128-bit state and 1600-bit state), and enables the simplified hardware pipeline to achieve a unity of highly dynamic switching and data integrity in terms of functionality.
[0017] 2. The functional timing coordination mechanism constructed in this solution solves the problem of physical timing drag caused by logic folding in data processing hardware design. The configuration status output by the microcode configuration and control unit in the system is given a dual function: while instructing the data path to execute specific logical functions such as symmetric cryptography or hashing, it is also used as a timing mode signal to dynamically adjust the physical execution path constraints of the data path. This allows the overall clock frequency of the system to be set based on the fastest task path, such as a single-cycle path, while slower tasks with longer critical paths are automatically configured to complete within multiple clock cycles. This architecture, which binds the selection of logical functions with physical timing constraints, allows the hardware to avoid compromising on peak performance while pursuing area minimization.
[0018] 3. By analyzing the computational primitives at the logic gate level, hardware resources are deeply reused. The shared linear path built to implement symmetric cryptography and hash algorithms already contains the logic required to implement basic data processing functions such as cyclic redundancy check (CRC) or pseudo-random number generation (PRNG) in its internal XOR array and permutation network. Therefore, by adding a new configuration state in the microcode configuration and control unit, the internal logic of the shared linear path can be reorganized, making it functionally equivalent to a linear feedback shift register, while gating the nonlinear computation part. This method expands the system with new data processing functions without adding computational hardware logic, thus improving the functional density of a single hardware component. Attached Figure Description
[0019] Figure 1 This is a diagram showing the top-level architecture and main control signal flow of the system of this invention; Figure 2 This is a comparison chart of dynamic and static power consumption under different computing modes of the present invention; Figure 3This is a diagram of the internal coordination mechanism and data path structure of the system of the present invention. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the specific embodiments described herein are only used to explain this invention and are not intended to limit the scope of protection of this invention.
[0021] The present invention discloses a dynamically switching hybrid hardware acceleration system for hashing and symmetric cryptography. As a data processing EDP architecture, it mainly includes a unified state register, a reconfigurable unified computational data path, a microcode configuration and control unit, and an adaptive timing constraint logic at the system level. The core operating mechanism of the system is that the microcode configuration and control unit is configured to respond to a change in an internal configuration state, which indicates the type of cryptographic task to be performed, such as a first cryptographic task type (e.g., AES symmetric cryptography) or a second cryptographic task type (e.g., SHA-3 hashing). In response to this change, the control unit collaboratively and in parallel generates two signals: a functional reconfiguration signal and a timing mode signal. The functional reconfiguration signal is sent to the reconfigurable unified computational data path to dynamically adjust its internal combinational logic function; while the timing mode signal is sent to the adaptive timing constraint logic, which then sets the execution path constraints of the data path in the data processing clock cycle based on the timing mode signal.
[0022] In hardware design practice for data processing, when multiple algorithmic logics are folded onto the same physical data path to save chip area, the highest operating clock frequency of the entire data path is forced to be limited by the longest critical path among all algorithms. This causes the peak performance of the system to be unnecessarily dragged down when executing algorithms that should be faster. The architecture design of this technical solution aims to address this physical implementation challenge through the aforementioned functional timing coordination mechanism. The reconfigurable unified computing data path physically integrates the first cryptographic task type, such as AES, with a first critical path duration of, for example... The computational logic, and the second critical path duration used for second cryptographic task types such as SHA-3, for example... The computational logic involves a second critical path duration that is greater than the first critical path duration. To achieve dynamic timing optimization, the system clock frequency of the entire data processing system can be set based on the fastest task, i.e., the task with the first critical path duration (AES). For example, if... It is 9.5 nanoseconds (ns), while If the clock cycle is 18 nanoseconds (ns), the system clock cycle can be set to 10 nanoseconds (ns), corresponding to a 100MHz operating frequency. When the configuration status of the microcode configuration and control unit is set to the first cryptographic task type (AES), the timing mode signal it generates will cause the adaptive timing constraint logic to set the execution path constraint to the first execution path constraint. In a specific engineering implementation, this first execution path constraint is a single-cycle path constraint, allowing the AES operation to be completed within one clock cycle (10ns), which meets its 9.5ns path requirement. When the configuration status is switched to the second cryptographic task type (SHA-3), the timing mode signal will cause the adaptive timing constraint logic to dynamically and non-intrusively set the execution path constraint to the second execution path constraint. This second execution path constraint is a multi-cycle path constraint, such as a 2-cycle path constraint, which allows the SHA-3 operation to be completed within two clock cycles (20ns), thus meeting its 18ns critical path requirement.
[0023] To achieve the above functionality, the reconfigurable unified computation data path is further configured internally to include a shared linear path and a dedicated nonlinear path. The shared linear path contains the logic circuitry required to implement linear computation primitives, such as XOR arrays, barrel shifters, or permutation networks, which are used to perform linear operations common to various cryptographic tasks, such as AES's ShiftRows and MixColumns, and SHA-3's... , , , Transformation; dedicated nonlinear paths contain their own unique nonlinear computational primitives, such as the S-Box lookup table required for AES to implement the SubBytes function, and the one required for SHA-3. Step-by-step nonlinear logic, such as AND / NOT / XOR gates; the functional reconfiguration signals generated by the microcode configuration and control unit, at their specific level, control the computational state data flow in the unified state register, directing it through a specific combination of shared linear paths and dedicated nonlinear paths. For example, in AES mode, it activates the S-Box and configures the shared path to perform the AES linear transformation; in SHA-3 mode, it activates... The logic and configuration shared path perform SHA-3 linear transformation; further, to reduce the dynamic power consumption of the system at the layer, the microcode configuration and control unit is also configured to, when the configuration state indicates the first cryptographic task type (such as AES), automatically gate the dedicated nonlinear path used only for the second cryptographic task type (e.g., for SHA-3) through clock gating, a common technique in design. The clock of the logic circuit (logic) is set to be the clock, and vice versa, thus avoiding switching power consumption caused by invalid logic units; the unified state register is configured as a single, wide-bit physical register file, wide enough to accommodate the largest computational state in all tasks, such as the 1600 bits required for SHA-3, while other tasks such as AES may only require 128 bits; to solve the data pollution problem that may be caused by incompatible state widths, this technical solution introduces a dynamic state boundary masking mechanism. Specifically, the configuration state is extended to further include the state width information required by the cryptographic task. The microcode configuration and control unit generates an additional state boundary masking signal based on this state width information; in physical implementation, this state boundary masking signal is connected to the write enable logic of each storage unit in the unified state register. When the system is in AES mode, i.e., the state width is 128 bits, this masking signal will automatically gate (prohibit writing) all register areas after 128 bits, specifically bits 129 to 1600, thereby preventing data from AES tasks from being written to the register areas reserved for SHA-3 tasks.
[0024] To further enhance system reliability and mitigate the risk of configuration-loss mismatch and silent data corruption due to bus errors or DMA descriptor misalignment, this system may further include a configuration stream cross-validation module. This module is configured as a hardware comparator that runs in parallel with the data path and receives two inputs: first, a first task type identifier representing the internal hardware state, read in real-time from the microcode configuration and control unit. For example, AES mode corresponds to 0b01; secondly, it reads the second task type identifier associated with the current input data stream in real time from the system's data input interface, such as the TUSER bypass signal channel of the AXI-Stream bus in the system. For example, a data packet labeled SHA-3 corresponds to 0b10; this module determines a mismatch condition in real time every clock cycle. Whether it is valid, among which In the example above, because Mismatch conditions Upon successful verification, the cross-validation module immediately generates a control signal to force gating or halt the processing of the erroneous data stream by the reconfigurable unified computing data path. Simultaneously, it can issue an interrupt request to the upper-layer system, such as the central processing unit (CPU), thus blocking the error at its source. To address the system-level switching latency commonly found in hardware accelerators due to reliance on CPU software-in-the-loop decisions, the system may further include an instruction packet detector located at the system's data input interface. This detector implements an autonomous control mechanism for embedding instructions within the data stream. The upstream module, such as DMA, is configured to in-band insert a special instruction into the actual data packet stream. The command packet detector monitors the input data stream in real time through hardware pattern matching. For example, it compares the packet header with a preset command packet identifier, a specific MagicWord. When a normal data packet is detected, the detector allows it to pass through the reconfigurable unified computing data path. When a command packet is detected, the detector immediately intercepts the command packet, preventing it from entering the computing path. It then extracts a new configuration state from the payload of the command packet, such as 0b10 representing a switch to SHA-3 mode. This new configuration state is then directly written to the microcode configuration and control unit through a dedicated hardware path, thereby triggering a change in configuration state at the pure hardware level and reducing the system's decision latency during task switching.
[0025] Furthermore, to address the common priority inversion problem in real-time operating systems (RTOS), where a long-running low-priority task (such as firmware hash verification) blocks a momentary high-priority task (such as real-time control instruction decryption), the microcode configuration and control unit can be further configured to include a hardware-implemented execution context stack (ECS). This stack is shallow, for example, configured with 2 to 3 levels, and is used only to store a very small amount of execution context, such as task type and execution round number. When the system is executing a low-priority task (such as SHA-3, Round 5), a high-priority preemption request signal arrives. The microcode configuration and control unit responds to this signal by first allowing the current computation round (Round 5) to complete to reach a clean state boundary, and then pushing the execution context of the low-priority task, i.e., [Config=SHA-3, Round=5], onto the execution context stack. Subsequently, the control unit immediately switches the configuration state to execute the high-priority task (such as AES), and after the high-priority task completes, it automatically pops the previously saved context [Config=SHA-3, Round=5] from the execution context stack. [round=5], and resumes the low-priority task from the next round (Round6) to continue execution seamlessly, thus achieving preemptive multitasking scheduling at the hardware level; the architecture of this technical solution also has high resource reusability. The shared linear path built for strong cryptography contains logic (XOR and shifters) that, in terms of computational principle, already includes all the computational primitives required to implement a linear feedback shift register (LFSR); therefore, the microcode configuration and control unit can be further configured to store a configuration state for a basic integrity check (e.g., CRC32). In this configuration state, the microcode of the control unit will reconstruct the logic circuit in the shared linear path, making its function equivalent to a CRC32 LFSR circuit, while gating the operation of the dedicated nonlinear path to save power; similarly, the microcode configuration and control unit can also be configured to store a configuration state for pseudo-random number generation (PRNG), and in this configuration state, the logic of the shared linear path is reconstructed to functionally implement a standard LFSR calculation for high-speed pseudo-random number generation. At this time, the unified state register is reused to store the current state of the LFSR.
[0026] Finally, the system may also include a data interface module, which is configured to receive external data packets at the system's data input end and parse the metadata of the external data packets. For example, the metadata may contain a task type identifier indicating how the data packet should be processed. The data interface module may be configured to compare the task type identifier in the metadata with the current configuration state of the microcode configuration and control unit, and if they are inconsistent, send a switching request signal to the microcode configuration and control unit to change the configuration state, thus forming a data-driven closed-loop control system. When the data interface module performs the operation of comparing the task type identifier contained in the metadata of the external data packet with the current configuration state of the microcode configuration and control unit, its configuration aims to achieve a predictable task switching based on the attributes of the data stream itself. For example, in a data processing system... In this system, data packets may arrive in a predetermined order, with type A being processed first and type B being processed later. When the data interface module detects that the task type identifier B of the next data packet to be processed is inconsistent with the current hardware configuration state A, this inconsistency does not necessarily indicate an error, but may indicate a normal and expected task switching point. In this case, the data interface module is configured not to generate an abort signal, but instead to send a switching request signal to the microcode configuration and control unit. This request signal carries the target task type identifier B parsed from the data packet metadata, thereby triggering the microcode configuration and control unit to update its internal configuration state to B, so that the hardware is ready to process the following data packet. This mechanism, which compares data packet metadata and triggers a switching request, provides a task switching method that does not require CPU intervention or special instruction packet data driving.
[0027] Example 1: In a specific data processing EDP application, namely a system-on-chip (SoC) design for a resource-constrained edge IoT security gateway, the system faces a typical engineering constraint: it must simultaneously support two computationally different tasks within an extremely limited chip area and power budget. The first type of task is a cryptographic task for high-throughput telemetry data streams, such as AES encryption, which has a relatively short first critical path duration. And a second cryptographic task type used for firmware update package verification, such as SHA-3 hash, which has a relatively long second critical path duration. In traditional design approaches, if logic folding is used to meet area constraints, the clock frequency of the entire system must be adjusted to accommodate a longer clock cycle. This results in performance limitations when performing AES tasks, failing to meet the throughput requirements of real-time data processing. To address this engineering problem, the gateway system employs a hardware acceleration system as described in the aforementioned specific implementation. The clock frequency of the entire system is set to 100MHz, based on the first cryptographic task type (AES). The duration is determined, for example, to be 9.5ns. When the data stream is telemetry data, the configuration state of the microcode configuration and control unit is set to AES mode, and functional reconfiguration signal and timing mode signal are generated in a coordinated manner. The functional reconfiguration signal configures the reconfigurable unified computing data path as AES logic. At the same time, the timing mode signal drives the adaptive timing constraint logic, setting the execution path constraint as the first execution path constraint, i.e., the single-cycle path constraint. Under this constraint, the AES calculation completes one iteration in every 100MHz clock cycle, i.e., 10ns, which meets the 9.5ns timing requirement, allowing the telemetry data stream to be processed according to its peak performance.
[0028] When a firmware update package arrives, the system's data interface module or instruction packet detector triggers the microcode configuration and control unit to switch its configuration state to SHA-3 mode. Within the same clock cycle, this control unit collaboratively updates its output: its function reconfiguration signal causes the same reconfigurable unified computation data path to implement SHA-3 computation logic. Simultaneously, its timing mode signal changes, driving the adaptive timing constraint logic to immediately switch the execution path constraint to a second execution path constraint, i.e., a multi-cycle path constraint, such as a 2-cycle path constraint. Under this new constraint, physically 18ns are required. The SHA-3 computation logic, which requires a certain path duration to complete, is allowed to occupy 2 system clock cycles, totaling 20ns, to close its timing. During the operation of this system, the selection of logic functions and physical timing constraints are dynamically constrained through the collaborative work of microcode configuration, control unit, and adaptive timing constraint logic. The system clock frequency does not need to be dynamically adjusted between different tasks, but always runs at the 100MHz frequency set for high-speed tasks. By simply performing adaptive adjustments to the path constraints, the physical timing drag inherent in logic folding is resolved, allowing the simplicity of chip area and peak performance throughput to coexist within a single architecture.
[0029] Example 2: To objectively verify the functional timing coordination mechanism of the present invention, this comparative experiment was conducted in the (data processing) hardware implementation to compare the specific performance gains in solving the static timing drag problem compared to the traditional logic folding design method. The experimental platform was based on a standard ASIC (Application-Specific Integrated Circuit) design flow, the hardware target process was set to a 28nm standard cell library, and the synthesis and placement / routing tools used industry-standard EDA (Electronic Design Automation) software. The input to the experiment was the same set of RTL (Register Transfer Level) hardware description language code, which implemented the specific implementation method and included the first cryptographic task type (e.g., AES). (Shorter) and second cryptographic task types (e.g., SHA-3, The experiment involved a relatively long (and reconfigurable unified computation data path) and a unified state register. Two experimental groups were set up: a control group and the prototype group. The only difference between the two groups was the constraint (SDC) file used in the synthesis and timing constraint stages. The control group used a traditional logic folding design method, with its timing constraint file set to a static single-cycle constraint. This required that all logic paths (whether AES or SHA-3) in the reconfigurable unified computation data path must be completed within one system clock cycle. The RTL code and this static constraint file were input into the synthesis tool for processing. The timing analysis report indicated that to satisfy the longest SHA-3 critical path, its duration... For example, a setup time requirement of 18ns, and the highest operating clock frequency of the entire system. It is limited to 55MHz.
[0030] The prototype of this invention adopts the functional timing coordination mechanism of this technical solution. Its timing constraint file is configured to respond to the timing mode signals output by the microcode configuration and control unit. This constraint file explicitly instructs the synthesis tool: when the timing mode signal indicates an AES task, the duration of the AES-related logic path is specified. For example, if the duration is 9.5ns, the first execution path constraint, i.e., the single-cycle path constraint, is applied; when the timing mode signal indicates a SHA-3 task, the duration of the SHA-3 related logic path is... For example, with a clock frequency of 18ns, a second execution path constraint is applied, namely a 2-cycle multi-cycle path constraint. The RTL code and this adaptive constraint file are input into the synthesis tool, and the target system clock frequency is set to 100MHz, corresponding to a 10ns cycle. The timing analysis report shows that the AES path (9.5ns) meets the 10ns single-cycle constraint, and the SHA-3 path (18ns) meets the 20ns (2 cycles) multi-cycle constraint. The system timing converges, and the highest operating clock frequency is... At 100MHz, the peak performance of the two test groups at their highest achievable clock frequencies was measured, especially the throughput of high-speed tasks (AES, processing 128 bits of data per cycle). The results are summarized in Table 1.
[0031] Table 1: Comparison of experimental data for different design methods.
[0032]
[0033] Experimental data shows that in the control group using traditional static constraints, the system clock is limited by the slowest SHA-3 task (18ns), resulting in a peak throughput of 7.04Gbps for the AES task (based on...). (Calculation); while the prototype of this invention using this technical solution has its system clock anchored at 100MHz, which is allowed for high-speed AES tasks, and its AES peak throughput reaches 12.8Gbps (based on (Calculation), which improved by about 81.8% compared to the control group; this experimental data objectively confirms that the technical solution, through the functional timing coordination mechanism and the use of adaptive timing constraint logic, effectively decouples the fixed binding relationship between logical function selection and static physical timing constraints without sacrificing the area advantage brought by hardware reuse, solves the problem of static timing drag, and enables tasks with different critical path durations in the system to match their respective processing performance.
[0034] Example 3: This example combines Figures 1 to 3 A description of a hardware-accelerated system that dynamically switches between hash and symmetric cryptography, such as... Figure 1 As shown, the input data stream is received by the data input interface, which sends the data stream to the reconfigurable unified computing data path. Simultaneously, the data stream is monitored by the instruction packet detector, and the second task type identifier carried by the instruction packet is also sent to the configuration stream cross-validation module. After recognizing an instruction, the instruction packet detector extracts the new configuration state and writes it to the microcode configuration and control unit. This control unit stores the configuration state and collaboratively generates a function reconfiguration signal and a timing pattern signal. The function reconfiguration signal is used to configure the reconfigurable unified computing data path, while the timing pattern signal is sent to the adaptive timing constraint logic. Based on the timing pattern signal, the adaptive timing constraint logic sets the execution path constraint of the data path, which applies to the reconfigurable unified computing data path. Simultaneously, the microcode configuration and control unit also provides the configuration stream cross-validation module with the first task type identifier. This cross-validation module compares the internal configuration with the data stream identifier and generates a stop control signal to intervene in the execution of the data path when a mismatch occurs. During computation, the reconfigurable unified computing data path interacts with the unified status register to read and write the computation state and outputs the processed data as a processed data stream via the data output interface.
[0035] like Figure 2 As shown, the system's dynamic power consumption (mW) and static power consumption (mW) performance in AES, SHA-3, CRC, and PRNG modes are compared using a bar chart. Specifically, the static power consumption (represented by solid bars) remains constant at 15mW in all four tested modes, while the dynamic power consumption (represented by diagonal filled bars) varies depending on the currently active computing function. The SHA-3 mode exhibits the highest dynamic power consumption, with an estimated value exceeding 50mW, followed by the AES mode at 45mW, the PRNG mode at 32mW, and the CRC mode at the lowest, with an estimated value of 28mW.
[0036] like Figure 3 As shown, the data input interface includes an instruction packet detector, which sends configuration instructions to the microcode configuration and control unit and sends data streams to the reconfigurable unified computing data path. The microcode configuration and control unit internally includes configuration state storage, state width information, a decoder and control logic, and an execution context stack. It outputs function reconstruction signals and timing pattern signals to the data path, outputs state boundary masking signals to the unified state register, and outputs state width information to the configuration stream cross-validation module. Simultaneously, it receives mismatch abort signals from this verification module. The reconfigurable unified computing data path is physically divided into a shared linear path and a dedicated nonlinear path. The shared linear path includes linear primitives shared by AES and SHA-3, such as XOR arrays, barrel shifters, and permutation networks, and can be reconfigured into CRC or PRNG functions. The dedicated nonlinear path includes an AESS-Box (corresponding to the first critical path) and SHA-3. The logic (corresponding to the second critical path) is divided into a unified status register, for example, a 128-bit AES status area and a 1600-bit SHA-3 status area. Data corruption is prevented through dynamic gating protection and write enable masking control mechanisms. The system clock is anchored to the fastest task, for example, 100MHz. The adaptive timing constraint logic dynamically sets the first execution path to constrain a single-cycle fast task or the second execution path to constrain a multi-cycle slow task based on the timing mode signal from the control unit, so as to ensure the timing convergence of the data path. The final output data is sent to the data output interface.
[0037] Example 4: To further illustrate the technical solution of the present invention, especially its functional and timing coordination mechanism, and the difference in technical effect compared with the conventional design method of the prior art, the following comparative example is set up; When facing the same engineering goals and hardware foundation as Example 2, namely, a unified computing data path and a unified status register containing AES and SHA-3 logic, and a target process of 28nm standard cell library, if the functional and timing coordination mechanism of the present invention is not adopted, but the conventional logic folding design method is followed, the result will be different; Therefore, this comparative example is consistent with the sample of the present invention in Example 2 in terms of RTL hardware description language code. The difference is that this comparative example does not include adaptive timing constraint logic and the function of microcode configuration and control unit generating timing mode signals in parallel. In the synthesis and timing constraint stage, it adopts the standard method in the art for such logic folding design, namely static timing constraint.
[0038] Using industry-standard EDA software, the same RTL code as in Example 2, along with a static timing constraint (SDC) file, is input into the synthesis tool. This static constraint file requires all logical paths in the reconfigurable unified computational data path to adhere to their inherent characteristics, regardless of whether an AES task is currently being executed. Even shorter ones, such as 9.5ns, are still SHA-3 tasks, which are inherently... For data paths with longer durations, such as 18ns, the calculations must be completed within one system clock cycle to meet setup time requirements. Given this constraint, synthesis tools, when performing timing optimization, must use the longest critical path in the entire data path, i.e., the SHA-3 path. The duration is 18ns, which serves as its optimization target and timing benchmark. After synthesis and placement and routing, the final timing analysis report confirms that, to ensure the SHA-3 path can operate reliably within a single cycle, the highest operating clock frequency of the entire hardware system is... The system is statically limited to 55MHz. Performance evaluation of this conventionally designed hardware system is conducted at this maximum allowed 55MHz system clock frequency. Its SHA-3 hash operation executes normally because its 18ns path satisfies a clock cycle of approximately 18.18ns. However, when the system switches to execute AES encryption, although the computation logic itself takes 9.5ns, faster than the clock cycle, its execution rate is still limited by the 55MHz system clock. Based on this, the peak data throughput of the system when executing AES tasks is calculated to be: 128 bits / cycle * 55MHz ≈ 7.04Gbps. This value is different from the 12.8Gbps achieved by the sample group of the present invention in Example 2 at a clock speed of 100MHz. The results of this comparative example show that, without the use of the functional timing coordination mechanism of the present invention, that is, without the coordination of adaptive timing constraint logic and corresponding timing mode signals, when only the computational logic with different critical path durations is physically folded and the conventional static timing constraint method in the art is used for hardware implementation, the overall performance of the system is statically limited by the physical path of the slowest task, which results in the potential peak performance of high-speed tasks not being fully realized. This is in contrast to the results shown by the sample group of the present invention in Example 2.
[0039] Example 5: This example aims to supplement the explanation of the internal reconstruction mechanism of the reconfigurable unified computing data path and the specific data processing hardware implementation details of the dynamic shielding mechanism of state boundaries, in order to eliminate potential technical understanding barriers. Consider a typical scenario where a system, after processing a first cryptographic task type, such as an AES encryption task (state width 128 bits), needs to immediately switch to processing a second cryptographic task type, such as a SHA-3 hash task (state width 1600 bits). This scenario places specific requirements on the instantaneous switching accuracy of the data path function and the isolation between computing states of different widths. To achieve dynamic functional reconstruction of the data path, the configuration state stored internally by the microcode configuration and control unit is implemented, for example, through a set of specific triggers, whose output signal lines are directly connected to a combinational logic decoder. The decoder generates a set of mutually exclusive control signals based on the input configuration state value, such as 01 for AES mode and 10 for SHA-3 mode. These control signals are then used to drive the selection logic units within the reconfigurable unified computing data path, such as multiplexers and enable gates. Specifically, when the configuration state is 01 (AES mode), the decoder output signal A is set high, directly enabling the S-Box lookup logic in the dedicated nonlinear path. Simultaneously, decoder output signals B and C are set to specific values to configure the barrel shifter or permutation network in the shared linear path to perform the AES ShiftRows operation and configure the XOR array therein to perform the MixColumns GF( The domain matrix multiplication logic; correspondingly, when the microcode configuration and control unit receives a switching command and its configuration state flips to 10 (SHA-3 mode) within one clock cycle, the decoder output changes immediately: signal A goes low to disable the S-Box, while signal D is set high to enable the dedicated nonlinear path. The logic is stepped, and signals E and F are set to new specific values to reconfigure the shifters, permutation networks, and XOR arrays in the shared linear path to achieve the SHA-3 requirements. , , , The linear transformation function, which is based on configuration state decoding and directly drives hardware selection logic, enables cycle-accurate reconfiguration of the data path function.
[0040] To ensure data isolation between tasks with different state widths, the microcode configuration and control unit also includes logic for determining the required state width for the current task. This width information can be directly hard-wired to specific bits of the self-configured state, or derived from the configuration state through a small lookup table. For example, the state width value associated with AES mode is 128, and the state width value associated with SHA-3 mode is 1600. This state width value, for example, is represented as... The bits are output and connected to the write enable control logic of the unified status register; in a specific hardware implementation, the unified status register (total width, for example, 1600 bits) may be divided into multiple physical words (e.g., 25 64-bit words, addresses from 0 to 24), and the system has a global write enable signal. At the same time, a separate write enable signal is set for each word. (i ranges from 0 to 24); state width value It is input into an address comparator or range detector, which is based on The value only applies to the address. Less than Those words output high-level enable signals Ultimately, the individual write enable signal for each word is generated through an AND gate: Thus, when the system is in AES mode ( )hour, ,only and It is a high level, therefore only and Able to follow Signal changes, and to Forced to be clamped to a low level, thus preventing any write operations to the region after the 128th bit of the register, dynamic hardware gating of the state boundary is realized. Through the above clarification of the data path reconstruction control signal generation path and the explanation of the specific hardware implementation of the write enable gating logic in the state boundary shielding mechanism, the key operating mechanism inside this technical solution is further clarified, proving its feasibility under the standard digital logic design flow, and ensuring the accuracy of function conversion and the integrity of state data when dynamically switching between different cryptographic tasks.
[0041] Example 6: In a dynamically switching hash and symmetric cryptography hybrid hardware acceleration system, as a data processing hardware module integrated into an edge computing device, upon first power-on or system reset, a standardized initialization and configuration procedure is executed. This procedure aims to bring the system's internal control logic, particularly the microcode configuration and control unit, into a known and functionally defined initial state, providing a starting point for subsequent data processing tasks. This procedure addresses potential issues such as undefined control states or incorrect configuration data loading during hardware system startup. The initialization procedure is triggered after the system reset signal is valid. First, the microcode configuration and control unit reads from an on-chip non-volatile memory unit, which can be a read-only memory (ROM). The system reads a preset configuration image table and parameter data from ROM or Flash Memory. These preset values are determined through offline design verification and hardware characterization phases. The configuration image table defines the mapping relationship between different cryptographic task types, in this case AES and SHA-3, and their corresponding internal configuration states, which can be represented by binary codes 01 and 10. The parameter data contains information associated with each configuration state, including the required state width value, in this case 128 bits and 1600 bits, and timing pattern information used to drive adaptive timing constraint logic. This read data is loaded into the working registers or state triggers inside the microcode configuration and control unit.
[0042] Next, the system executes a built-in self-test (BIST) sequence in which the microcode configuration and control unit is sequentially placed into its supported configuration states, first entering AES mode and then SHA-3 mode. In each state, the actual hardware level of its output function reconstruction signal, timing mode signal, and state boundary masking signal is compared by a built-in comparison logic with the expected reference value stored in the same non-volatile memory unit. If the outputs in all states are consistent with the expected values, the self-test passes. If an inconsistency is detected, an error status register is set. The state of this register can be read by the upper-layer system to determine whether to suspend subsequent operations or enter a preset security processing flow. After the self-test passes, the microcode configuration and control unit is set to a predefined default state, which can be an idle state or the system's default first cryptographic task type processing mode, ready to receive subsequent data processing requests. By executing such a standardized initialization loading and self-test process, the configuration state image, associated parameters, and state transition logic inside the microcode configuration and control unit are established and verified at system startup, avoiding subsequent functional errors or data processing anomalies that may be caused by uncertain initial hardware states.
[0043] Example 7: This example further illustrates the autonomous switching mechanism for data processing through embedded instructions in the data stream, demonstrating its operation in avoiding CPU software intervention latency. Consider a security scenario where the system is currently in AES mode, encrypting a series of continuously arriving data packets. At this time, the upstream data source (e.g., the DMA controller) needs to insert a SHA-3 hash verification task according to its descriptor chain. To achieve hardware-level autonomous switching, after the last AES data packet, the upstream data source generates and sends a special... The instruction packet contains a predefined instruction packet identifier in its header, such as a specific bit pattern, and its payload contains information about the target configuration state, such as binary code 10 representing switching to SHA-3 mode. The instruction packet is inserted into the data stream, immediately followed by the first data packet that needs to be checked for SHA-3 hashing. When the instruction packet arrives at the data input interface of this hardware acceleration system, the instruction packet detector at the interface identifies the special header within the current clock cycle through hardware pattern matching logic. After successful identification, the detector performs an interception action to prevent the instruction packet from flowing into the reconfigurable unified computing data path.
[0044] Simultaneously, a new configuration state information of 10 is extracted from the payload of the instruction packet. This extracted configuration state information is directly written into the status register inside the microcode configuration and control unit via a dedicated hardware signal line. In response to this hardware write event, the microcode configuration and control unit updates its internal configuration state to SHA-3 mode in the next clock cycle. Based on this new state, it outputs updated functional reconfiguration signals and timing mode signals in parallel, switching the reconfigurable unified computing data path to SHA-3 logic function and applying the multi-cycle path constraints corresponding to SHA-3 to the adaptive timing constraint logic. Since this switching process is completed entirely at the hardware level, bypassing time-consuming operations such as CPU software interrupts, scheduling, and MMIO (memory-mapped input / output) access, the switching latency is controlled within a few clock cycles. Therefore, when the first SHA-3 data packet following the instruction packet arrives at the reconfigurable unified computing data path, the path has already completed functional and timing preparation and can start processing directly.
[0045] 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 present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.
[0046] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.
Claims
1. A dynamically switching hardware acceleration system combining hashing and symmetric cryptography, characterized in that, The system includes: A unified state register is configured to store the computational state of a currently active cryptographic task; A reconfigurable unified computation data path is connected to the input and output of a unified state register. The reconfigurable unified computation data path physically integrates a computation logic with a first critical path duration for a first cryptographic task type and a computation logic with a second critical path duration for a second cryptographic task type, wherein the second critical path duration is longer than the first critical path duration. A microcode configuration and control unit is configured to store a configuration state indicating the type of currently active cryptographic task; An adaptive timing constraint logic, the microcode configuration and control unit is also configured to, in response to a change in configuration state, collaboratively perform the following operations: generate a functional reconfiguration signal to reconfigure the internal logic function of the reconfigurable unified computing data path to adapt it to the cryptographic task type corresponding to the configuration state; generate a timing pattern signal in parallel, the timing pattern signal corresponding to the critical path duration of the cryptographic task type corresponding to the configuration state; and the adaptive timing constraint logic is configured to: receive the timing pattern signal and, based on the timing pattern signal, set the execution path constraint of the reconfigurable unified computing data path in the data processing clock cycle to a first execution path constraint corresponding to a first critical path duration, or a second execution path constraint corresponding to a second critical path duration.
2. The dynamically switching hardware acceleration system for hash and symmetric cryptography according to claim 1, characterized in that, The configuration state further includes state width information required for the cryptographic task; the microcode configuration and control unit is also configured to: generate a state boundary masking signal based on the state width information; and use the state boundary masking signal to gate the write enable logic of the unified state register to prevent data of a cryptographic task with a narrow state width from being written into the area of the unified state register reserved for cryptographic tasks with a wide state width.
3. The dynamically switching hardware acceleration system for hash and symmetric cryptography according to claim 1, characterized in that, The system further includes a configuration stream cross-validation module, which is configured to: receive a first task type identifier corresponding to the configuration state from the microcode configuration and control unit; receive a second task type identifier associated with the input data stream from the system's data input interface; and determine a mismatch condition. Whether it is true or not, among which, , This serves as the identifier for the first task type. It serves as the identifier for the second task type; and, when the mismatch condition is met, it generates a control signal to abort the input data stream processing of the reconfigurable unified computing data path.
4. The dynamically switching hardware acceleration system combining hash and symmetric cryptography according to claim 1, characterized in that, The microcode configuration and control unit also includes a hardware-implemented execution context stack; the microcode configuration and control unit is also configured to: suspend the currently active cryptographic task upon receiving a preemption request signal, the currently active cryptographic task being defined as a low-priority task; Push the execution context of a low-priority task onto the execution context stack. The execution context includes the task type of the low-priority task and an execution round number. Then, execute a high-priority task associated with the preemption request signal. And after a high-priority task is completed, the execution context is popped from the execution context stack.
5. A dynamically switching hardware acceleration system combining hash and symmetric cryptography according to claim 1, characterized in that, The system further includes a command packet detector located at the system's data input interface and configured to: monitor the input data stream and identify a command packet by comparing the packet header of the input data stream with a preset command packet identifier; when a command packet is identified, intercept the command packet and extract a new configuration state from the payload of the command packet; and write the new configuration state directly into the microcode configuration and control unit to trigger a change in the configuration state.
6. A dynamically switching hardware acceleration system combining hash and symmetric cryptography according to claim 1, characterized in that, The reconfigurable unified computational data path includes: a shared linear path containing logic circuits configured to perform linear computational primitives common to multiple cryptographic tasks; a dedicated nonlinear path containing logic circuits configured to perform nonlinear computational primitives specific to each of multiple cryptographic tasks; wherein the microcode configuration and control unit is further configured to: store a configuration state for a basic integrity check; and, in the configuration state of the basic integrity check, reconfigure the logic circuits in the shared linear path.
7. A dynamically switching hardware acceleration system combining hash and symmetric cryptography according to claim 6, characterized in that, The microcode configuration and control unit is also configured to: store a configuration state for pseudo-random number generation; and, in the configuration state for pseudo-random number generation, reconstruct the logic circuit in the shared linear path so that it functionally implements the calculation of a linear feedback shift register, thereby generating pseudo-random numbers; The unified state register is used to store the current state of the linear feedback shift register.
8. A dynamically switching hardware acceleration system for hash and symmetric cryptography according to claim 6, characterized in that, The microcode configuration and control unit is also configured to: when the configuration state indicates a first cryptographic task type, use only the clock of the logic circuit in the gated dedicated nonlinear path for the second cryptographic task type; and when the configuration state indicates a second cryptographic task type, use only the clock of the logic circuit in the gated dedicated nonlinear path for the first cryptographic task type.
9. A dynamically switching hardware acceleration system combining hash and symmetric cryptography according to claim 1, characterized in that, The system further includes a data interface module, which is configured to: receive external data packets; compare the task type identifier contained in the metadata of the external data packets with the configuration status; and when the task type identifier and the configuration status are inconsistent, send a switching request signal to the microcode configuration and control unit to change the configuration status.
10. A dynamically switching hardware acceleration system combining hash and symmetric cryptography according to claim 1, characterized in that, The first execution path constraint is a single-cycle path constraint, and the second execution path constraint is a multi-cycle path constraint.
Citation Information
Patent Citations
Hardware accelerators and systems for hybrid encryption algorithms
CN109565438B