An automated design method and apparatus for FHE accelerator architecture

Abstract

This invention proposes an automated design method for FHE accelerator architectures. It proposes an architecture for automatically designing FHE hardware accelerators, accepting hardware parameters from an FHE application analysis model, including variable pipeline architectures and partitionable memory architectures. An FHE application analysis framework is established, capable of analyzing the structure and parameter information of FHE applications and inputting this parameter information into a parameterizable hardware architecture for automated design. Starting from the computation graph of the FHE application, the FHE application analysis framework establishes an analysis framework from the FHE application to the hardware acceleration architecture parameters, and obtains the hardware parameters quickly through an efficient search algorithm. Combining the FHE hardware acceleration architecture and the FHE application analysis framework results in a complete FHE acceleration framework based on automated design of FHE applications. The FHE hardware acceleration architecture is then automatically designed according to the FHE application.

Description

Technical Field

[0001] This invention relates to the field of fully homomorphic encryption technology, and particularly to an automated design method, apparatus, electronic device, computer-readable storage medium, and computer program product for FHE accelerator architecture. Background Technology

[0002] Fully homomorphic encryption (FHE), as a mainstream approach to privacy computing, enables arbitrary addition and multiplication operations on data while it is encrypted, allowing for complex computations without decryption. It offers extremely high security and versatility. Unlike traditional "use-and-decrypt" computing models, FHE allows computing service providers to perform calculations without knowing the plaintext data, significantly reducing the risk of data leakage.

[0003] However, the development of FHE still faces computational challenges, as its computational complexity is far higher than that of plaintext computation (3-5 orders of magnitude). The FHE process requires performing polynomial operations on a large modulus integer ring, involving complex key switching and bootstrapping operations, which are extremely time-consuming. Simultaneously, due to security requirements, the ciphertext key occupies a large storage space, leading to severe storage and communication pressure, further impacting system throughput. Low computational efficiency has become a key bottleneck restricting the widespread application of FHE.

[0004] To improve the practicality of FHE, academia and industry have extensively researched various acceleration methods in recent years, mainly focusing on algorithm-level optimization and hardware-level optimization. Hardware acceleration has become a key approach to overcoming performance bottlenecks. Current hardware optimization primarily concentrates on FPGA, ASIC, and GPU platforms. However, it currently suffers from the following technical shortcomings:

[0005] 1) Insufficient accelerator flexibility: The excessive pursuit of acceleration effects in certain application scenarios ignores the significant differences in encryption parameters, computational processes and storage requirements of FHE tasks in different application scenarios, which seriously affects the parameter adaptation and task generalization of the accelerator.

[0006] 2) Lack of hardware and software co-design: Pure hardware and software design cannot meet the diverse system requirements, while hardware and software co-design can better suit diverse applications. Summary of the Invention

[0007] This invention aims to solve the technical problem that existing fixed FHE acceleration architectures cannot efficiently run a wide variety of FHE applications. Specifically, it includes: how to design a hardware acceleration architecture that is equally efficient when there are significant differences in program flow structure in current FHE applications; how to use efficient algorithms to analyze the mapping from diverse FHE architectures to hardware parameterization; and how to design an efficient storage architecture that adapts to the changing storage requirements of FHE applications.

[0008] To address the shortcomings of existing technologies, this invention proposes an automated design method for FHE accelerator architectures, including:

[0009] Step 1: Obtain the FHE application and the FPGA hardware accelerator used to execute the FHE application; extract the data flow graph of the FHE application;

[0010] Step 2: Divide the interdependent nodes in the data flow graph into operator sequences, map the concurrently executable operator sequences to different candidate pipelines, map the execution order of operators in the operator sequence to the pipeline level order, and determine the number of PEs in the candidate pipeline based on the amount of data processed in parallel by the operators, so as to establish the initial value range and initial configuration N0, D0, P0 of the pipeline number N, depth D, and parallelism P.

[0011] Step 3: Start the simulated annealing search with N0, D0, P0 and a preset initial temperature T0, iteratively perturb the number of pipelines N, depth D, and parallelism P to obtain candidate configurations; calculate the application latency L, pipeline utilization, operator utilization, and PE unit utilization for each candidate configuration, and combine them to form the overall utilization rate U. Determine the merits of each candidate configuration based on the evaluation function of application latency L and overall utilization rate U; retain some non-optimal candidate configurations according to the annealing acceptance probability and gradually reduce the temperature, while deleting candidate configurations with higher latency and lower utilization, to obtain a non-dominated candidate set that meets the hardware constraints of the FPGA hardware accelerator.

[0012] Step 4: Select the computation configuration from the non-dominated candidate set according to the performance target of the FHE application, including the number of pipelines N, the depth of each pipeline D, the parallelism within the pipeline P, and the pipeline scheduling parameters of each operator configuration.

[0013] Step 5: Based on the pipeline scheduling parameters, the execution process of the FHE application is discretized into multiple time steps from 0 to Tmax. The three types of data for each time step are calculated. These three types of data include key data requirement data Skey(t), read-only data requirement data Sro(t), and read-write data requirement data Srw(t). The total on-chip storage capacity Smax of the FPGA hardware accelerator for these three types of data is obtained.

[0014] Step 6: Establish dynamic programming state functions FX(s,t) for the three types of data respectively. FX(s,t) represents the off-chip read bandwidth cost generated when allocating an on-chip capacity of size s for the corresponding data at time step t. For each time step and each candidate capacity, compare the cumulative costs of the current data being fully resident in BRAM and partially retained in HBM and update the state. Under the constraint that the size of the three types of data is less than or equal to the total on-chip storage capacity Smax, select the partition capacity with the minimum total off-chip read bandwidth cost and the corresponding data resident scheme as the storage configuration.

[0015] Step 7: Bind the pipeline scheduling parameters to the pipeline IP core of the FPGA hardware accelerator, and bind the partition capacity to the BRAM IP core of the FPGA hardware accelerator; Generate the connection relationships and control information between pipeline stages, pipelines, BRAM and HBM according to the data flow graph dependencies, as the connection configuration;

[0016] Step 8: Based on the computing configuration, storage configuration, and connectivity configuration, instantiate the RTL module of the FPGA hardware accelerator to form the computing cluster and storage subsystem of the FHE application in the FPGA hardware accelerator; generate the configuration bitstream using FPGA synthesis, placement and routing, and bitstream generation tools.

[0017] Step 9: Load the configuration bitstream into the target FPGA in the FPGA hardware accelerator; read the operation parameters and encrypted text information from the FPGA hardware accelerator into the HBM, and perform encrypted application calculations by the PE pipeline of the FPGA hardware accelerator. The BRAM and HBM are jointly responsible for caching the running data, and finally obtain the encrypted result for the user to decrypt, which serves as the execution result of the FHE application.

[0018] The automated design method for FHE accelerator architecture is described above. In the data flow graph, nodes represent FHE operators, and edges represent data dependencies between operators. Step 1 further includes: calculating the depth, width, number of operators, number of operator executions, and amount of parallel data of the data flow graph, and extracting the ciphertext polynomial degree, modulus bit width, computation level, ciphertext size, key size, and intermediate data size to form an application feature set.

[0019] The automated design method for the FHE accelerator architecture includes step 4, which includes: if the candidate configuration exceeds the hardware performance constraints of the FPGA in the FPGA hardware accelerator, then reduce the number of pipelines N, the depth of each pipeline D, and the parallelism within the pipeline P, and return to step 3 to continue the search.

[0020] The automated design method for FHE accelerator architecture, wherein step 3 includes:

[0021] Simulated annealing search is initiated with N0, D0, P0 and a preset initial temperature T0. The pipeline number N, depth D, and parallelism P are iteratively perturbed to obtain candidate configurations. For each candidate configuration, the application latency L, pipeline utilization, operator utilization, and PE utilization U are calculated, and the merits of each candidate configuration are judged based on the evaluation functions of application latency L and PE utilization U. According to the annealing acceptance probability, some non-optimal candidate configurations are retained and the temperature is gradually reduced. At the same time, candidate configurations with higher latency and lower utilization are deleted to obtain a non-dominated candidate set that meets the hardware constraints of the FPGA hardware accelerator.

[0022] The search starts with initial parameters N0, D0, P0 and initial temperature T0, and perturbs N, D and P to generate multiple candidate configurations. For each candidate configuration, the operator sequence is mapped to each pipeline according to the candidate depth, and the application execution is simulated according to the parallelism within the pipeline to obtain the latency L and hardware utilization U of the candidate configuration. The utilization can be statistically analyzed at the pipeline level, operator level and PE array level respectively. The PE array utilization can be obtained by the ratio of the number of effectively working PEs to the total number of configured PEs.

[0023] The evaluation function is F=log(1+β×U / L), where β represents the weight between delay and utilization. The search retains candidates with better evaluation and retains some temporarily poor candidates according to the simulated annealing acceptance probability. The temperature is gradually reduced according to the cooling coefficient. When there is no improvement after several consecutive iterations, β is adjusted and the search continues.

[0024] Furthermore, Pareto filtering is performed after each update of the candidate configuration: if a candidate configuration has both higher latency and lower utilization compared to another candidate configuration, it is deleted; the remaining candidates are non-dominated candidates.

[0025] This invention also proposes an automated design apparatus for FHE accelerator architectures, comprising:

[0026] Module 1: Obtain the FHE application and the FPGA hardware accelerator used to execute the FHE application; extract the data flow graph of the FHE application;

[0027] Module 2 divides the interdependent nodes in the data flow graph into operator sequences, maps concurrently executable operator sequences to different candidate pipelines, maps the execution order of operators in the operator sequence to pipeline order, and determines the number of PEs in the candidate pipeline based on the amount of data processed in parallel by the operators, so as to establish the initial value range and initial configuration N0, D0, P0 of the pipeline number N, depth D, and parallelism P.

[0028] Module 3 initiates a simulated annealing search with N0, D0, P0 and a preset initial temperature T0, iteratively perturbing the number of pipelines N, depth D, and parallelism P to obtain candidate configurations. For each candidate configuration, it calculates the application latency L, pipeline utilization, operator utilization, and PE unit utilization, and synthesizes them into a comprehensive utilization rate U. The merits of each candidate configuration are judged based on the evaluation function of application latency L and comprehensive utilization rate U. According to the annealing acceptance probability, some non-optimal candidate configurations are retained and the temperature is gradually reduced. At the same time, candidate configurations with higher latency and lower utilization are deleted to obtain a non-dominated candidate set that meets the hardware constraints of the FPGA hardware accelerator.

[0029] Module 4 selects the computation configuration from the non-dominated candidate set according to the performance objectives of the FHE application, including the number of pipelines N, the depth of each pipeline D, the parallelism within the pipeline P, and the pipeline scheduling parameters configured for each level of operator.

[0030] Module 5, based on the pipeline scheduling parameters, discretizes the execution process of the FHE application into multiple time steps from 0 to Tmax, calculates three types of data for each time step, including key data requirement data Skey(t), read-only data requirement data Sro(t), and read-write data requirement data Srw(t), and obtains the total on-chip storage capacity Smax of the FPGA hardware accelerator for these three types of data;

[0031] Module 6 establishes dynamic programming state functions FX(s,t) for the three types of data, where FX(s,t) represents the off-chip read bandwidth cost incurred when allocating an on-chip capacity of size s for the corresponding data at time step t. For each time step and each candidate capacity, the cumulative cost of the current data residing entirely in BRAM versus partially residing in HBM is compared and the state is updated. Under the constraint that the size of the three types of data is less than or equal to the total on-chip storage capacity Smax, the partition capacity with the minimum total off-chip read bandwidth cost and the corresponding data residency scheme are selected as the storage configuration.

[0032] Module 7 binds the pipeline scheduling parameters to the pipeline IP core of the FPGA hardware accelerator and binds the partition capacity to the BRAM IP core of the FPGA hardware accelerator; it generates the connection relationships and control information between pipeline stages, pipelines, BRAM and HBM according to the data flow graph dependencies, as the connection configuration;

[0033] Module 8 instantiates the RTL module of the FPGA hardware accelerator based on the computing configuration, storage configuration, and connectivity configuration, forming the computing cluster and storage subsystem of the FHE application within the FPGA hardware accelerator; and generates the configuration bitstream using FPGA synthesis, placement and routing, and bitstream generation tools.

[0034] Module 9 loads the configuration bitstream into the target FPGA in the FPGA hardware accelerator; the operation parameters and encrypted text information are read from the FPGA hardware accelerator into the HBM, and the PE pipeline of the FPGA hardware accelerator performs the calculation of the encrypted application. The BRAM and HBM are jointly responsible for caching the data during operation, and finally obtain the encrypted result for the user to decrypt, which serves as the execution result of the FHE application.

[0035] The automated design device for FHE accelerator architecture is described above. In the data flow graph, nodes represent FHE operators, and edges represent data dependencies between operators. The module 1 also includes: calculating the depth, width, number of operators, number of operator executions, and amount of parallel data of the data flow graph, and extracting the ciphertext polynomial degree, modulus bit width, computation level, ciphertext size, key size, and intermediate data size to form an application feature set.

[0036] The automated design apparatus for the FHE accelerator architecture, wherein module 4 includes: if the candidate configuration exceeds the hardware performance constraints of the FPGA in the FPGA hardware accelerator, then reduce the number of pipelines N, the depth of each pipeline D, and the parallelism within the pipeline P, and return to module 3 to continue the search.

[0037] Module 3 includes:

[0038] Simulated annealing search is initiated with N0, D0, P0 and a preset initial temperature T0. The pipeline number N, depth D, and parallelism P are iteratively perturbed to obtain candidate configurations. For each candidate configuration, the application latency L, pipeline utilization, operator utilization, and PE utilization U are calculated, and the merits of each candidate configuration are judged based on the evaluation functions of application latency L and PE utilization U. According to the annealing acceptance probability, some non-optimal candidate configurations are retained and the temperature is gradually reduced. At the same time, candidate configurations with higher latency and lower utilization are deleted to obtain a non-dominated candidate set that meets the hardware constraints of the FPGA hardware accelerator.

[0039] The search starts with initial parameters N0, D0, P0 and initial temperature T0, and perturbs N, D and P to generate multiple candidate configurations. For each candidate configuration, the operator sequence is mapped to each pipeline according to the candidate depth, and the application execution is simulated according to the parallelism within the pipeline to obtain the latency L and hardware utilization U of the candidate configuration. The utilization can be statistically analyzed at the pipeline level, operator level and PE array level respectively. The PE array utilization can be obtained by the ratio of the number of effectively working PEs to the total number of configured PEs.

[0040] The evaluation function is F=log(1+β×U / L), where β represents the weight between delay and utilization. The search retains candidates with better evaluation and retains some temporarily poor candidates according to the simulated annealing acceptance probability. The temperature is gradually reduced according to the cooling coefficient. When there is no improvement after several consecutive iterations, β is adjusted and the search continues.

[0041] Furthermore, Pareto filtering is performed after each update of the candidate configuration: if a candidate configuration has both higher latency and lower utilization compared to another candidate configuration, it is deleted; the remaining candidates are non-dominated candidates.

[0042] The present invention also proposes an electronic device, including the aforementioned automated design apparatus for FHE accelerator architecture, wherein the electronic device may be connected to an information display device, the information display device being used to display the execution result with user-set display parameters, attributes or through an artificial intelligence model.

[0043] The present invention also proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the automated design method for the FHE accelerator architecture.

[0044] The present invention also proposes a computer program product comprising a computer program, wherein the computer program, when executed by a processor, implements the steps of the automated design method for the FHE accelerator architecture.

[0045] As can be seen from the above solutions, the advantages of the present invention are:

[0046] Improved performance of the FHE hardware accelerator: From the perspective of FHE applications, the performance of the FHE hardware accelerator when running different FHE applications has been significantly improved.

[0047] Improved hardware utilization of the FHE hardware accelerator: While improving hardware performance, it reduced resource usage and improved hardware utilization.

[0048] Integrated hardware and software co-design framework: The designed acceleration framework includes parameterizable hardware units and efficiently searchable software algorithms, which can efficiently integrate to obtain a high-performance computing architecture according to the application. Attached Figure Description

[0049] Figure 1 This is a schematic diagram of the software and hardware collaborative framework and hardware architecture for the automated design of an FHE accelerator based on FHE applications, as described in this invention.

[0050] Figure 2 This is a schematic diagram of the structure of the first electronic device of the present invention;

[0051] Figure 3This is a schematic diagram of the application environment structure of the first electronic device of the present invention;

[0052] Figure 4 This is a schematic diagram of the structure of the second electronic device of the present invention.

[0053] Figure label:

[0054] A - First electronic device;

[0055] B - An automated design device for FHE accelerator architecture;

[0056] C-Data acquisition equipment;

[0057] D-Information display device;

[0058] 1000 - Second electronic device;

[0059] Ⅰ-Computational Unit;

[0060] II-ROM;

[0061] III-RAM;

[0062] N-bus;

[0063] V-Interface;

[0064] VI - Input Unit;

[0065] VII - Output Unit;

[0066] VIII - Storage medium;

[0067] IX - Communication Unit. Detailed Implementation

[0068] It should be noted that, in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0069] In the absence of further restrictions, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0070] The processor described in this invention is the control center of an electronic device. It can be a single processor or a collective term for multiple processing elements. For example, it can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of this invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0071] Alternatively, the processor can perform various functions of the electronic device by running or executing software programs stored in memory and by calling data stored in memory.

[0072] In a specific implementation, as one example, the processor may include one or more CPUs. Each of these processors may be a single-core processor or a multi-core processor. Here, "processor" can refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions). Electronic devices may include servers, desktop computers, laptops, smartphones, tablets, embedded computers, etc., where the embedded computer includes vehicles and robots, etc.

[0073] The memory is used to store the software program that executes the solution of the present invention, and the execution is controlled by the processor. For specific implementation methods, please refer to the above method embodiments, which will not be repeated here.

[0074] It should be noted that the structure of the electronic device shown in the accompanying drawings of this invention does not constitute a limitation thereof. The actual knowledge structure recognition device may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0075] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0076] It should also be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0077] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0078] It should also be understood that, in various embodiments of the present invention, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0079] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0080] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0081] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0082] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0083] During their research on hardware-accelerated FHE, the inventors discovered that the reconfigurable nature of FPGAs allowed for flexible adjustments to the FHE accelerator, enabling the design of a relatively efficient FHE hardware acceleration architecture across various FHE applications. Through in-depth analysis, the inventors realized that the fundamental problem lay in the lack of an FHE acceleration framework that could integrate the analysis of FHE application characteristics with the design of corresponding hardware acceleration architectures through a hardware-software collaborative approach.

[0084] Traditional FHE hardware acceleration architectures cannot flexibly adjust their hardware architecture based on the different types of applications running. To address this, the inventors have proposed a novel FHE acceleration architecture. Its core technology lies in introducing the concept of Automated Design, establishing a complete process from FHE application analysis to generating the FHE hardware acceleration architecture. This ensures high performance across various FHE application scenarios.

[0085] To achieve the above-mentioned technical effects, the present invention proposes the following key technical points:

[0086] Key Point 1: Build an architecture for an automated FHE hardware accelerator, including both compute and storage architectures. The key is to construct a parameterizable hardware architecture that accepts hardware parameters from the FHE application analysis model, including variable pipeline architectures and partitionable storage architectures.

[0087] Key Point 2: Establishing an FHE Application Analysis Framework. This framework can analyze the structure and parameter information of FHE applications, inputting this parameter information into a parameterizable hardware architecture for automated design. Starting from the computational graph of the FHE application, the framework establishes an analysis framework from the FHE application to the hardware acceleration architecture parameters, and quickly obtains the hardware parameters through an efficient search algorithm.

[0088] Key Point 3: This system combines the FHE hardware acceleration architecture and the FHE application analysis framework through hardware and software co-processing technology, forming a complete FHE acceleration framework based on automated FHE application design. The FHE hardware acceleration architecture is automatically designed according to the FHE application.

[0089] To make the above-mentioned features and effects of the present invention clearer and easier to understand, specific embodiments are described below in conjunction with the accompanying drawings. This specification discloses one or more embodiments incorporating the features of the present invention. The disclosed embodiments are merely illustrative. The scope of protection of the present invention is not limited to the disclosed embodiments, but is defined by the appended claims.

[0090] The specific embodiments of the present invention will be further described in conjunction with the accompanying drawings. For example... Figure 1 As shown, this invention adopts a hardware and software co-design approach.

[0091] Hardware Architecture: The hardware architecture primarily involves microarchitecture design and overall architecture design. The microarchitecture design employs configurable multi-operator functional modules, using these modules as the core of the Processing Element (PE) unit, allowing for flexible pipeline construction based on the FHE application's data flow graph and operator dependencies. Architecturally, a variable pipeline architecture and a partitionable storage architecture are designed. The overall operation of this invention involves first inputting the FHE application, then the software collaboration side accepting the FHE application from the user, followed by the built-in FHE application analysis framework automatically analyzing the FHE application's structure and parameters, and finally, merging this information with the parameter interface provided by the hardware side. Specifically:

[0092] like Figure 1 As shown, the present invention design includes hardware architecture components B(1), B(2), B(3) and software collaboration components A(1), A(2), A(3), A(4).

[0093] like Figure 1 As shown in B(1) to B(3), the hardware architecture is implemented using a Field Programmable Gate Array (FPGA), which mainly includes a computing cluster and a storage subsystem. The computing cluster is used to perform polynomial and ciphertext operations in FHE applications, and the storage subsystem is used to store the key data, input data, intermediate data and output data required for the operation. The computing cluster reads the data to be processed and the operation parameters from the storage subsystem, and writes the intermediate results or final results generated by each pipeline stage back to the storage subsystem.

[0094] like Figure 1 As shown in B(1), this represents a variable pipelined computing architecture and a partitionable storage architecture (unparalleled); Figure 1 As shown in B(3), this is the final architecture of the complete computing cluster and storage module generated after receiving parameters from A(1)-A(4).

[0095] A computing cluster consists of one or more parameterized pipelines, each of which can be implemented as a synthesizable RTL module or IP core. Configurable pipeline parameters include at least the number of pipelines N, pipeline depth D, operator types for each pipeline stage, and parallelism P within the pipeline. Pipeline depth, also known as length, refers to the number of pipeline stages (X stages of pipeline). For example, a pipeline IP core can be configured with pipeline_length, pipeline_depth, and parallelism parameters. After the software collaboration side obtains these parameters, it writes them into the corresponding RTL module or IP core, thereby instantiating pipelines with different numbers, depths, operator orders, and parallelism.

[0096] The storage subsystem may include on-chip Block Random Access Memory (BRAM) and High Bandwidth Memory (HBM), which together form a data exchange path of "Computation Cluster-Register-BRAM-HBM" with registers and the computing cluster. BRAM, located near the computing cluster, stores frequently accessed data and provides low-latency, high-bandwidth data access to each pipeline. HBM stores large amounts of data not residing in BRAM. BRAM can be divided into a key area, a read-only data area, a read-write data area, and an unused area according to the data type and lifecycle in the target FHE application. The key area stores computing or evaluation keys that need to be continuously used during FHE computation; the read-only data area stores input data or data that is not modified during execution; the read-write data area stores intermediate results generated by each pipeline stage and consumed by subsequent pipeline stages; and the unused area is the remaining space after allocating the first three types of areas. The storage IP core can be configured with capacity parameters such as key, input, and read_write, and the size of each partition is determined based on the storage partition parameters output by the software collaboration side, avoiding the long-term occupation of limited BRAM space by data with short lifecycles or low access frequency.

[0097] The hardware architecture receives pipeline configuration parameters and storage partition parameters from the software collaboration side, and also receives the ciphertext, key, modulus, and operation coefficients required to execute FHE applications. An exemplary data flow is as follows: data is read from HBM or BRAM to a register file, sent to a PE configured with the corresponding operator function via a multiplexer, the result is temporarily stored in a local buffer and sent to the next processing stage, and finally, the intermediate result or ciphertext of the result is written back to BRAM or HBM. Therefore, while keeping the multi-operator PE and parameterized IP core template essentially unchanged, by changing the number, depth, parallelism, and storage partition parameters of the pipeline, corresponding computing clusters and storage architectures can be generated for different FHE applications.

[0098] like Figure 1 As shown in B(2), this is the microarchitecture design of the present invention, whose main function is to realize the calculation of various FHE operators.

[0099] Each pipeline can be composed of an array of processing units (PEs). Multiple PEs cascaded along the data dependency direction constitute multiple processing stages of the pipeline, and multiple PEs arranged side-by-side in the same processing stage constitute parallel computing channels. The PE array may include a register file, input multiplexers, arithmetic data paths, local buffers, and output multiplexers. The register file is used to store and distribute operands a, b, modulus q, twiddle factors, or other operational coefficients c to the PEs; the input multiplexers are used to select inputs from the register file, the previous stage output, and the local buffer buf according to the operator configuration of the current processing stage; the local buffers are used to temporarily store intermediate results, decouple data transmission between adjacent processing stages, and provide data feedback paths for operators that require feedback read / write; the output multiplexers are used to send the results a′, b′ generated by the PEs to the next PE stage, write them back to the local buffer, or send them to the storage subsystem.

[0100] The PE employs a multi-operator function module, integrating multiple FHE operator functions within the same configurable data path. These functions may include: ① Modular addition (MA) and modular subtraction (MS), used to perform addition or subtraction on inputs a and b within the residual class ring defined by the modulus q, yielding a′=(a+b) mod q or a′=(ab) mod q respectively; ② Modular multiplication (MM), used to perform modular multiplication, for example, obtaining a′=(b×c) mod q from input b and coefficient c; ③ Number theory transformation (NTT) and inverse number theory transformation (INTT), used to convert between the coefficient representation and the number theory transformation representation of a polynomial. The NTT butterfly operation yields a′=(a+b×c) mod q and b′=(ab×c) mod q, while the INTT butterfly operation yields a′=(a+b) mod q and b′=((ab)×c) mod q. q; ④ Basis conversion function BConv, used to convert data represented by one modular basis of the residue system into data represented by another modular basis. It can multiply the input residue with the conversion coefficient and accumulate it to the local buffer. For example, it can execute buf←buf+b×c, while allowing one input data to continue to be passed; ⑤ Auto-isomorphism function Auto, used to map or rearrange polynomial coefficients using the read, write and feedback paths of the local buffer. It can form a′=a×c+b and b′=b×c+a according to the input a, b and coefficient c, and write a′ and / or b′ into the buffer; ⑥ Buffered output function, used to directly output the results already in the local buffer to the next processing stage or storage subsystem.

[0101] The above-described functionalities represent the division of the PE array's logic functions. At the underlying level, they can share modular multipliers, modular adders / subtractors, multiplexers, registers, and buffers, without requiring a fixed and independent dedicated pipeline for each operator. By changing the control signals, the same multi-functional computing unit can be configured to execute one of the following functions—MA, MS, MM, NTT, INTT, BConv, or Auto—at different processing times. The output of the preceding PE stage can also be directly transmitted to the following PE stage or fed back to the local buffer via a multiplexer. Therefore, the same microarchitecture can adapt to the different operator sequences included in different FHE applications and provide a unified hardware foundation for subsequent application-specific pipeline construction.

[0102] like Figure 1 As shown in A(1) to A(4), corresponding configuration parameters are generated to analyze the application characteristics of FHE.

[0103] As shown in Figures A(1)-A(2), when constructing the pipeline, the software collaboration side extracts the sequence of operators with execution dependencies from the data flow graph of the FHE application, maps the sequential dependencies between operators to the processing level order in the pipeline, maps the concurrently executable operator sequence to different pipelines, and maps the data that can be processed in parallel within the same operator to multiple PEs in the same processing level. As shown in Figure A(4), if the pipeline depth is too large and the amount of input data is insufficient, pipeline cavitation and idle hardware may occur, while if the depth is too small, the throughput may be reduced; if the parallelism is too high, some PEs may be idle due to insufficient workload, while if the parallelism is too low, a performance bottleneck may be formed. Therefore, N, D, and P are searched according to the data flow graph characteristics of the target application and the FPGA resource constraints, rather than simply taking the maximum value of each parameter. The data flow graph characteristics are based on the computational characteristics of the application, dividing the application into the horizontal and vertical scale of a directed acyclic graph composed of FHE operators (MA, MM, NTT, INTT, BConv, etc.), and the operator sequence divided by the interdependent nodes in the graph.

[0104] As shown in Figure A(4), combined with the above hardware design section, the parameters are embedded into the designed IP core, which is a parameterized hardware architecture template, to realize the automated design of FHE hardware accelerator.

[0105] The "variable pipeline architecture" refers to the fact that the pipeline organization of the computing cluster is not fixed in advance during design. Instead, it uses parameterized pipeline IP cores as templates and changes the number of pipelines N, pipeline depth D, and intra-pipeline parallelism P based on the data flow graph and encryption parameters of the FHE application to be executed. Therefore, different FHE applications can obtain different pipeline instances. For example, a shallow and wide data flow graph can be configured with more shallow pipelines, while a deep and narrow data flow graph can be configured with fewer but deeper pipelines. PEs in the same pipeline stage can also select functions such as MA, MM, NTT, INTT, BConv, or Auto according to operator configuration parameters. The "variable" aspect mainly indicates that the hardware architecture can be customized according to the application during the application mapping and hardware generation stages, rather than requiring the same generated hardware to arbitrarily change its physical structure in each clock cycle.

[0106] Compared to existing manually designed FHE accelerators, current architectures typically have fixed pipeline numbers, stages, parallelism, and dedicated data paths for a specific high-frequency operator or workload. While some architectures allow individual computational units to switch between a limited number of operators, the overall pipeline organization remains fixed. When the depth, width, operator ratio, ciphertext polynomial degree, or key size of the target application's data flow graph changes, fixed pipelines are prone to issues such as idle operator units, pipeline bubbling, insufficient parallel resources, or over-provisioning. This application, however, starts from the application's data flow graph and simultaneously searches for N, D, P, and operator configurations, coordinating them with storage partition parameters to ensure that the generated computing cluster matches the target application's operator dependencies, parallelizable workload, and data size.

[0107] The variable pipeline process in this application and the reconfigurable process of the FPGA device itself belong to different levels and are not the same. FPGA reconfigurability is a hardware-level capability, meaning that the logic implemented by lookup tables, registers, and programmable interconnects can be changed by loading configuration bitstreams; this capability itself does not analyze the FPGA application, nor does it automatically determine how many pipelines should be set up, which operators each pipeline contains, how many parallel PEs are needed, and how to partition the BRAM. The process in this application belongs to the architecture decision and automatic generation layer: first, the software collaborative side analyzes the application and searches for architecture parameters, then binds the parameters to parameterized RTL / IP cores to generate the target computing cluster and storage architecture, and finally, the architecture can be implemented on the device using conventional FPGA synthesis, placement and routing, and bitstream loading processes.

[0108] FHE applications include privacy information retrieval applications and neural network inference applications. Privacy inference applications employ Privacy Set Intersection (PSI) and Private Information Retrieval (PIR). In PSI, different participants each hold a set of encrypted identifiers or data items. The server calculates the intersection without knowing the plaintext of the sets, and the result can be used for privacy-protected user matching, blacklist verification, or joint risk control. In PIR, users encrypt their query conditions or keywords and submit them to the database server. The server performs a search on the database without knowing the user's specific query content and returns encrypted matching records or results.

[0109] The second type of example used in this invention is encrypted neural network inference, including multilayer perceptrons (MLPs) and ResNet-20. The client can encrypt feature vectors or images and send them to the inference server. The server performs neural network calculations without obtaining the plaintext features or images, returning encrypted classification scores. The client decrypts the data to obtain the classification result. For example, ResNet-20 can be used to classify CIFAR-10 encrypted images.

[0110] The application analysis framework receives application information that can include at least two types of parameters. The first type is computational structure parameters, including the type and number of operator nodes in the FHE application data flow graph, data dependencies between operators, maximum depth of the data flow graph, average width, the data size that each operator can process in parallel, and the number of executions for different operator sequences. The second type is encryption and data parameters, including the ciphertext polynomial degree, modulus bit width or modulus chain information, maximum computation level, ciphertext size, key size, and the amount of intermediate data generated at each stage. The application analysis framework also receives resource constraints such as the available LUT, FF, DSP, BRAM capacity, HBM capacity, or bandwidth on the FPGA to eliminate candidate configurations that cannot be implemented on the target device.

[0111] In the computational structure analysis, the data flow graph of the FHE application is first traversed, and operator nodes with dependencies are decomposed into several operator sequences. Then, based on whether the sequences can be executed concurrently, different sequences are assigned to different candidate pipelines. The depth of the candidate pipeline is determined based on the number of consecutive operators and the dependency span of each sequence, and the parallelism within the pipeline is determined based on the number of ciphertext coefficients or data items that can be processed simultaneously within each operator sequence. This transforms the data flow graph characteristics of the application layer into the number of searchable pipelines N, depth D, parallelism P, and configuration parameters of operators at each level at the hardware layer.

[0112] The computational architecture parameters employ a heuristic search based on simulated annealing and Pareto optimal selection. The search starts with initial parameters N0, D0, P0, and an initial temperature T0, perturbing N, D, and P to generate candidate configurations. For each candidate configuration, the operator sequence is mapped to each pipeline according to a preset candidate depth, and application execution is simulated considering pipeline parallelism to obtain the latency L and hardware utilization U of the candidate configuration. Utilization can be statistically analyzed at the pipeline level, operator level, and PE array level. PE array utilization can be obtained as the ratio of the number of effectively working PEs to the total number of configured PEs.

[0113] The evaluation function can be F=log(1+β×U / L), where β represents the weight between latency and utilization. The search retains candidates with better evaluations and some temporarily poor candidates are retained according to the simulated annealing acceptance probability to avoid prematurely falling into local optima; the temperature is gradually decreased according to the cooling coefficient. When there is no improvement after several consecutive iterations, β is adjusted and the search continues. After each update of the candidate set, Pareto filtering is performed: if a candidate has both higher latency and lower utilization than another candidate, it is deleted; the remaining candidates are non-dominated candidates. Finally, a set of pipeline parameters that balances low latency, high utilization, and resource constraints is obtained.

[0114] In the storage requirement analysis, the application execution process is divided into multiple time steps based on the computation scheduling results, and the key data requirement Skey(t), read-only data requirement Sro(t), and read / write data requirement Srw(t) for each time step are calculated. Key data typically persists throughout the FHE computation, read-only data is mainly read during the input or program start phase, and read / write data is generated by the previous pipeline stage and consumed by subsequent pipeline stages. Given the total on-chip storage capacity Smax, a state function FX(s,t) is established for each type of data, representing the off-chip read bandwidth cost incurred when allocating capacity s at time step t due to failure to reside on-chip. Dynamic programming compares the two options of "residing the current data in BRAM" and "retaining some data in HBM and bearing the off-chip read cost" at each time step, recursively obtaining the minimum bandwidth cost for each type of data; then, under the constraint sa+sb+sc≤Smax, the three types of states are combined to select the key area, read-only area, and read / write area capacities sa, sb, and sc with the minimum total off-chip read bandwidth cost.

[0115] The above analysis ultimately outputs computational architecture parameters and storage partition parameters. For example, on an FPGA platform, it yields 4 pipelines, depth 1, and parallelism 64 for PSI; 2 pipelines, depth 1, and parallelism 32 for PIR; 1 pipeline, depth 1, and parallelism 128 for MLP; and 1 pipeline, depth 2, and parallelism 128 for ResNet-20. It also yields the key area, read-only area, and read-write area capacities for each application. This indicates that the analysis results are not a general "suitable for a specific application," but rather provide the number of pipelines, pipeline length, parallelism, and BRAM partition capacity that can be directly written to parameterized IP cores.

[0116] The "merging" process referred to in this article is not simply splicing two existing files together, but rather a process of converting application analysis results into hardware parameters and mapping, verifying, and binding them with parameterized hardware templates. Specifically, this may include: converting the searched N, D, and P parameters into the pipeline_num, pipeline_length, and parallelism parameters for each pipeline IP core; converting the dynamic programming parameters sa, sb, and sc into the key, input, and read_write parameters for the BRAM IP core; generating connections between pipeline stages, between each pipeline and the BRAM, and between the BRAM and HBM based on operator dependencies; checking whether the DSP, LUT, FF, BRAM capacity, data bandwidth, and pipeline dependencies meet the target FPGA constraints; if not, feeding back the excess information to the parameter search process and reselecting candidate parameters; if satisfied, fixing the parameters and generating a hardware instance.

[0117] Conventional FPGA synthesis tools can synthesize, place and route, and generate bitstreams from a defined RTL, but they typically do not automatically search for N, D, and P based on the FHE application's data flow graph and encryption parameters, nor do they automatically determine BRAM partitions based on the three data lifecycles. Therefore, this application can directly use existing synthesis, placement and routing, and bitstream loading tools to complete the final implementation steps. However, the application feature extraction, calculation and storage parameter search, and parameter-to-hardware interface integration process constitute the application-driven automated design flow of this application. This flow matches the generated pipeline with the dependencies and parallel workload of the target application, reduces pipeline dangling and idle PEs, and prioritizes the storage of continuously used or frequently accessed data in the limited BRAM, thereby reducing off-chip access bandwidth and execution latency, and improving hardware utilization.

[0118] Searching for hardware parameters: The application analysis framework on the software collaboration side analyzes the structure and parameters of the FHE application using the following algorithm:

[0119] 1) Computational architecture: a heuristic search algorithm based on simulated annealing and Pareto non-dominated screening;

[0120] 2) Storage partitioning: a dynamic programming algorithm based on data lifecycle and off-chip read bandwidth cost.

[0121] The search yielded the computing architecture and storage partitioning architecture parameters under the aforementioned FHE hardware acceleration architecture template.

[0122] Parameter integration into architecture: Parameters are embedded into the pre-written IP cores, which are the parameterizable computing and storage architectures mentioned above.

[0123] Architecture generation: Generate the complete FHE accelerator hardware architecture.

[0124] Furthermore, the present invention also provides an automatic generation method for accelerator architecture based on FHE applications. This method can be jointly implemented by a software collaboration side and a parameterized hardware template, and may include the following steps:

[0125] The inputs to this method include: FHE application description information, FHE encryption parameters, hardware resource constraints of the target FPGA, and parameterized RTL / IP core templates. The FHE application description information includes the operator dataflow graph, operator type, operator dependencies, and data size; the FHE encryption parameters include the ciphertext polynomial degree, modulus or modulus chain, computation level, ciphertext size, and key size; the hardware resource constraints include available LUT, FF, DSP, BRAM capacity, HBM capacity or bandwidth, and the allowed number, depth, and parallelism range of pipelines.

[0126] The output of this method is the hardware architecture configuration or reconfiguration information of the target FPGA, including at least the number of pipelines N, the depth of each pipeline D, the pipeline operator configuration, the parallelism within the pipeline P, the BRAM key area capacity key, the read-only data area capacity input, the read-write data area capacity read_write, and the corresponding data connection and control configuration; furthermore, parameterized RTL, synthesized netlist, or configuration bitstream for loading by the target FPGA can be generated based on these parameters.

[0127] Step S1: Extract application features. Read the target FHE application and establish a data flow graph G=(V,E), where node V represents FHE operators such as MA, MM, NTT, INTT, BConv, or Auto, and edge E represents data dependencies between operators. Analyze the depth, width, number of operators, number of operator executions, and parallelizable data volume of the data flow graph, and extract the ciphertext polynomial degree, modulus bit width, computation level, ciphertext size, key size, and intermediate data size to form an application feature set.

[0128] Step S2: Establish candidate mappings from application to hardware. Following the data dependency traversal G, interdependent nodes are divided into operator sequences. Concurrently executable operator sequences are mapped to different candidate pipelines. The execution order of operators within the operator sequences is mapped to pipeline sequence. The number of PEs within a candidate pipeline is determined based on the amount of data that the same operator can process in parallel, thereby establishing the initial value ranges and initial configurations of N, D, and P, N0, D0, and P0.

[0129] Step S3: Search and compute architecture parameters. Initiate a simulated annealing search with N0, D0, P0 and an initial temperature T0, iteratively perturbing N, D, and P. Perform cycle-level or equivalent timing simulations for each candidate configuration, calculating application latency L, pipeline utilization, operator utilization, and PE utilization U. Determine the candidate's merits based on an evaluation function that considers both L and U. Retain some non-optimal candidates according to the annealing acceptance probability and gradually decrease the temperature, while removing Pareto-dominated candidates with higher latency and lower utilization, resulting in a set of non-dominated candidates that satisfy resource constraints.

[0130] Step S4: Determine the computation configuration. Select a computation configuration from the non-dominated candidate set according to the performance objectives of the target application, outputting the number of pipelines N, the depth of each pipeline D, the parallelism within the pipeline P, and the configuration of operators at each stage. If a candidate configuration exceeds the constraints of the target FPGA's LUTs, FFs, DSPs, or BRAMs, narrow down the corresponding parameter range (N, P, D) and return to step S3 to continue the search. The narrowed parameters are N, P, and D, which represent the hardware resource scale of the accelerator.

[0131] Step S5: Establish the storage requirement sequence. Based on the pipeline schedule determined in step S4, the execution process of the FHE application is discretized into multiple time steps from 0 to Tmax. The key data requirement Skey(t), read-only data requirement Sro(t), and read-write data requirement Srw(t) for each time step are calculated, and the total on-chip storage capacity Smax available for the target FPGA for the above three types of data is obtained. Tmax represents the range of time points. Based on the operator sequence generated by the computation graph, the execution status of the operator sequence is determined by the operator sequence and the parameters of the computation cluster. Then, the operator sequence is divided into operator sequences executed according to time, resulting in the time execution sequence of the operator sequence. The maximum execution time Tmax is obtained based on the time execution sequence.

[0132] Step S6: Search for storage partitions. Establish dynamic programming state functions FX(s,t) for the three types of data, where each value represents the off-chip read bandwidth cost incurred when allocating s on-chip capacity to the corresponding data at time step t. For each time step and each candidate capacity, compare the cumulative costs of the current data residing entirely in BRAM and partially in HBM, and update the state accordingly. Under the constraint sa+sb+sc≤Smax, combine the three states of key, read-only, and read-write, and select the partition capacities sa, sb, and sc with the minimum total off-chip read bandwidth cost, along with the corresponding data residency scheme.

[0133] Step S7: Perform parameter merging. Bind N, D, P, and operator configurations to the pipeline_num, pipeline_length, parallelism, and operator configuration parameters of the pipeline IP core, respectively. Bind sa, sb, and sc to the key, input, and read_write parameters of the BRAM IP core. Generate the connection relationships and control information between pipeline stages, pipelines, BRAM, and HBM according to the data flow graph dependencies. Then check resource usage, storage capacity, data bandwidth, and dependency timing. If the check fails, the over-limit or conflict information is fed back to step S3 or step S6 for a re-search. If the check passes, fix the hardware configuration.

[0134] Step S8: Generate hardware reconfiguration information. Based on fixed compute, storage, and connectivity configurations, instantiate parameterized RTL modules to form the compute cluster and storage subsystem corresponding to the target FHE application. Generate a configuration bitstream using FPGA synthesis, placement and routing, and bitstream generation tools, and output at least one of the following: pipeline configuration, BRAM partitioning configuration, connectivity control information, and configuration bitstream, as the hardware architecture configuration or reconfiguration information for the target FPGA.

[0135] like Figure 1 As shown in section A(4), the unparalleled computation, storage, and connectivity configurations can be understood as IP cores without parameters (RTL form). This part constitutes a complete computation cluster, storage unit, and communication connection unit. Then, through the parameter search method described above, the computation parameters and storage parameters are searched out and passed into the IP cores to form a complete accelerator architecture, which is a complete RTL circuit. Then, synthesis, placement and routing, and bitstream generation are performed.

[0136] Step S9: Configure and execute the FHE application. Load the configuration bitstream generated in step S8 into the target FPGA, or write the architecture configuration parameters into a hardware instance that supports parameter configuration; load the ciphertext, key, and operation coefficients into HBM or BRAM, and have the configured multi-operator PE pipeline perform FHE calculations according to the data flow graph, and write the intermediate ciphertext and result ciphertext back to the storage subsystem, finally outputting the result ciphertext for user decryption.

[0137] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiments.

[0138] This invention also proposes an automated design apparatus for FHE accelerator architectures, comprising:

[0139] Module 1: Obtain the FHE application and the FPGA hardware accelerator used to execute the FHE application; extract the data flow graph of the FHE application;

[0140] Module 2 divides the interdependent nodes in the data flow graph into operator sequences, maps concurrently executable operator sequences to different candidate pipelines, maps the execution order of operators in the operator sequence to pipeline order, and determines the number of PEs in the candidate pipeline based on the amount of data processed in parallel by the operators, so as to establish the initial value range and initial configuration N0, D0, P0 of the pipeline number N, depth D, and parallelism P.

[0141] Module 3 initiates a simulated annealing search with N0, D0, P0 and a preset initial temperature T0, iteratively perturbing the number of pipelines N, depth D, and parallelism P to obtain candidate configurations. For each candidate configuration, it calculates the application latency L, pipeline utilization, operator utilization, and PE unit utilization, and synthesizes them into a comprehensive utilization rate U. The merits of each candidate configuration are judged based on the evaluation function of application latency L and comprehensive utilization rate U. According to the annealing acceptance probability, some non-optimal candidate configurations are retained and the temperature is gradually reduced. At the same time, candidate configurations with higher latency and lower utilization are deleted to obtain a non-dominated candidate set that meets the hardware constraints of the FPGA hardware accelerator.

[0142] Module 4 selects the computation configuration from the non-dominated candidate set according to the performance objectives of the FHE application, including the number of pipelines N, the depth of each pipeline D, the parallelism within the pipeline P, and the pipeline scheduling parameters configured for each level of operator.

[0143] Module 5, based on the pipeline scheduling parameters, discretizes the execution process of the FHE application into multiple time steps from 0 to Tmax, calculates three types of data for each time step, including key data requirement data Skey(t), read-only data requirement data Sro(t), and read-write data requirement data Srw(t), and obtains the total on-chip storage capacity Smax of the FPGA hardware accelerator for these three types of data;

[0144] Module 6 establishes dynamic programming state functions FX(s,t) for the three types of data, where FX(s,t) represents the off-chip read bandwidth cost incurred when allocating an on-chip capacity of size s for the corresponding data at time step t. For each time step and each candidate capacity, the cumulative cost of the current data residing entirely in BRAM versus partially residing in HBM is compared and the state is updated. Under the constraint that the size of the three types of data is less than or equal to the total on-chip storage capacity Smax, the partition capacity with the minimum total off-chip read bandwidth cost and the corresponding data residency scheme are selected as the storage configuration.

[0145] Module 7 binds the pipeline scheduling parameters to the pipeline IP core of the FPGA hardware accelerator and binds the partition capacity to the BRAM IP core of the FPGA hardware accelerator; it generates the connection relationships and control information between pipeline stages, pipelines, BRAM and HBM according to the data flow graph dependencies, as the connection configuration;

[0146] Module 8 instantiates the RTL module of the FPGA hardware accelerator based on the computing configuration, storage configuration, and connectivity configuration, forming the computing cluster and storage subsystem of the FHE application within the FPGA hardware accelerator; and generates the configuration bitstream using FPGA synthesis, placement and routing, and bitstream generation tools.

[0147] Module 9 loads the configuration bitstream into the target FPGA in the FPGA hardware accelerator; the operation parameters and encrypted text information are read from the FPGA hardware accelerator into the HBM, and the PE pipeline of the FPGA hardware accelerator performs the calculation of the encrypted application. The BRAM and HBM are jointly responsible for caching the data during operation, and finally obtain the encrypted result for the user to decrypt, which serves as the execution result of the FHE application.

[0148] The automated design device for FHE accelerator architecture is described above. In the data flow graph, nodes represent FHE operators, and edges represent data dependencies between operators. The module 1 also includes: calculating the depth, width, number of operators, number of operator executions, and amount of parallel data of the data flow graph, and extracting the ciphertext polynomial degree, modulus bit width, computation level, ciphertext size, key size, and intermediate data size to form an application feature set.

[0149] The automated design apparatus for the FHE accelerator architecture, wherein module 4 includes: if the candidate configuration exceeds the hardware performance constraints of the FPGA in the FPGA hardware accelerator, then reduce the number of pipelines N, the depth of each pipeline D, and the parallelism within the pipeline P, and return to module 3 to continue the search.

[0150] Module 3 includes:

[0151] Simulated annealing search is initiated with N0, D0, P0 and a preset initial temperature T0. The pipeline number N, depth D, and parallelism P are iteratively perturbed to obtain candidate configurations. For each candidate configuration, the application latency L, pipeline utilization, operator utilization, and PE utilization U are calculated, and the merits of each candidate configuration are judged based on the evaluation functions of application latency L and PE utilization U. According to the annealing acceptance probability, some non-optimal candidate configurations are retained and the temperature is gradually reduced. At the same time, candidate configurations with higher latency and lower utilization are deleted to obtain a non-dominated candidate set that meets the hardware constraints of the FPGA hardware accelerator.

[0152] The search starts with initial parameters N0, D0, P0 and initial temperature T0, and perturbs N, D and P to generate multiple candidate configurations. For each candidate configuration, the operator sequence is mapped to each pipeline according to the candidate depth, and the application execution is simulated according to the parallelism within the pipeline to obtain the latency L and hardware utilization U of the candidate configuration. The utilization can be statistically analyzed at the pipeline level, operator level and PE array level respectively. The PE array utilization can be obtained by the ratio of the number of effectively working PEs to the total number of configured PEs.

[0153] The evaluation function is F=log(1+β×U / L), where β represents the weight between delay and utilization. The search retains candidates with better evaluation and retains some temporarily poor candidates according to the simulated annealing acceptance probability. The temperature is gradually reduced according to the cooling coefficient. When there is no improvement after several consecutive iterations, β is adjusted and the search continues.

[0154] Furthermore, Pareto filtering is performed after each update of the candidate configuration: if a candidate configuration has both higher latency and lower utilization compared to another candidate configuration, it is deleted; the remaining candidates are non-dominated candidates.

[0155] like Figure 2 As shown, in another embodiment of the present invention, a first electronic device A is also provided, comprising the aforementioned automated design device B for an FHE accelerator architecture.

[0156] like Figure 3As shown, the first electronic device A can also be connected to the data acquisition device C and the information display device D through a wired or wireless information transmission scheme. The data acquisition device C is used to acquire FHE applications, and the information display device D is used to display the execution results of the FHE applications obtained by the present invention.

[0157] The information display device D can process and organize the data output by the first electronic device A based on an information display mechanism to improve the readability of the data. This information display mechanism can be manually preset, for example, visualizing the data output by the first electronic device A. It can present the user with specified key information based on user-defined display parameters and / or attributes, such as the data range and font, color, and scrolling options. Users can access this information more quickly without needing to navigate to secondary pages or scroll through pages, saving them time and effort. Alternatively, the information display mechanism can be an artificial intelligence (AI) display model that learns the user's key information interests based on past usage habits, such as viewing time, click count, and edit count, and automatically presents rich and necessary key information.

[0158] The present invention also provides a computer program product comprising a computer program that can be stored on a readable storage medium. When the computer program is executed by a processor, the computer is able to execute the automated design method for FHE accelerator architecture provided by the methods described above.

[0159] In another embodiment, the present invention also proposes a storage medium VIII for storing a computer program that executes the automated design method for the FHE accelerator architecture. It should be understood that the storage medium in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0160] Figure 4 A schematic block diagram of a second electronic device 1000 that can be used to implement embodiments of the present invention is shown. The second electronic device 1000 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The second electronic device 1000 can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein. The second electronic device 1000 may be the same as or different from the first electronic device A.

[0161] The second electronic device 1000 includes a computing unit I, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory II (ROM) or a computer program loaded from storage medium VIII into random access memory (RAM) III. The RAM III may also store various programs and data required for the operation of the device 1000. The computing unit I, ROM II, and RAM III are interconnected via bus IV. An input / output (I / O) interface V is also connected to bus IV.

[0162] Multiple components in the second electronic device 1000 are connected to I / O interface V, including: input unit VI, such as a keyboard, mouse, etc.; output unit VII, such as various types of displays, speakers, etc.; storage medium VIII, such as a disk, optical disk, etc.; and communication unit IX, such as a network card, modem, wireless transceiver, etc. Communication unit IX allows the second electronic device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0163] The computing unit I can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of computing unit I include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit I performs the various methods and processes described above, such as method steps S1-S9. For example, in some embodiments, the methods can be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage medium VIII. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1000 via ROM II and / or communication unit IX. When the computer program is loaded into RAM III and executed by computing unit I, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, computing unit I can be configured to perform methods by any other suitable means (e.g., by means of firmware).

[0164] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and illustrations shown and described herein.

Claims

1. An automated design method for FHE accelerator architecture, characterized in that, include: Step 1: Obtain the FHE application and the FPGA hardware accelerator used to execute the FHE application; Extract the data flow graph of the FHE application; Step 2: Divide the interdependent nodes in the data flow graph into operator sequences, map the concurrently executable operator sequences to different candidate pipelines, map the execution order of operators in the operator sequence to the pipeline level order, and determine the number of PEs in the candidate pipeline based on the amount of data processed in parallel by the operators, so as to establish the initial value range and initial configuration N0, D0, P0 of the pipeline number N, depth D, and parallelism P. Step 3: Start the simulated annealing search with N0, D0, P0 and a preset initial temperature T0, iteratively perturb the number of pipelines N, depth D, and parallelism P to obtain candidate configurations; calculate the application latency L, pipeline utilization, operator utilization, and PE unit utilization for each candidate configuration, and combine them to form the overall utilization rate U. Determine the merits of each candidate configuration based on the evaluation function of application latency L and overall utilization rate U; retain some non-optimal candidate configurations according to the annealing acceptance probability and gradually reduce the temperature, while deleting candidate configurations with higher latency and lower utilization, to obtain a non-dominated candidate set that meets the hardware constraints of the FPGA hardware accelerator. Step 4: Select the computation configuration from the non-dominated candidate set according to the performance target of the FHE application, including the number of pipelines N, the depth of each pipeline D, the parallelism within the pipeline P, and the pipeline scheduling parameters of each operator configuration. Step 5: Based on the pipeline scheduling parameters, the execution process of the FHE application is discretized into multiple time steps from 0 to Tmax. The three types of data for each time step are calculated. These three types of data include key data requirement data Skey(t), read-only data requirement data Sro(t), and read-write data requirement data Srw(t). The total on-chip storage capacity Smax of the FPGA hardware accelerator for these three types of data is obtained. Step 6: Establish dynamic programming state functions FX(s,t) for the three types of data respectively. FX(s,t) represents the off-chip read bandwidth cost generated when allocating an on-chip capacity of size s for the corresponding data at time step t. For each time step and each candidate capacity, compare the cumulative costs of the current data being fully resident in BRAM and partially retained in HBM and update the state. Under the constraint that the size of the three types of data is less than or equal to the total on-chip storage capacity Smax, select the partition capacity with the minimum total off-chip read bandwidth cost and the corresponding data resident scheme as the storage configuration. Step 7: Bind the pipeline scheduling parameters to the pipeline IP core of the FPGA hardware accelerator, and bind the partition capacity to the BRAM IP core of the FPGA hardware accelerator. Based on the data flow graph dependencies, the connection relationships and control information between pipeline stages, pipelines, BRAM and HBM are generated as connection configurations. Step 8: Based on the computing configuration, storage configuration, and connectivity configuration, instantiate the RTL module of the FPGA hardware accelerator to form the computing cluster and storage subsystem of the FHE application in the FPGA hardware accelerator; generate the configuration bitstream using FPGA synthesis, placement and routing, and bitstream generation tools. Step 9: Load the configuration bitstream into the target FPGA in the FPGA hardware accelerator; read the operation parameters and encrypted text information from the FPGA hardware accelerator into the HBM, and perform encrypted application calculations by the PE pipeline of the FPGA hardware accelerator. The BRAM and HBM are jointly responsible for caching the running data, and finally obtain the encrypted result for the user to decrypt, which serves as the execution result of the FHE application.

2. The automated design method for FHE accelerator architecture as described in claim 1, characterized in that, In this data flow graph, nodes represent FHE operators, and edges represent data dependencies between operators. Step 1 also includes: calculating the depth, width, number of operators, number of operator executions, and amount of parallel data of the data flow graph, and extracting the ciphertext polynomial degree, modulus bit width, computation level, ciphertext size, key size, and intermediate data size to form an application feature set.

3. The automated design method for FHE accelerator architecture as described in claim 1, characterized in that, Step 4 includes: if the candidate configuration exceeds the hardware performance constraints of the FPGA in the FPGA hardware accelerator, then reduce the number of pipelines N, the depth of each pipeline D, and the parallelism within the pipeline P, and return to step 3 to continue the search.

4. The automated design method for FHE accelerator architecture as described in claim 1, characterized in that, Step 3 includes: Simulated annealing search is initiated with N0, D0, P0 and a preset initial temperature T0. The pipeline number N, depth D, and parallelism P are iteratively perturbed to obtain candidate configurations. For each candidate configuration, the application latency L, pipeline utilization, operator utilization, and PE utilization U are calculated, and the merits of each candidate configuration are judged based on the evaluation functions of application latency L and PE utilization U. According to the annealing acceptance probability, some non-optimal candidate configurations are retained and the temperature is gradually reduced. At the same time, candidate configurations with higher latency and lower utilization are deleted to obtain a non-dominated candidate set that meets the hardware constraints of the FPGA hardware accelerator. The search starts with initial parameters N0, D0, P0 and initial temperature T0, and perturbs N, D and P to generate multiple candidate configurations. For each candidate configuration, the operator sequence is mapped to each pipeline according to the candidate depth, and the application execution is simulated according to the parallelism within the pipeline to obtain the latency L and hardware utilization U of the candidate configuration. The utilization can be statistically analyzed at the pipeline level, operator level and PE array level respectively. The PE array utilization can be obtained by the ratio of the number of effectively working PEs to the total number of configured PEs. The evaluation function is F=log(1+β×U / L), where β represents the weight between delay and utilization. The search retains candidates with better evaluation and retains some temporarily poor candidates according to the simulated annealing acceptance probability. The temperature is gradually reduced according to the cooling coefficient. When there is no improvement after several consecutive iterations, β is adjusted and the search continues. Furthermore, Pareto filtering is performed after each update of the candidate configuration: if a candidate configuration has both higher latency and lower utilization compared to another candidate configuration, it is deleted; the remaining candidates are non-dominated candidates.

5. An automated design apparatus for FHE accelerator architectures, characterized in that, include: Module 1, acquires the FHE application and the FPGA hardware accelerator used to execute the FHE application; Extract the data flow graph of the FHE application; Module 2 divides the interdependent nodes in the data flow graph into operator sequences, maps concurrently executable operator sequences to different candidate pipelines, maps the execution order of operators in the operator sequence to pipeline order, and determines the number of PEs in the candidate pipeline based on the amount of data processed in parallel by the operators, so as to establish the initial value range and initial configuration N0, D0, P0 of the pipeline number N, depth D, and parallelism P. Module 3 initiates a simulated annealing search with N0, D0, P0 and a preset initial temperature T0, iteratively perturbing the number of pipelines N, depth D, and parallelism P to obtain candidate configurations. For each candidate configuration, it calculates the application latency L, pipeline utilization, operator utilization, and PE unit utilization, and synthesizes them into a comprehensive utilization rate U. The merits of each candidate configuration are judged based on the evaluation function of application latency L and comprehensive utilization rate U. According to the annealing acceptance probability, some non-optimal candidate configurations are retained and the temperature is gradually reduced. At the same time, candidate configurations with higher latency and lower utilization are deleted to obtain a non-dominated candidate set that meets the hardware constraints of the FPGA hardware accelerator. Module 4 selects the computation configuration from the non-dominated candidate set according to the performance objectives of the FHE application, including the number of pipelines N, the depth of each pipeline D, the parallelism within the pipeline P, and the pipeline scheduling parameters configured for each level of operator. Module 5, based on the pipeline scheduling parameters, discretizes the execution process of the FHE application into multiple time steps from 0 to Tmax, calculates three types of data for each time step, including key data requirement data Skey(t), read-only data requirement data Sro(t), and read-write data requirement data Srw(t), and obtains the total on-chip storage capacity Smax of the FPGA hardware accelerator for these three types of data; Module 6 establishes dynamic programming state functions FX(s,t) for the three types of data, where FX(s,t) represents the off-chip read bandwidth cost incurred when allocating an on-chip capacity of size s for the corresponding data at time step t. For each time step and each candidate capacity, the cumulative cost of the current data residing entirely in BRAM versus partially residing in HBM is compared and the state is updated. Under the constraint that the size of the three types of data is less than or equal to the total on-chip storage capacity Smax, the partition capacity with the minimum total off-chip read bandwidth cost and the corresponding data residency scheme are selected as the storage configuration. Module 7 binds the pipeline scheduling parameters to the pipeline IP core of the FPGA hardware accelerator and binds the partition capacity to the BRAM IP core of the FPGA hardware accelerator. Based on the data flow graph dependencies, the connection relationships and control information between pipeline stages, pipelines, BRAM and HBM are generated as connection configurations. Module 8 instantiates the RTL module of the FPGA hardware accelerator based on the computing configuration, storage configuration, and connectivity configuration, forming the computing cluster and storage subsystem of the FHE application within the FPGA hardware accelerator; and generates the configuration bitstream using FPGA synthesis, placement and routing, and bitstream generation tools. Module 9 loads the configuration bitstream into the target FPGA in the FPGA hardware accelerator; the operation parameters and encrypted text information are read from the FPGA hardware accelerator into the HBM, and the PE pipeline of the FPGA hardware accelerator performs the calculation of the encrypted application. The BRAM and HBM are jointly responsible for caching the data during operation, and finally obtain the encrypted result for the user to decrypt, which serves as the execution result of the FHE application.

6. The automated design apparatus for FHE accelerator architecture as described in claim 1, characterized in that, In this data flow graph, nodes represent FHE operators, and edges represent data dependencies between operators. Module 1 also includes: calculating the depth, width, number of operators, number of operator executions, and amount of parallel data of the data flow graph, and extracting the ciphertext polynomial degree, modulus bit width, computation level, ciphertext size, key size, and intermediate data size to form an application feature set.

7. The automated design apparatus for FHE accelerator architecture as described in claim 1, characterized in that, Module 4 includes: if the candidate configuration exceeds the hardware performance constraints of the FPGA in the FPGA hardware accelerator, then reduce the number of pipelines N, the depth of each pipeline D, and the parallelism within the pipeline P, and return to module 3 to continue the search. Module 3 includes: Simulated annealing search is initiated with N0, D0, P0 and a preset initial temperature T0. The pipeline number N, depth D, and parallelism P are iteratively perturbed to obtain candidate configurations. For each candidate configuration, the application latency L, pipeline utilization, operator utilization, and PE utilization U are calculated, and the merits of each candidate configuration are judged based on the evaluation functions of application latency L and PE utilization U. According to the annealing acceptance probability, some non-optimal candidate configurations are retained and the temperature is gradually reduced. At the same time, candidate configurations with higher latency and lower utilization are deleted to obtain a non-dominated candidate set that meets the hardware constraints of the FPGA hardware accelerator. The search starts with initial parameters N0, D0, P0 and initial temperature T0, and perturbs N, D and P to generate multiple candidate configurations. For each candidate configuration, the operator sequence is mapped to each pipeline according to the candidate depth, and the application execution is simulated according to the parallelism within the pipeline to obtain the latency L and hardware utilization U of the candidate configuration. The utilization can be statistically analyzed at the pipeline level, operator level and PE array level respectively. The PE array utilization can be obtained by the ratio of the number of effectively working PEs to the total number of configured PEs. The evaluation function is F=log(1+β×U / L), where β represents the weight between delay and utilization. The search retains candidates with better evaluation and retains some temporarily poor candidates according to the simulated annealing acceptance probability. The temperature is gradually reduced according to the cooling coefficient. When there is no improvement after several consecutive iterations, β is adjusted and the search continues. Furthermore, Pareto filtering is performed after each update of the candidate configuration: if a candidate configuration has both higher latency and lower utilization compared to another candidate configuration, it is deleted; the remaining candidates are non-dominated candidates.

8. An electronic device, characterized in that, The invention includes an automated design apparatus for an FHE accelerator architecture as described in claims 5-7, wherein the electronic device is connected to an information display device, which displays the execution result using user-set display parameters, attributes, or through an artificial intelligence model.

9. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the automated design method for FHE accelerator architecture as described in any one of claims 1-4.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the automated design method for the FHE accelerator architecture as described in any of claims 1-4.

Images