Dynamic hypergraph hardware accelerator and acceleration method based on FPGA

Abstract

The invention relates to a dynamic hypergraph hardware accelerator based on an FPGA and an acceleration method. The hardware accelerator comprises a central processing unit and an FPGA processing unit. The central processing unit reads and analyzes the input mode hypergraph to obtain a matching plan and sends the matching plan to the FPGA processing unit; verifying the constraint related to the high-order intersection and the unique mapping condition of the vertex; the FPGA processing unit locates and marks candidate results which are invalid due to updating operation; expanding a neighborhood domain in the data hypergraph by taking the updated edge as an anchor point so as to construct a local dependency subgraph; in the local dependence subgraph range, preposed pruning is carried out based on a matching plan, and multi-constraint screening is executed; performing bitmap intersection operation on the pruned candidate results to perform constraint verification, and discarding the candidate results which do not pass the constraint verification; on the basis of candidate results passing the constraint verification, generating a normalized key to carry out rapid pre-checking, thereby realizing duplicate removal and pre-filtering; and sending the candidate result subjected to duplicate removal and pre-filtering to a central processing unit.

Description

Technical Field

[0001] This invention relates to the field of hardware accelerator technology, and in particular to an FPGA-based dynamic supergraph hardware accelerator and acceleration method. Background Technology

[0002] With the rapid development of big data and artificial intelligence technologies, graph-structured data has become a core representation for depicting complex relational networks, playing a crucial role in fields such as social network analysis, recommender systems, traffic prediction, bioinformatics, and knowledge graphs. Traditional graph computing mainly targets static ordinary graphs (composed of vertices and edges), but in real-world scenarios, the relationships between vertices often exhibit high-order multivariate characteristics, requiring modeling using hypergraphs. Hypergraphs use "hyperedges" as the basic unit, allowing a single hyperedge to connect more than two vertices, and can more accurately express group interactions and high-order semantic associations. They significantly outperform traditional graph models in tasks such as community detection, hyperedge prediction, and Hypergraph Neural Networks (HGNNs).

[0003] However, hypergraphs in real-world applications often evolve dynamically over time: the creation or disbanding of groups on social platforms corresponds to the addition or deletion of hyperedges, while changes in user behavior in e-commerce recommendation systems trigger real-time updates to relationships. This high-frequency dynamic characteristic poses a serious challenge to existing computing frameworks. Current mainstream hypergraph pattern mining and matching methods are based on CPU / GPU implementations and suffer from four major bottlenecks: 1. High global recalculation overhead: Structure updates require recalculating the candidate set and matching relationships across the entire graph, leading to a surge in redundant computations and latency; 2. Low storage access efficiency: High-order connections complicate the storage of adjacency information, irregular memory access causes cache invalidation, and bandwidth becomes a performance bottleneck; 3. Severe candidate redundancy: The mining process generates a large number of failed candidate results, significantly increasing the burden of intersection calculation and consistency verification; 4. Lack of hardware support: Existing general-purpose parallel computing frameworks (such as GPUs) are mainly optimized for regular dense tensor computation. Although some improvement schemes attempt to optimize through sparse matrix representation (such as the correlation matrix), they are still difficult to cope with the high-order correlation and irregular pattern dependencies unique to hypergraph data, resulting in serious memory access conflicts and computational redundancy when processing hypergraph intersection operations, thus limiting performance.

[0004] Existing improvement solutions (such as incremental computation, pruning strategies, and index acceleration) are mostly limited to the software level, making it difficult to fully utilize the advantages of hardware parallelism and pipelining. Especially in dynamic hypergraph scenarios, these methods cannot simultaneously meet the dual requirements of low-latency updates and high-throughput mining. Therefore, there is an urgent need to design a hardware-software co-acceleration solution for dynamic hypergraphs: by leveraging the customizability and parallel architecture of FPGAs, core processes such as candidate generation, intersection constraint verification, and result maintenance can be optimized at the hardware level. This would support incremental recalculation of locally dependent subgraphs, avoid redundancy in global traversal, and thus significantly improve the real-time efficiency and throughput of dynamic hypergraph pattern mining while ensuring computational correctness.

[0005] For example, CN115328850A discloses a hardware accelerator for hypergraph processing and its operation method. The hardware accelerator includes a data loader, an address translator, a task trigger, a processor, and a merger. The data loader, under a pre-defined data-centric load-triggered merge execution model, sequentially reads hypergraph block data from off-chip memory according to the hypergraph data organization and block order. The address translator deploys the hypergraph data to the processor's private registers and / or buffer memory according to the priority order of the loaded data and records offset information. The task trigger generates computation tasks based on the loaded data and schedules them to the processor. The processor receives and executes the computation tasks. The merger schedules intermediate results to a first-priority data merging unit or a second-priority data merging unit based on data priority to perform intermediate result merging operations. However, this technical solution mainly targets static hypergraph processing and lacks targeted support for key issues such as dynamic updates, higher-order intersection optimization, and candidate redundancy reduction, thus failing to solve the aforementioned technical problems.

[0006] Furthermore, on the one hand, there are differences in understanding among those skilled in the art; on the other hand, the applicant studied a large number of documents and patents when making this invention, but due to space limitations, not all details and contents were listed in detail. However, this does not mean that the present invention does not possess the features of these prior art. On the contrary, the present invention already possesses all the features of the prior art, and the applicant reserves the right to add relevant prior art to the background art. Summary of the Invention

[0007] This invention aims to provide an FPGA-based dynamic hypergraph hardware accelerator and acceleration method to solve the core problems of high computational overhead, severe candidate redundancy, and lack of efficient incremental update mechanism in dynamic hypergraph pattern mining, thereby achieving high throughput and low latency pattern mining and maintenance in large-scale, frequently updated hypergraph scenarios.

[0008] The present invention provides, from a first aspect, an FPGA-based dynamic supergraph hardware accelerator, the hardware accelerator including a central processing unit and an FPGA processing unit.

[0009] The central processing unit is configured to: read and parse the input pattern hypergraph to obtain a matching plan and send it to the FPGA processing unit; verify the constraints involving higher-order intersections and the unique mapping conditions of vertices; and undertake the candidate expansion and backoff processing of hyperedges with ultra-high degree to ensure correctness.

[0010] The FPGA processing unit is configured to: locate and mark candidate results that fail due to update operations; expand the neighborhood domain in the data hypergraph using update edges as anchors to construct a local dependency subgraph; within the local dependency subgraph, perform pre-pruning based on a matching plan and execute multiple constraint filtering to reduce redundant candidates; perform bitmap intersection operations on the pruned candidate results to perform constraint verification, discarding candidate results that fail constraint verification to achieve early truncation; generate normalized keys based on candidate results that pass constraint verification for fast pre-lookup, thereby achieving deduplication pre-filtering; and send the candidate results that pass deduplication pre-filtering to the central processing unit.

[0011] The core function of this invention is to efficiently process dynamically evolving hypergraph data, achieving fast, low-latency pattern matching and result updates. Its key advantage lies in its significantly improved processing efficiency in dynamic scenarios through a hardware-software co-working incremental computing architecture. Specifically, the central processing unit is responsible for global scheduling, complex verification, and consistency maintenance, while the FPGA processing unit utilizes its parallel computing capabilities to focus on high-performance local computation tasks. This invention, through a local dependency subgraph mechanism, strictly limits the computation scope to local regions affected by graph updates, avoiding the huge overhead of full graph recalculation. Simultaneously, the FPGA hardware pipeline accelerates a series of operations such as candidate generation, multiple pruning, bitmap intersection constraint verification, and pre-filtering deduplication, and reduces redundant computation through mechanisms such as early truncation. Ultimately, while ensuring the correctness and consistency of results, this system can achieve millisecond-level update response and high-throughput pattern mining, making it particularly suitable for large-scale, real-time-critical dynamic hypergraph applications.

[0012] According to a preferred embodiment, the central processing unit includes a schema parsing module, an incremental log management module, a complex consistency check module, and a global result index maintenance module.

[0013] The pattern parsing module parses the pattern hypergraph, generating matching order, degree constraints, intersection constraints, and symmetry breaking constraints, thus forming a matching plan and sending it to the FPGA processing unit. The matching plan serves as the guiding basis for candidate result generation and screening. The incremental log management module receives dynamic update requests and maintains the hypergraph storage structure based on a delete-then-add strategy. It generates incremental log entries and sends read-only updated views to the FPGA processing unit. The complex consistency check module verifies constraints involving high-order intersections and unique mapping conditions of vertices. It handles candidate expansion and rollback processing for hyperedges with very high degree to ensure correctness. The global result index maintenance module stores candidate results in a global index table to ensure the consistency of the result set in dynamic scenarios.

[0014] The central processing unit (CPU) is designed to create a highly efficient and reliable hardware-software collaborative control core. Its advantages lie in: the pattern parsing module generates optimized instructions to guide the FPGA's efficient operation; the incremental log management module ensures the orderly and traceable nature of dynamic updates; the complex consistency check module handles complex calculations, guaranteeing absolutely correct results; and the global result index maintenance module maintains the consistency of the final state. These four components work together to enable the CPU to precisely schedule parallel computations by the FPGA processing units and rigorously control correctness and consistency, making it the key brain for the reliable operation of the entire hardware acceleration system.

[0015] According to a preferred embodiment, the FPGA processing unit includes a candidate failure handling module, a dependency subgraph generation module, a candidate generation and pruning module, an intersection constraint calculation module, a deduplication pre-filtering module, and a result writing module.

[0016] The candidate failure handling module locates and marks dynamically changing candidate results based on incremental logs and adds failure markers to the global index table. The dependency subgraph generation module expands the adjacency structure of updated edges using the updated edges as anchors within a local range, constructing a local dependency subgraph to narrow the candidate generation range. The candidate generation and pruning module performs candidate expansion based on the matching plan within the local dependency subgraph range and performs multi-constraint filtering to reduce redundant candidates at the source. The intersection constraint calculation module calculates pairwise intersections and multi-way intersections for the pruned candidate results to perform constraint verification, discarding candidate results that fail constraint verification to achieve early truncation. The deduplication pre-filtering module generates normalized keys for candidate results and performs a fast pre-lookup on the normalized keys, sending the new candidate results obtained after deduplication pre-filtering to the central processing unit for precise querying. The result writing module writes the candidate results that have passed the deduplication pre-filtering to the global result index table.

[0017] This technical solution constructs a complete FPGA hardware-accelerated pipeline, whose core advantage lies in achieving efficient incremental processing of dynamic hypergraph updates. The pipeline begins with rapid failure marking to ensure the real-time accuracy of the result set; then, by constructing a locally dependent subgraph, the computational scope is minimized to avoid global recalculation; next, candidate generation and multiple pruning are performed within the local scope to reduce redundancy at the source; then, hardware circuitry is used to quickly verify intersection constraints and preemptively truncate the computation of failed candidate results; finally, pre-filtering for deduplication and batch writing ensure the uniqueness of the results and reduce storage pressure. The entire process is interconnected, and through hardware parallelism and pipeline technology, it significantly improves the processing throughput and real-time performance in dynamic scenarios.

[0018] According to a preferred embodiment, the candidate failure handling module includes an input FIFO and an operation splitter, an index lookup unit, a comparator array and a failure marker, a first writer, and an FSM controller.

[0019] The input FIFO and operation splitter are used to receive incremental logs and distinguish operation types; the index lookup unit is used to locate candidate results containing updated edges and store the mapping relationship between superedge numbers and candidate result ID lists; the comparator array and failure marker are used to compare the superedge numbers in the incremental logs with the candidate index buffer in parallel and mark the matched candidate results with failure tags; the first writer is used to update the failure candidate status to the global result index table; the FSM controller is used to coordinate the operation order of each subunit and return an ACK signal to the central processing unit.

[0020] The hardware design of this candidate failure handling module enables a rapid and accurate response to the impact of dynamic updates. Its core advantage lies in the hardware-based and pipelined implementation of time-consuming lookup and marking operations in the software through highly parallel dedicated circuitry. Input splitting and operation classification ensure task ordering; reverse index lookup achieves precise positioning with O(1) time complexity; the comparator array supports parallel batch comparisons, greatly improving processing speed; a dedicated writer optimizes memory updates; and the FSM controller ensures the coordination and reliability of the entire pipeline. This design results in extremely low latency for failure marking.

[0021] According to a preferred embodiment, the dependency subgraph generation module includes an input FIFO and a task parser, a neighborhood retrieval unit, a K-order neighborhood expander, a dependency subgraph assembler, and a second writer.

[0022] The input FIFO and task parser are used to parse the information of newly added or modified update edges; the neighborhood retrieval unit is used to retrieve all adjacent superedges that share vertices with the update edge; based on the vertex set of the update edge, the inverted index structure is used to quickly query all sets of superedges containing the same vertex; the K-order neighborhood expander is used to expand the neighborhood of the update edge to one or more orders according to the maximum dependency order K of the pattern; the dependency subgraph assembler is used to combine the update edge and its expanded neighbor set into a local dependency subgraph; the second writer is used to store the local dependency subgraph into the storage module for subsequent pipelined processing.

[0023] The core function of this dependency subgraph generation module is to achieve precise control over the scope of incremental computation. Its advantage lies in its ability to efficiently construct locally dependent subgraphs containing only the affected regions through a pipelined dedicated circuit. The module starts by parsing and updating edges, quickly retrieving first-order neighbors using an inverted index, then intelligently expanding multi-order neighbors based on pattern dependencies (K value), and finally assembling them into a compact subgraph structure. This process strictly limits all subsequent computations (such as candidate generation and verification) to a local scope, completely avoiding the huge redundant computational overhead of full graph traversal.

[0024] According to a preferred embodiment, the candidate generation and pruning module includes an input parser, a degree / label checker, a distinctness checker, a symmetry breaker, and a candidate expander.

[0025] The input parser is used to parse the vertices and adjacency relationships of the local dependency subgraph; the degree / label checker is used to perform preliminary screening of candidate results and eliminate candidates that do not meet the constraints; the distinctness checker is used to check whether there are duplicate vertices in the mapping table; if the same vertex is found to be assigned to two pattern vertices, the candidate result is immediately discarded; the symmetry breaker is used to eliminate equivalent candidate permutations caused by the symmetry of the pattern hypergraph; the candidate expander is used to generate legal candidate results and output them to the intersection constraint calculation module.

[0026] The advantage of this candidate generation and pruning module lies in its ability to perform multi-level constraint checks (such as degree, label, distinctness, and symmetry) at an early stage of candidate result generation through a pipelined dedicated circuit. This allows for the rapid filtering out of a large number of invalid or redundant candidate results at the source. This early pruning strategy significantly reduces the load on subsequent more complex calculations (such as intersection constraint verification), effectively improving the processing efficiency and throughput of the entire pipeline.

[0027] According to a preferred embodiment, the intersection constraint calculation module includes a bitmap register, a logic AND operator, a popcount counter, and an early truncation logic unit.

[0028] The bitmap register is used to encode the vertex set of candidate hyperedges into bitmap form; the logical AND operator is used to perform bitwise logical AND operations on the bitmaps of two or more candidate hyperedges to obtain the intersection result of the bitmaps; the popcount counter is used to count the number of vertices in the intersection result and compare the number of vertices with the intersection cardinality in the pattern constraint; if the results are consistent, the constraint verification is passed; the early truncation logic is used to immediately terminate the calculation and discard the candidate result when it is determined that the current candidate cannot satisfy the constraint condition.

[0029] The core advantage of this intersection constraint calculation module lies in leveraging hardware parallelism to transform complex set intersection constraint verification into efficient bitwise operations. By encoding the vertex set as a bitmap and using a logical AND operator for parallel intersection calculation, and a popcount counter to quickly count the intersection size, constraint verification with O(1) time complexity is achieved. Early truncation logic can immediately terminate subsequent calculations when candidates that do not meet the constraints are detected early, avoiding the computational overhead of invalid candidate results.

[0030] According to a preferred embodiment, the deduplication pre-filtering module includes a normalized bond generator, a Bloom filter, and a pre-filter output.

[0031] The normalized key generator maps candidate results to unique key values; the Bloom filter quickly determines whether a candidate already exists; and the pre-filter output sends potentially new candidate results to the central processing unit for precise querying.

[0032] The core function of this deduplication pre-filtering module is to quickly deduplicate candidate results. Its advantage lies in using a hardware-based Bloom filter for efficient prediction. It maps candidate results to normalized keys and performs high-speed queries through the Bloom filter. If a result is determined to already exist, it is discarded directly, avoiding redundant calculations in subsequent precise queries; if a result is determined to be a potential new candidate, it is sent to the central processing unit for final confirmation. This design ensures the uniqueness of the results while significantly reducing the precise query load on the central processing unit, thereby improving the overall system throughput.

[0033] This invention provides a hardware acceleration method for dynamic hypergraphs based on FPGA from a second aspect. The method includes: a central processing unit (CPU) reading and parsing the input pattern hypergraph to obtain a matching plan and sending it to the FPGA processing unit; verifying constraints involving high-order intersections and unique mapping conditions of vertices to handle candidate expansion and backoff processing of hyperedges with very high degree, ensuring correctness; the FPGA processing unit locating and marking candidate results that fail due to update operations; expanding the neighborhood domain in the data hypergraph using the updated edge as an anchor point to construct a locally dependent subgraph; within the locally dependent subgraph, performing pre-pruning based on the matching plan and executing multiple constraint filtering to reduce redundant candidates; performing bitmap intersection operations on the pruned candidate results to perform constraint verification, discarding candidate results that fail constraint verification to achieve early truncation; generating normalized keys based on candidate results that pass constraint verification for fast pre-lookup, thereby achieving deduplication pre-filtering; and sending the candidate results that pass deduplication pre-filtering to the CPU.

[0034] The core advantage of this technical solution lies in its real-time and efficient processing of dynamic hypergraph matching through a heterogeneous computing architecture that combines hardware and software. It offloads computationally intensive and frequent incremental updates, local subgraph construction, candidate pruning, and verification tasks to the FPGA hardware pipeline for parallel execution, thereby achieving throughput far exceeding that of pure software solutions and extremely low latency. Simultaneously, the central processing unit handles complex logic control and final confirmation, ensuring the absolute correctness of the results. This division of labor enables the system to cope with rapid changes in dynamic data while guaranteeing the accurate completion of large-scale complex queries, significantly improving overall processing efficiency.

[0035] According to a preferred embodiment, the method further includes: when the order k of the intersection calculation is greater than 3 or the degree of the candidate hyperedge exceeds a threshold, the central processing unit performs the calculation process, and the FPGA processing unit completes the non-calculation process in parallel pipeline.

[0036] The core advantage of this technical solution lies in its dynamic load balancing between hardware and software. It intelligently allocates computationally complex tasks (such as high-order intersections or extremely high degrees) to the central processing unit to ensure the correctness of complex logic; simultaneously, the FPGA hardware pipeline processes a large number of other routine tasks in parallel. This collaborative mechanism prevents hardware circuits from becoming performance bottlenecks due to handling extremely complex situations, ensuring that the system maintains stable and efficient overall processing capabilities when facing hypergraphs of various sizes and data distributions, thus improving the system's robustness and adaptability.

[0037] The present invention provides, from a third aspect, an incremental pattern matching hardware accelerator for dynamic hypergraphs, including a central processing unit and an FPGA processing unit communicatively connected to the central processing unit, wherein the FPGA processing unit includes a dependent subgraph generation module, a candidate generation and pruning module, an intersection constraint calculation module, and a deduplication pre-filtering module.

[0038] The dependency subgraph generation module is used to construct a local dependency subgraph within a limited neighborhood radius by using the updated hyperedge as an anchor point when the dynamic hypergraph is updated or modified. This limits incremental computation to the scope of the update's impact and avoids recalculating the entire graph. The candidate generation and pruning module generates a set of candidate maps based on the pattern matching plan within the local dependency subgraph and performs pre-pruning. The intersection constraint calculation module verifies the hypergraph adjacency relationships and intersection constraints of the candidate map set. The intersection constraint calculation module includes a bitmap register, a logical AND operator, a popcount counter, and an early truncation logic unit, and is implemented in a hardware pipeline manner. The algorithm performs intersection calculations and early stopping to reduce the computational overhead of invalid candidate results. The deduplication pre-filtering module includes a normalized key generator and a Bloom filter. The normalized key generator converts candidate mappings into order-independent normalized keys, while the Bloom filter performs probabilistic pre-screening of the normalized keys, ensuring that only potentially new candidate results are output to the central processing unit for accurate deduplication, thereby reducing the global index access pressure. The central processing unit is configured to perform accurate deduplication / writing on the potentially new candidate results output by the deduplication pre-filtering module, and to perform rollback when the computational complexity of candidate expansion or intersection constraint verification exceeds a preset threshold.

[0039] The key innovations of this invention include: First, incremental recalculation of locally dependent subgraphs: When adding or modifying superedges, only the updated edge is used as the anchor point to expand the first-order or multi-order neighborhood, construct the locally dependent subgraph and perform incremental recalculation, avoiding repeated calculation of the entire graph; Second, the intersection constraint circuit and early stop mechanism: the hardware calculation of the intersection constraint is implemented by using bitmap and popcount circuit, and an early stop mechanism is introduced to terminate immediately when it is determined that the intersection cannot meet the pattern requirements, thereby reducing latency and power consumption. Third, deduplication pre-filtering and versioned global index table: The FPGA processing unit uses a Bloom filter to quickly pre-look up candidate normalized keys, and combines it with the global index table of the central processing unit for accurate query and version management, realizing idempotent writing of candidates and historical backtracking, significantly reducing redundant results.

[0040] The beneficial effects of this invention are as follows: While ensuring the correctness of the results, the candidate size and computational overhead are significantly reduced; by leveraging the parallel pipelined execution of the FPGA processing unit, fast processing of candidate failure, candidate generation, intersection calculation and result writing is achieved, significantly improving throughput; through local dependency subgraphs and incremental update mechanisms, update latency is controlled at the millisecond level, making it suitable for large-scale dynamic graph scenarios with high real-time requirements. Attached Figure Description

[0041] Figure 1 This is a simplified schematic diagram of the module connection relationship of the dynamic supergraph hardware accelerator provided by the present invention; Figure 2 This is a schematic diagram of the flow relationship of the acceleration method of the dynamic supergraph hardware accelerator provided by the present invention; Figure 3 This is a functional flowchart of the candidate failure handling module provided by the present invention; Figure 4 This is a functional flowchart of the dependency subgraph generation module provided by the present invention; Figure 5 This is a functional flowchart of the candidate generation and pruning module provided by the present invention; Figure 6 This is a functional flowchart of the intersection constraint calculation module provided by the present invention; Figure 7 This is a functional flowchart of the deduplication pre-filtering module provided by the present invention; Figure 8 This is a functional flowchart of the result writing module provided by the present invention.

[0042] List of reference numerals 101: Central Processing Unit; 1011: Pattern Parsing Module; 1012: Incremental Log Management Module; 1013: Complex Consistency Check Module; 1014: Global Result Index Maintenance Module; 102: FPGA Processing Unit; 1021: Candidate Failure Handling Module; 1022: Dependency Subgraph Generation Module; 1023: Candidate Generation and Pruning Module; 1024: Intersection Constraint Calculation Module; 1025: Deduplication Pre-filtering Module; 1026: Result Writing Module; 200: Storage Module; 2001: Pattern Hypergraph Storage Area; 2002: Data Hypergraph Storage Area; 2003: Intersection Table Storage Area; 2004: Incremental Log Storage Area; 2005: Candidate Result Index Storage Area; 1031: CPU→FPGA Connection Line; 1032: FPGA CPU connection cable; 1033: CPU Storage module connection cable; 1034: FPGA Storage module connection cable; 1035: CPU → storage module connection cable. Detailed Implementation

[0043] The following is a detailed explanation with reference to the accompanying drawings.

[0044] This invention provides explanations and clarifications for some terms and concepts.

[0045] A hypergraph is a generalized graph, the most general discrete structure among finite sets, with wide applications in information science, life sciences, and other fields. An edge in a hypergraph can connect any number of vertices. In contrast, an edge in a regular graph can only connect two vertices. Formally, a hypergraph is an ordered binary tuple H=(X,E), where X is a non-empty set of vertices, and E is a non-empty subset of X. The elements of E are called edges or hyperedges. A hypergraph with no duplicate edges is called a simple hypergraph.

[0046] Pattern P: A special subgraph that needs to be extracted from the data.

[0047] Central Processing Unit (CPU) 101: Responsible for the update and control logic of the dynamic graph, including schema parsing, incremental log (DeltaLog) generation, complex consistency checks, and maintenance of the global result index table (ResultIndex). CPU 101 plays a scheduling and management role in the system, ensuring data consistency and global coordination during the dynamic update process.

[0048] FPGA processing unit 102: Field-Programmable Gate Array (FPGA), serving as the computing core, undertakes computationally intensive tasks such as candidate failure handling, dependency subgraph generation, candidate screening, intersection constraint verification, and result deduplication and writing. Internally, FPGA processing unit 102 utilizes a pipelined design to achieve parallel processing of multiple hardware units, accelerating dynamic hypergraph pattern mining.

[0049] DMA (Direct Memory Access): Direct memory access.

[0050] Degree: For a hyperedge, it refers to the number of vertices contained within the hyperedge. For a vertex, it refers to the total number of vertices connected to the hyperedge.

[0051] A pattern line graph is a graph with pattern hyperedges as vertices and shared vertices as edges, used to represent the intersection relationships between pattern hyperedges. The maximum dependency order in a pattern line graph is K.

[0052] Dependency graph: A subgraph containing update edges and their adjacent superedges.

[0053] Idempotent write: Writing the same candidate result multiple times will not generate duplicate records.

[0054] Version rebirth: The candidate key was previously invalid in the global result index; delete_ver ≠ It has been re-marked as valid in the new version.

[0055] Storage module 200: This is either DRAM or on-chip cache, serving as the storage medium for global graph data and candidate indices. It stores the data hypergraph, intersection table (DataCap), incremental log (DeltaLog), and global result index table (ResultIndex). Storage module 200 is connected to FPGA processing unit 102 via a multi-channel high-bandwidth interface (DDR / HBM) and also supports direct read / write operations by central processing unit 101, ensuring efficient access to large-scale data.

[0056] An edge set is a fundamental concept in graph theory, referring to the set of all edges in a graph. In this invention, the edge set of a data hypergraph is represented as {e...} i Updated edges specifically refer to edges that undergo topological changes during graph structure update operations, while candidate hyperedges specifically refer to potential edges that can establish a matching relationship with the pattern graph.

[0057] Example 1 Existing technologies typically introduce incremental update mechanisms only at the hypergraph data structure level, still relying on recalculation across the entire graph. Therefore, in scenarios with frequent structural evolution and large-scale dynamics, the computational overhead remains extremely high. The technical solution proposed in this invention differs from existing methods by innovatively introducing an incremental maintenance mechanism to the pattern matching result layer: through the analysis of pattern dependencies and caching of candidate substructures, when hyperedges are added, deleted, or modified, the affected candidate pattern subgraphs can be accurately identified, and incremental recalculation is performed only on these local regions, thereby avoiding global mining overhead and achieving real-time maintenance of results.

[0058] To achieve the above objectives, this invention provides an FPGA-based dynamic supergraph hardware accelerator and acceleration method. The system revolves around a design concept of supergraph update—candidate maintenance—hardware-software collaboration, forming an end-to-end acceleration pipeline. This invention also provides a device or electronic device for use as a hardware accelerator to execute the acceleration method of this invention. The system of this invention can also be connected to a storage module, which can be its own storage system or a third-party storage module, for data storage.

[0059] The overall system architecture of this invention is constructed using a collaborative approach between a central processing unit 101 (CPU) and an FPGA processing unit 102, mainly comprising the central processing unit 101 and the FPGA processing unit 102. The central processing unit 101 and the FPGA processing unit 102 establish a high-speed interconnection with each other through a communication interface module to realize the transmission and reception of information.

[0060] The central processing unit 101 of the present invention is configured to: read and parse the input pattern hypergraph to obtain a matching plan and send it to the FPGA processing unit 102; verify the constraints involving higher-order intersections and the unique mapping conditions of vertices, so as to undertake the candidate expansion and backoff processing of hyperedges with ultra-high degree and ensure correctness.

[0061] The FPGA processing unit 102 of the present invention is configured to: locate and mark candidate results that fail due to update operations; expand the neighborhood domain in the data hypergraph with the update edge as the anchor point to construct a local dependency subgraph; within the local dependency subgraph, perform pre-pruning based on the matching plan and execute multiple constraint screening to reduce redundant candidates; perform bitmap intersection operation on the pruned candidate results to perform constraint verification, and discard candidate results that fail the constraint verification to achieve early truncation; generate normalized keys based on the candidate results that pass the constraint verification to perform fast pre-lookup, thereby achieving deduplication pre-filtering; and send the candidate results that pass the deduplication pre-filtering to the central processing unit 101.

[0062] Preferably, to balance computing performance and flexibility, the present invention introduces a threshold fallback mechanism between the central processing unit 101 and the FPGA processing unit 102: When the order of the intersection calculation k≤3, it is executed in parallel by the FPGA processing unit 102; if k>3, it falls back to the central processing unit 101 for processing.

[0063] When the degree of a candidate hyperedge exceeds a threshold (e.g., >64 vertices), the central processing unit 101 is rolled back.

[0064] The eventual consistency maintenance of the global index table is always guaranteed by the central processing unit 101, avoiding the risk of inconsistent states of the FPGA processing unit 102.

[0065] This hierarchical mechanism allows the present invention to take advantage of the high parallelism of the FPGA processing unit 102 while avoiding excessive logic complexity and resource waste.

[0066] The system of this invention is particularly suitable for pattern mining tasks in large-scale dynamic hypergraph scenarios. While ensuring correctness and consistency, it can significantly improve throughput and reduce latency.

[0067] like Figure 1As shown, to accommodate data storage for hardware accelerators, this invention also includes a storage module 200 connected to the hardware accelerator. This storage module 200 includes a Pattern Graph Storage 2001, a Data Graph Storage 2002, an Intersection Table (DataCap) Storage 2003, an Update Log (DeltaLog) Storage 2004, and a ResultIndex Storage 2005.

[0068] The schema hypergraph storage area 2001 is used to store the parsed schema hypergraph structure (degree constraints, intersection constraints, matching order, etc.) for fast access by the FPGA processing unit 102. Preferably, the schema hypergraph storage area 2001 stores the schema hypergraph structure in read-only mode.

[0069] The data hypergraph storage area 2002 is used to store the vertex set and adjacency relationship of the original hyperedge. It uses compressed sparse rows (CSR) or equivalent sparse structure to reduce storage overhead.

[0070] The intersection table storage area 2003 is used to store the intersection cardinality information between all data superedges, which is used for fast intersection calculation of the FPGA processing unit 102.

[0071] The incremental log storage area 2004 is used to maintain the incremental log in a circular buffer manner, supports versioned snapshots, and ensures the consistency of concurrent execution of the central processing unit 101 and the FPGA processing unit 102. The incremental log storage area 2004 is used to record update operation entries (add, delete, modify) generated by the central processing unit 101, maintains them in a circular buffer manner, and provides versioned snapshots to ensure data consistency when the central processing unit 101 and the FPGA processing unit 102 are executed concurrently.

[0072] The candidate result index storage area 2005 is used to store currently valid candidate results, and supports information such as version number, status flag (valid / invalid), and timestamp, which are used for result merging and historical backtracking.

[0073] Preferably, the on-chip cache of the FPGA processing unit 102 stores short-lived active adjacency information and candidate results to support the high bandwidth requirements of intersection calculation and failure handling. Access via the multi-channel DRAM controller of the storage module 200 enables a hierarchical design for global DRAM storage and on-chip cache hotspot acceleration. This invention effectively improves parallel memory access efficiency while ensuring large-scale data storage.

[0074] like Figure 1As shown, the CPU→FPGA connection line 1031 is a dashed line, representing the control flow and incremental log channel. It is used by the central processing unit 101 to send incremental log entries, scheduling instructions, and pattern matching plans to the FPGA processing unit 102, in a unidirectional transmission. Preferably, this invention uses a high-speed interconnect bus (e.g., PCIe Gen4 / Gen5, CXL, or AXI bus) as the CPU→FPGA connection line 1031. This CPU–FPGA interconnect interface supports the separation of command and data channels, enabling the transmission of large-scale candidate data without blocking the issuance and execution feedback of task control instructions.

[0075] like Figure 1 As shown, FPGA CPU connection line 1032 is a solid line, representing the data channel of the global index table. It is used by the FPGA processing unit 102 to output candidate results or failure markers (tombstones), and is eventually maintained by the central processing unit 101. It is bidirectional.

[0076] like Figure 1 As shown, CPU The connection line 1033 of the storage module 200 is a solid line, representing the graph data and incremental log buffer channel. The central processing unit 101 can directly access the storage module 200 to perform hypergraph structure modifications and log updates, enabling bidirectional transmission.

[0077] like Figure 1 As shown, FPGA The connection line 1034 of the storage module 200 is a solid line, representing a high-bandwidth data channel (HBM / DDR). The FPGA processing unit 102 batches the vertex set, adjacency relationship and intersection table during the candidate generation and intersection calculation stages, and transmits them bidirectionally.

[0078] like Figure 1 As shown, the connection line 1035 between the CPU and the storage module 200 is a dashed line. This control channel is used by the central processing unit 101 to send configuration, management, or consistency maintenance commands to the storage module 200, and is a unidirectional transmission.

[0079] Preferably, the FPGA processing unit 102 interacts directly with the external storage module 200 (DDR4 / DDR5 or HBM) through a memory access interface via a multi-channel DRAM controller, supporting burst transfer and pipelined access. During candidate generation, intersection calculation, and other stages, it can batch load adjacency relationships, intersection tables, and other data in a high-bandwidth manner.

[0080] Optionally, in the scenario where the central processing unit 101 and the FPGA processing unit 102 share a global result index table, the interface interconnection between the central processing unit 101 and the FPGA processing unit 102 can support cache-coherent memory access, ensuring that the writing, invalidation marking and regeneration operations of results remain consistent across multiple processing units.

[0081] Through the above design, the communication interface module of this embodiment effectively reduces the data transmission latency between the central processing unit 101 and the FPGA processing unit 102, improves the interaction efficiency of incremental logs, candidate results and adjacency relationships during incremental calculation, and provides important support for the overall system performance.

[0082] The central processing unit 101 of this invention is mainly responsible for dynamic graph update operations and scheduling logic. In this system, the central processing unit 101 is the control center, which sends update events and dependency information to the FPGA processing unit 102 and is responsible for maintaining the consistency of the final result.

[0083] Preferably, such as Figure 1 As shown, the central processing unit 101 includes a Pattern Parsing Module 1011, an Incremental Log Manager 1012, an Advanced Consistency Verification Module 1013, and a Global Result Index Manager 1014.

[0084] The pattern parsing module 1011 is used to parse the pattern hypergraph, generate matching order, degree constraints, intersection constraints, and symmetry breaking constraints, thereby forming a matching plan and sending it to the FPGA processing unit 102. The matching plan serves as a guide for generating and filtering candidate results.

[0085] The incremental log management module 1012 receives dynamic update requests and maintains the hypergraph storage structure based on a delete-then-add strategy. The incremental log management module 1012 generates incremental log entries and sends read-only update views to the FPGA processing unit 102. Incremental log entries record update type, hyperedge number, vertex set, and adjacent edge intersection information.

[0086] The complex consistency check module 1013 is used to verify constraints involving higher-order intersections (k>3) and the unique mapping conditions of vertices. This verification is an exact verification. The complex consistency check module 1013 undertakes candidate expansion and backoff processing for ultra-high degree superedges when necessary to ensure correctness.

[0087] The global result index maintenance module 1014 is used to store candidate results to the global index table, and supports adding, deleting, versioning records and idempotent write operations to ensure the consistency of the result set in dynamic scenarios.

[0088] Preferably, the FPGA processing unit 102 includes a candidate failure processing module 1021, a dependency subgraph generation module 1022, a candidate generation and pruning module 1023, an intersection constraint calculation module 1024, a deduplication pre-filtering module 1025, and a result writing module 1026.

[0089] The candidate failure handling module 1021, the dependency subgraph generation module 1022, the candidate generation and pruning module 1023, the intersection constraint calculation module 1024, the deduplication pre-filtering module 1025, and the result writing module 1026 are interconnected through AXI or on-chip network (NoC) to form an on-chip interconnection mechanism, realize parallel pipelined transmission, and avoid a single bus becoming a bottleneck.

[0090] The candidate failure handling module 1021 is used to locate and mark candidate results that have undergone dynamic changes based on incremental logs, and add failure markers to the global index table.

[0091] Specifically, the candidate failure handling module 1021 is connected to the central processing unit 101 via a line. The candidate failure handling module 1021 receives incremental log entries sent by the central processing unit 101. Based on the incremental log entries, the candidate failure handling module 1021 locates and marks candidate results containing affected (deleted or modified superedges), and performs failure marking in the global index table. The candidate failure handling module 1021 writes the failure marks through the inverted index table of the on-chip cache, sends back the results, and updates the signal.

[0092] The dependency subgraph generation module 1022 is used to expand the adjacency structure of the updated edge in a local range, using the updated edge as the anchor point, to construct a local dependency subgraph and narrow down the candidate generation range.

[0093] More preferably, under the constraints of the incremental log entries provided by the central processing unit 101 and the maximum dependency order K of the pattern, the dependency subgraph generation unit performs hardware-based expansion of the first-order / multi-order neighborhood to generate a local dependency subgraph. The dependency subgraph generation unit only extracts the candidate working set related to the update edge, thus narrowing the recalculation scope.

[0094] The candidate generation and pruning module 1023 is used to perform candidate expansion based on the matching plan and perform multi-constraint filtering within the scope of the locally dependent subgraph to reduce redundant candidate results at the source. Preferably, within the scope of the locally dependent subgraph, the candidate generation and pruning module 1023 generates candidate results based on the matching plan and prunes them based on degree, label constraints, distinctness constraints, and symmetry breaking constraints. Optionally, within the scope of the locally dependent subgraph, L1 pruning (degree / label) and immediate verification of distinctness and symmetry breaking constraints are performed according to the matching plan. The candidate generation and pruning module 1023 expands the candidate results in parallel and outputs them to obtain the pruned candidate results.

[0095] The intersection constraint calculation module 1024 is used to calculate pairwise intersections and multi-way intersections of the pruned candidate results for constraint verification, discarding candidate results that fail the constraint verification to achieve early truncation. More preferably, the intersection constraint calculation module 1024 is used to perform intersection constraint verification between candidate results, using a bitmap AND operation circuit and a popcount circuit to calculate vertex relationships in parallel, and terminating early when the conditions are not met.

[0096] Specifically, the intersection constraint calculation module 1024 uses a bitmap AND operation circuit and a popcount circuit to calculate pairwise intersections and multi-way intersections of k (e.g., k≤3).

[0097] The intersection constraint calculation module 1024 has built-in early stop logic, which terminates the calculation immediately when the result can no longer satisfy the pattern constraint.

[0098] The deduplication pre-filtering module 1025 generates normalized keys for candidate results and performs a fast pre-lookup on these normalized keys. It then sends the new candidate results obtained after deduplication pre-filtering to the central processing unit 101 for precise querying. Preferably, the deduplication pre-filtering module 1025 performs a fast pre-lookup using a Bloom / Counting Bloom filter and sends the new candidate results obtained after deduplication pre-filtering to the central processing unit 101 for precise querying. In other words, the deduplication pre-filtering module 1025 sends normalized keys that are "potentially new" back to the central processing unit 101 for precise querying, avoiding duplicate storage.

[0099] The result writing module 1026 is used to write the candidate results that have passed the deduplication pre-filtering to the global result index table. Specifically, the result writing module 1026 works in conjunction with the global result index maintenance module 1014 of the central processing unit 101 to submit the pre-filtered candidate keys and their version numbers in batches. The result writing module 1026 supports a version regeneration (restores existing but previously invalid keys to validity) writing strategy.

[0100] Preferably, the central processing unit 101 is also equipped with a control module for log management, complex consistency verification and global index maintenance.

[0101] like Figure 1 As shown, the input to the candidate failure handling module 1021 is the DeltaLog. The candidate failure handling module 1021 is used to locate and mark candidate results containing the updated edge when a delete (DEL) or modify (MOD) operation occurs in the dynamic graph, causing them to become invalid in the global result index table (ResultIndex), thereby ensuring the correctness and consistency of subsequent results. The candidate failure handling module 1021 is implemented in a pipelined manner and internally includes an input FIFO and operation splitter, an index lookup unit, a comparator array and failure marker, a first writer, and an FSM controller.

[0102] like Figure 3 As shown, the processing procedure of the candidate failure handling module 1021 includes: receiving incremental logs; determining the update edge type; if the update edge type is DEL / MOD, then inverting the index to the candidate result; writing (annotating) the failure flag; and then ending. If the update edge type is ADD / MOD, the candidate failure handling module 1021 inputs the incremental logs into the dependency subgraph generation module 1022.

[0103] Specifically, the input FIFO and operation splitter are used to receive incremental logs and distinguish operation types. The input FIFO and operation splitter receives incremental logs from the central processing unit 101, parses the operation type (add, delete, modify) and the target superedge number to determine the updated edge type. When the operation type is delete (DEL) or modify (MOD), the input FIFO and operation splitter sends the incremental log to the index lookup unit according to the failure handling path.

[0104] For Modification (MOD) operations, the operations of the candidate failure handling module 1021 include writing failure flags and simultaneously sending the updated edges to the dependent subgraph generation module 1022 to trigger subsequent recalculation.

[0105] For example, at time t+1, the incremental log input is {type=DEL, eid=e3}. The input FIFO and operation diverter transfer the incremental log entry to the failure path, triggering the candidate location process.

[0106] The index lookup unit is used for reverse indexing of candidate results, i.e., locating candidate results containing the updated edge, and storing the mapping relationship between the hyperedge number and the candidate result ID list. The candidate result ID list is implemented using an on-chip cache combined with a hash lookup structure, which can locate all candidate results involving the target hyperedge in O(1) time complexity. When an updated edge is input, the relevant candidate IDs will be directly output from the candidate result ID list.

[0107] For example: Suppose that candidate results (e0, e1, e3) exist, and the inverted index table records e3→{CandID#5}, when DEL(e3) is entered, the index lookup tool immediately finds candidate result number #5. The index lookup tool caches this result for subsequent batch processing.

[0108] The comparator array and failure flagger are used to compare the superedge numbers in the incremental log with the candidate index buffer in parallel, and write the matching candidate results into the failure flag. The failure flag includes a status field (valid→invalid) and the corresponding version number (delete_ver=t+1).

[0109] For example: If in the candidate set {CandID#5, CandID#9}, CandID#5 contains data edge e3, and CandID#9 does not contain data edge e3, then only CandID#5 is marked as invalid as {invalid delete_ver=t+1}.

[0110] The first writer updates the failure candidate states to the global result index table, ensuring consistency. The first writer supports batch writing and write merging, reducing DRAM memory access overhead. For Modification Operations (MODs), the first writer not only invalidates old candidates but also updates the dependency subgraph generation module 1022 to expand the dependency subgraph.

[0111] For example, in the scenario where data edge e3 is deleted, the first writer updates the status of ResultIndex[CandID#5] to invalid and records delete_ver=t+1; if the input is MOD(e2), in addition to the invalid old candidate, the first writer also sends data edge e2 to the dependency subgraph generation module 1022 to continue generating new candidates.

[0112] The FSM (Finite State Machine) controller coordinates the operation sequence of each sub-unit and returns an ACK signal to the central processing unit 101. The FSM controller coordinates the aforementioned sub-modules through a finite state machine to ensure orderly processing. The state transitions of the FSM controller include: Receive status: Read incremental logs from FIFO; Retrieval status: Driven by inverted index table lookup; Marking status: Trigger comparator array and failure marker; Write back to state: Call the write module 1026 to batch update the global structure index table; Feedback status: Returns an ACK signal and version number update to the central processing unit 101.

[0113] For example, the process of the FSM (Finite State Machine) controller can be simplified as follows: receive DEL(e3) → look up {CandID#5} in the index → ​​write the failure flag → write back to the global result index table → return to the central processing unit 101: ACK(DEL,e3).

[0114] According to a preferred embodiment, the dependency subgraph generation module 1022 includes an input FIFO and task parser, a neighborhood retrieval unit, a K-order neighborhood expander, a dependency subgraph assembler, and a second writer.

[0115] like Figure 4 As shown, the pipeline processing steps of the dependency subgraph generation module 1022 include: obtaining update edge data; reading the adjacent edges of the update edge by accessing the data hypergraph area; K-order neighborhood expansion; dependency subgraph assembly; writing to the data hypergraph storage area 2002 and outputting the local dependency subgraph.

[0116] The dependency subgraph generation module 1022 is used to construct a local dependency subgraph (DepSubgraph) within a limited neighborhood radius, using the updated edge as the anchor point, when an add-on (ADD) or modify-on-delete (MOD) update occurs in the dynamic hypergraph. This module 1022 progressively extracts candidate working sets related to the update through first-order / multi-order neighborhood expansion, extracting only those related to subsequent matching. This strictly limits incremental computation to the scope of the update's influence, avoiding recalculation of the entire graph.

[0117] The input FIFO and task parser are used to obtain updated edge data and parse newly added or modified updated edge information. This input FIFO and task parser receives newly added (ADD) or modified (MOD) updated edge information from the input FIFO and operation splitter in the candidate failure handling module 1021. When a newly added hyperedge e_new={v1,v2} is received, its vertex set {v1,v2} is parsed, and the data hypergraph storage area 2002 of the storage module 200 is accessed to establish an index entry in the data hypergraph storage area 2002; if it is a modification operation, the modified vertex set is passed to the subsequent neighborhood expansion logic. The input FIFO and task parser send the updated edge and its neighbor edge set to the neighborhood retrieval device.

[0118] For example, if a new superedge e4={v1,v2} is added, the input FIFO and task parser will mark it as a new edge and prepare to retrieve its neighbor set.

[0119] After receiving the updated edge and its neighbor set from the input FIFO and the task parser, the neighborhood finder retrieves all adjacent superedges that share vertices with the updated edge. Based on the vertex set of the updated edge, the neighborhood finder quickly queries all sets of superedges containing the same vertex using an inverted index structure. The neighborhood finder then sends the superedge set to the K-order neighborhood expander.

[0120] For example, if edge e4={v1,v2} is updated, and e0={v0,v1,v2} and e1={v2,v3}, then the neighborhood retrieval tool identifies that data edge e0 and data edge e1 are adjacent to data edge e4, and adds them to the candidate neighbor set.

[0121] Preferably, after receiving the hyperedge set from the neighborhood retrieval unit, the K-order neighborhood expander is used to expand the neighborhood of the updated edge to one or more orders based on the maximum dependency order K of the pattern. If the maximum dependency of the pattern hypergraph is K=2, then not only need to include the one-order neighbors of the updated edge, but also need to continue expanding the adjacency set of these neighbors until a second-order range is reached. During the expansion process, each neighbor is visited only once to avoid duplication. The K-order neighborhood expander sends the expanded candidate results to the dependency subgraph assembler.

[0122] For example, in the pattern hypergraph {pe0(u0,u1,u2), pe1(u2,u3), pe2(u0,u3,u4)}, if the updated edge e4={v1,v2} matches the pattern edge pe1, it needs to be extended to its second-order neighboring edges to ensure that the dependency between the pattern edges pe0 and pe2 can be covered.

[0123] After receiving expanded candidate results from the K-order neighborhood expander, the dependency subgraph assembler combines the updated edges and their expanded neighbor sets into a local dependency subgraph. The data structure of the local dependency subgraph includes hyperedge IDs, a vertex set, and an adjacency list, used for subsequent candidate generation and filtering. During assembly, the dependency subgraph assembler removes duplicate neighbor edges to ensure the local dependency subgraph is compact.

[0124] For example, if the first-order neighbors of the updated edge e4={v1,v2} are {e0, e1}, and the second-order neighbors are empty, then the output of the dependent subgraph assembler is: {e4={v1,v2}, e0={v0,v1,v2}, e1={v2,v3}}. The dependent subgraph assembler sends the local dependent subgraph to the second writer.

[0125] After receiving the local dependency subgraph from the dependency subgraph assembler, the second writer stores the local dependency subgraph in the storage module 200 for subsequent pipelined processing. Preferably, the second writer writes the finally constructed local dependency subgraph to the data hypergraph storage area 2002 of the storage module 200. Figure 4As shown, the output of the dependency subgraph generation module 1022 is a local dependency subgraph, which is used by the next stage of the pipeline of the FPGA processing unit 102 (candidate generation and pruning module 1023).

[0126] For example, the aforementioned local dependent subgraph {e4,e0,e1} is written to the data hypergraph storage area 2002 of storage module 200 in the form of an adjacency list or compressed storage structure, and a "write complete" signal is returned to enter the next pipeline stage.

[0127] According to a preferred embodiment, the candidate generation and pruning module 1023 includes an input parser, a degree / label checker, a distinctness checker, a symmetry breaker, and a candidate expander.

[0128] like Figure 5 As shown, the pipeline processing steps of the candidate generation and pruning module 1023 include: reading the data hypergraph / locally dependent subgraph; expanding candidate results according to degree; expanding candidate results by adjacency drive; checking for distinctness, if the distinctness constraint is violated, the candidate results are expanded again according to degree or the candidate results are discarded; then performing symmetry breaking constraints, if the symmetry breaking constraints are violated, the candidate results are discarded; then, the candidate results are output in batches.

[0129] The candidate generation and pruning module 1023 is used to generate candidate results within the scope of the local dependency subgraph (DepSubgraph) according to the matching plan sent by the pattern parsing module 1011, and to prune through multiple constraints to reduce the calculation of redundant candidate results and invalid candidate results.

[0130] The input parser reads the data hypergraph / local dependency subgraph and parses the vertices and adjacency relationships of the local dependency subgraph. The input parser receives the local dependency subgraph from the dependency subgraph generation module 1022, reads and parses the hyperedges and vertex sets within it. The input parser parses the index, vertex set, and adjacency relationships of each hyperedge in the local dependency subgraph and determines the expansion order according to the pattern matching plan. The input parser sends the parsed candidate results to the degree / label checker.

[0131] For example, if the local dependency subgraph contains {e4={v1,v2}, e0={v0,v1,v2}, e1={v2,v3}}, the input parser organizes it into a sequence of candidate expansions, ready for subsequent pruning logic processing.

[0132] After receiving candidate results from the input parser, the degree / label checker expands the candidate results based on the degree, i.e., it performs preliminary screening of the candidate results, eliminating candidate results that do not meet the degree constraint or label constraint. If the degree requirement for pattern edge pe0 is 3, while the degree of data edge e4 is only 2, then data edge e4 is directly pruned; if the pattern vertex has a label constraint (such as it must be a user vertex), then candidate vertices that do not meet the label constraint are filtered out.

[0133] For example, in the pattern hypergraph {pe0(u0,u1,u2), pe1(u2,u3)}, if the data edge e4={v1} has a degree of 1, then it is impossible to match the pattern edge pe0 (degree = 3) and the pattern edge pe1 (degree = 2), so it is discarded.

[0134] Preferably, the degree / label checker also employs a lower bound constraint on the degree, i.e., degree(E) ≥ degree(pe). i All candidates are retained. The examples in this specification are for simplification, and the use of equality filtering is only for illustrative purposes.

[0135] The degree / label checker sends candidate results that satisfy the degree constraint or label constraint to the distinctness checker.

[0136] After receiving candidate results that satisfy the degree or label constraints from the degree / label checker, the distinctness checker checks for duplicate vertices in the mapping table. If the same vertex is found to be assigned to two pattern vertices, the candidate result is immediately discarded. The distinctness checker ensures that pattern vertices cannot be mapped to the same data vertices during the candidate result mapping process, avoiding invalid matches. The distinctness checker checks for duplicate vertices in the mapping table using a parallel comparator array; if the same vertex is found to be assigned to two pattern vertices, the distinctness checker immediately discards the candidate result.

[0137] For example, if the pattern edge {pe0(u0,u1)} is mapped to {e4(v1,v1)}, meaning that pattern vertices u0 and u1 are mapped to the same vertex v1, then the candidate result immediately becomes invalid and is discarded. The distinctness checker sends candidate results that pass the distinctness check to the symmetry breaker.

[0138] After receiving candidate results from the distinctness checker, the symmetry breaker eliminates equivalent candidate permutations caused by the symmetry of the pattern hypergraph, avoiding redundant computation. The symmetry breaker assigns order constraints (e.g., incrementing pattern edge IDs) to each pattern edge, retaining only candidate results that satisfy the order conditions during candidate generation and discarding those that do not. The symmetry breaker then sends the candidate results that satisfy the order conditions to the candidate expander.

[0139] For example: if the hypergraph {pe0, pe1} may match data edges {e0, e1} in both local dependency subgraphs, then it is stipulated that the edge must satisfy the condition. id (pe0) <edge id (pe1), and the order cannot be swapped, thus deduplicating two equivalent candidate results into one.

[0140] After receiving candidate results from the symmetry breaker, the candidate expander generates valid candidate results and outputs them in batches to the intersection constraint calculation module 1024. Each candidate result contains a mapping relationship between pattern edges and data edges. Pattern edges refer to the edges in the pattern hypergraph to be queried or mined, i.e., pe. i Data edges refer to the edges in the original hypergraph, that is, the edges e in the edge set. i .

[0141] For example, if the final result of pruning the local dependency subgraph is pe0→e0, pe1→e1, then the candidate expander generates candidate results {pe0:e0, pe1:e1} and outputs them.

[0142] According to a preferred embodiment, the intersection constraint calculation module 1024 includes a bitmap register, a logic AND operator, a popcount counter, and an early truncation logic unit.

[0143] The intersection constraint calculation module 1024 is used to perform intersection calculations on the vertex relationships in the candidate results after the candidate results are generated, in order to verify whether they satisfy the adjacency relationships and intersection constraints in the mode hypergraph. The intersection constraint calculation module 1024 implements the intersection calculation with hardware pipeline circuitry, and by combining a bitmap register, a logic AND operator, a popcount counter, and an early truncation logic unit, it can effectively reduce the computational overhead of failed candidate results while maintaining parallelism.

[0144] like Figure 6 As shown, the bitmap register reads the candidate results, encodes the candidate results (the set of vertices of the candidate hyperedges) into a bitmap format, and stores it on the on-chip module. Each bit in the bitmap corresponds to whether a vertex belongs to the hyperedge, and fast intersection calculation can be achieved through simple bit operations.

[0145] For example, if candidate hyperedge e0={v1,v2,v4}, the bitmap register will encode the bitmap as [0,1,1,0,1], indicating that vertices v1, v2, and v4 are in active positions. That is, candidate hyperedge e1={v2,v3,v4} is encoded as [0,0,1,1,1].

[0146] like Figure 6As shown, after reading the candidate results, the bitmap register reads a candidate entry {CandID, mapping(E0, E1, ...)}.

[0147] Subsequently, the bitmap register performs the operation of loading the candidate set and the intersection constraint set L, where L is the set of all intersection constraints to be verified in this mode.

[0148] Loop Iteration Control: To iterate through all constraints, a loop variable i=1 is set. After each iteration, the condition i>|L| is used to determine whether all constraint verifications have been completed. |L| represents the length of the constraint list, i.e., the total number of constraints.

[0149] If yes, i is greater than the total number of constraints |L|, then all constraints pass, and the bitmap register inputs the data into the deduplication pre-filtering module 1025. If not, the bitmap register performs the operation of retrieving the i-th constraint and continues the verification.

[0150] Faster lookup path: e.g. Figure 6 As shown, for the current constraints, the bitmap register first determines whether it can directly look up the DataCap table.

[0151] If the intersection of the edge pair can be directly looked up in the table (yes), that is, the intersection of the edge pair has been pre-calculated, the bitmap register can directly obtain the intersection cardinality through inter_cnt=DataCap[index], skip the bitmap calculation step, and directly enter the cardinality comparison stage.

[0152] If a table lookup is not possible (no), the bitmap register enters the hardware calculation path.

[0153] First, the bitmap register loads the bitmap B(E) that participates in the edge. a The vertex set is encoded into a bitmap format. Then, the logical AND operator performs block AND operations and accumulates the popcount counter to calculate partial_cnt, as shown below. Figure 6 As shown.

[0154] The bitmap register sends the candidate results in bitmap form to the logical AND operator.

[0155] After receiving candidate results from the bitmap register, the logic AND operator performs a bit-by-bit logic AND operation on the bitmaps of two or more candidate superedges to obtain the intersection result of the bitmaps. The hardware circuitry of the logic AND operator supports multi-channel parallel operation, which can complete the intersection operation of multiple candidate combinations at once.

[0156] For example, performing a block AND operation on the bitmaps of data edge e0 and data edge e1 yields [0,0,1,0,1], indicating that the intersection result is {v2,v4}.

[0157] The popcount counter is used to count the number of vertices in the intersection result and compare the number of vertices with the intersection cardinality in the pattern constraint; if the results match, the constraint verification passes. Preferably, the popcount counter is implemented using a parallel addition tree, which can complete the weighted summation of the bitmap within one clock cycle.

[0158] For example: if the intersection of the pattern superedges pe0 and pe1 requires a cardinality of 2, and the cardinality of the result {v2,v4} obtained in the previous step is exactly 2, then the candidate result passes the constraint verification.

[0159] During the calculation, the early stop logic is based on Early-Stop decision logic (see...). Figure 6 The `partial_cnt` parameter is monitored in real time. `partial_cnt` is the cumulative sum of the vertex intersections in the currently processed blocks. If the determination result is yes, meaning the current partial sum cannot satisfy the final constraint (e.g., it is far below the threshold), it is immediately discarded, terminating the subsequent calculation of that candidate to save power. Specifically, to avoid full calculation of failed candidate results, during the partial comparison stage, if the truncation logic determines that the current candidate cannot satisfy the constraint, it immediately terminates the calculation and discards the candidate. This significantly reduces power consumption and latency.

[0160] For example: if a pattern constraint requires an intersection of ≥3, but during the comparison of the first 10 bitmaps, it has been found that at most one common vertex can be obtained, and the remaining bitmap length is insufficient to provide two vertices, then the calculation of this candidate should be terminated early and there is no need to continue.

[0161] If the judgment result is negative, i.e. the Early-Stop judgment logic is not satisfied, then inter_cnt is calculated (inter_cnt is the total after all bits have been counted). The final partial_cnt is equal to the final inter_cnt if and only if all bitmap blocks have been processed and no early truncation has been triggered.

[0162] Result Verification and Update: The logic unit prematurely truncates after completing the calculation to obtain inter_cnt and then proceeds to the step of determining whether inter_cnt = k, as follows: Figure 6 As shown.

[0163] If the judgment result is negative, that is, inter_cnt is not equal to the preset constraint base number K, then the candidate result is discarded; if the judgment result is positive, that is, inter_cnt is equal to K, then it means that the current i-th constraint has passed, execute the i=i+1 operation and return to the loop start point to start the verification of the next constraint.

[0164] The intersection constraint calculation module 1024 also includes an output port. The output port outputs the candidate results verified by the intersection constraint in batches for further processing by the deduplication and pre-filtering module 1025. The output data of the output port includes candidate mapping relationships, the cardinality of the intersection results, and the constraint verification status (pass / fail).

[0165] For example, if the candidate {pe0→e0, pe1→e1} passes the intersection constraint verification, the output format is {CandID#12, status=valid, inter_size=2}, and it is passed to the deduplication pre-filtering module 1025.

[0166] Through the intersection constraint calculation module 1024, the hardware accelerator can quickly perform adjacency and intersection constraint verification in a hardware-based manner, avoiding the large number of set operations and loop traversals in traditional software methods. Combined with the Early Stop strategy, this intersection constraint calculation module 1024 can significantly reduce average latency and improve overall pipeline processing efficiency in large-scale candidate scenarios. Compared with existing technologies, this design has significant advantages in both throughput and energy efficiency.

[0167] According to a preferred embodiment, the deduplication pre-filtering module 1025 includes a normalized key generator, a Bloom filter, and a pre-filter output terminal. The deduplication pre-filtering module 1025 is used to avoid duplicate storage and redundant writing of candidate results, and is a crucial component in ensuring system efficiency and consistency.

[0168] The core idea of ​​the deduplication pre-filtering module 1025 is to generate a normalized key (CanonicalKey) for the candidate results and use a probabilistic pre-lookup mechanism for fast filtering. Only results that are "likely new" will enter the central processing unit 101 for further precise querying, thereby significantly reducing the global index access pressure.

[0169] like Figure 7 As shown, the normalization key generator receives candidate results and generates normalization keys, which means mapping candidate results to unique key values.

[0170] The canonical key generator is used to convert candidate mappings into order-independent canonical keys, which serve as unique identifiers for subsequent deduplication and writing.

[0171] Specifically, the normalized key generator arranges the data superedge numbers in the candidate results in a predetermined order (such as ascending order or pattern position order) according to the symmetry breaking constraints sent by the pattern parsing module 1011, and combines them with pattern_id to form a fixed-length key value (which can be compressed to 64 / 128 bits by the on-chip hash kernel).

[0172] For example, regardless of the generation order, the pattern hyperedge {pe0→e0, pe1→e4, pe2→e5} will eventually be normalized into a data edge {e0,e4,e5}, with the corresponding normalization key Key=H(pattern_id || e0 || e4 || e5).

[0173] The normalized key generator sends the normalized keys to the Bloom filter.

[0174] After receiving the normalized key from the Bloom filter, the Bloom filter quickly determines whether a candidate result already exists.

[0175] Specifically, a Bloom filter (a probabilistic data structure based on bit arrays and multiple hash functions) performs a fast lookup of normalized keys.

[0176] The principle of a Bloom filter is to map the normalized key to multiple positions in a bit array using multiple hash functions. If any of these positions contain 0, the candidate result is definitely new; if all positions contain 1, the candidate result may already exist (with a small probability of false positives).

[0177] like Figure 7 As shown, Bloom filters are used for Bloom queries, i.e., fast queries.

[0178] like Figure 7 As shown, if the result of the quick lookup is negative (0 exists), then the Bloom filter marks the candidate result as NEW and performs a BF bit setting operation, setting the bit pointed to by the hash position mapped to the candidate result to 1. Finally, the Bloom filter sends the candidate result to the result writing module 1026.

[0179] For example, the candidate normalized key (pattern_id, e0, e4, e5) is mapped to the bit array position [7,12,29] through three sets of hash functions. If the 12th bit is 0, then the candidate normalized key must be a new result. Bit 12 (and other mapped bits 7 and 29) are set to 1 to ensure that subsequent identical candidate keys are identified as existing states in the fast lookup stage.

[0180] like Figure 7 As shown, if the results of the quick pre-lookup are all 1s, the candidate result is determined to be "possibly already existing". The candidate result is then sent to the central processing unit 101 for precise querying or written to the request queue via the pre-filter output. For branches with a query result of 1, the central processing unit 101 performs a precise query on the global result index table to determine if the candidate result exists.

[0181] If the exact query result is found to exist, the central processing unit 101 determines it to be a true duplicate and discards it. If the exact query result is not found, it means that the Bloom filter has misjudged. At this time, the central processing unit 101 sends the exact query result to the Bloom filter, triggers the BF bit setting process, and the Bloom filter performs the BF bit setting operation again and updates its own state. Finally, it sends the corrected candidate result to the result writing module 1026.

[0182] Example of an exact query result that does not exist: The Bloom filter has already written the candidate normalized key A(pattern_id, e 10 , e 15 , e 20 ) and candidate normalized key B(pattern_id, e5, e 25 , e 40 At this point, bits 5, 10, 15, 20, 25, and 40 in the bit array are all set to 1. When the new candidate normalized key C(pattern_id, e 10 , e 25 ,e 40 When the hash function maps the bit array to position [10, 25, 40], the Bloom filter detects that bits 10, 25, and 40 in the bit array are all 1, and enters the branch where the query result is 1. At this time, the central processing unit 101 queries the global result index table and finds that the table does not contain the key C(pattern_id, e 10 , e 25 , e 40 The Bloom filter fails to detect the absence of a candidate result, thus determining that the current match is a false positive. To eliminate false positives and ensure eventual consistency, in response to receiving the information indicating a non-existent result from the central processing unit 101, the Bloom filter needs to re-trigger the BF bit setting operation, setting the corresponding bit to 1 again and updating the Bloom filter state. This dynamic update mechanism ensures that subsequent identical candidate results can be directly intercepted by the Bloom filter, thereby reducing unnecessary redundant and precise queries.

[0183] Through the above design, the deduplication pre-filtering module 1025 achieves fast batch pre-lookup on the FPGA processing unit 102, significantly reducing the number of times the central processing unit 101 and the storage module 200 access the global result index. In large-scale dynamic graph pattern mining scenarios, this mechanism can significantly reduce memory access pressure and latency, while maintaining the uniqueness and consistency of candidate results.

[0184] The deduplication pre-filtering module 1025 also includes a batch commit and a Bloom updater.

[0185] The batch commit and Bloom updater are used to aggregate NEW / REBIRTH candidate results into batches and send them to the result writing module 1026, while simultaneously updating the Bloom bit array to reflect the latest deduplication status. The implementation is as follows: for candidate results in the same batch, bit write merging is first performed in the on-chip cache, and then the results are uniformly refreshed to the Bloom array; when outputting externally, {Key, mapping details, version stamp} are carried to reduce the number of memory accesses by the result writing module 1026.

[0186] For example: a batch key {K1,K2,…,K...} 64 Once a version is declared NEW / REBIRTH, it is committed uniformly. Multiple words in the Bloom bit are merged into a small number of write-back operations, reducing the occupation of on-chip ports.

[0187] Technical Effects: By introducing a combined mechanism of "normalized key, multi-hash blobs, batch submission, and precise query rollback by the central processing unit 101" in the deduplication pre-filtering module 1025, this embodiment significantly reduces the proportion of repeated writes and DRAM write amplification while maintaining result consistency. Pipeline implementation ensures that the deduplication pre-filtering module 1025 can handle the upstream intersection constraint calculation module 1024 at line speed, and leaves a very small number of boundary cases to the central processing unit 101 for precise processing, thereby achieving an adjustable engineering trade-off between resource consumption, throughput, and false positive rate.

[0188] The result writing module 1026 is used to write candidate results that have been determined as "new results" by the deduplication pre-filtering module 1025 into the candidate result index storage area 2005 of the storage module 200 in batches, so as to complete the update and maintenance of the global result index. The result writing module 1026 not only ensures the consistency of candidate writing, but also supports version management and idempotent writing, thereby improving the correctness and efficiency of the system in dynamic update scenarios.

[0189] The result writing module 1026 includes a batch write buffer, a version number check and consistency control unit, and a global result index interface module.

[0190] like Figure 8 As shown, the batch write buffer receives the output of the deduplication pre-filtering module 1025. That is, the result write module 1026 receives candidate results determined as new results from the deduplication pre-filtering module 1025. The batch write buffer temporarily stores the received set of candidate key-value pairs, forming a batch processing queue.

[0191] The batch write buffer aggregates multiple candidate write requests, converting scattered requests into a single burst write request. For example, if 20 candidate results are detected as new results, they are aggregated and sent to storage module 200 in a single commit, thereby reducing random access to storage module 200. The batch write buffer then sends a single burst write request to the version number check and consistency control unit.

[0192] After receiving a burst write request, the version number check and consistency control unit assigns a version number (ver_id) to each candidate result. The version number check and consistency control unit executes idempotency control logic, performing version number checks or idempotency checks (see [link to documentation]). Figure 8 The idempotent control logic is as follows.

[0193] If a candidate result is detected to have already been written, it is considered a duplicate candidate. The candidate result will not be inserted again and will be discarded directly. Figure 8 (Duplicate candidate branches are discarded). If a candidate result has been marked as failed (tombstone), then version regeneration logic is executed.

[0194] For example, if candidate key {CandID#7} becomes invalid at time t and reappears at time t+2, its status is updated to {valid, ver_id=t+2}. If the candidate result is new, it is assigned the current version number and marked as valid, and the write operation is performed directly. The version number check and consistency control unit sends the candidate results with version numbers to the global result index interface module.

[0195] After receiving the candidate results with version numbers from the version number check and consistency control unit, the global result index interface module performs a final write-back of the processed batch data through the parallel bus protocol, writing it into the global result index storage area 2005 of the storage module 200.

[0196] The global result index interface module sends a write acknowledgment (ACK) to the global result index maintenance module 1014 of the central processing unit 101.

[0197] For example, after the candidate set {CandID#7, CandID#8} is written, an ACK is returned: 2 entries committed, so that the central processing unit 101 can perform synchronous maintenance.

[0198] In summary, the result writing module 1026 achieves efficient and reliable storage and maintenance of candidate results through batch writing, version control, and idempotency mechanisms. With the support of the result writing module 1026, this invention not only ensures the correctness and consistency of the result index during dynamic hypergraph updates, but also maintains high throughput performance even with frequent updates and rollbacks.

[0199] Compared with existing hypergraph pattern mining systems, the accelerator in this embodiment has the following technical advantages in terms of hardware architecture and dynamic update mechanism: (1) Improved incremental update efficiency: By performing dynamic incremental log recording and neighbor dependency identification on the CPU side, and performing candidate failure processing and incremental recalculation of dependency subgraph on the FPGA processing unit 102, the system avoids the high overhead of global recalculation and achieves fast updates in the local range.

[0200] (2) Co-optimization of computation and storage: By introducing the DRAM multi-channel storage module 200 and the on-chip cache management mechanism, combined with the pipelined execution inside the FPGA processing unit 102, the bandwidth utilization and cache hit rate of candidate generation and intersection screening are significantly improved.

[0201] (3) Candidate size pruning: Introducing degree constraints, pattern-aware pruning, and symmetry breaking mechanisms during the candidate generation stage can reduce redundant candidates at the source and reduce the burden of intersection calculation and consistency check. It should be noted that the embodiment uses a lower degree constraint (≥) to improve the recall rate, and then combines pattern-aware pruning and symmetry breaking mechanisms to ensure the correctness of the matching results.

[0202] (4) Efficient failure handling mechanism: The versioned global structure index structure is adopted, combined with the fast failure mark on the FPGA processing unit 102, which can complete the failure judgment and deletion of candidate results in milliseconds, ensuring the real-time performance and consistency of the result set.

[0203] (5) Interface collaboration expansion capability: The communication and interface module supports multi-channel parallel access and asynchronous task instruction issuance, and can maintain good scalability in the environment of multi-core central processing unit 101 and clustered FPGA processing unit 102, providing hardware support for supergraph mining in large-scale dynamic graph scenarios.

[0204] Example 2 This embodiment is a further improvement on embodiment 1, and repeated content will not be described again.

[0205] This embodiment provides a hardware acceleration method for dynamic hypergraphs based on FPGA. The method includes: a central processing unit 101 reads and parses the input pattern hypergraph to obtain a matching plan and sends it to the FPGA processing unit 102; accurately verifies the constraints involving high-order intersections and the unique mapping conditions of vertices to handle the candidate expansion and backoff processing of hyperedges with very high degree, ensuring correctness; the FPGA processing unit 102 locates and marks candidate results that fail due to update operations; expands the neighborhood domain in the data hypergraph with the updated edge as the anchor point to construct a locally dependent subgraph; within the scope of the locally dependent subgraph, performs pre-pruning based on the matching plan and executes multiple constraint screening to reduce redundant candidates; performs bitmap intersection operation on the pruned candidate results to perform constraint verification, discarding candidate results that fail constraint verification to achieve early truncation; generates normalized keys based on the candidate results that pass constraint verification for fast pre-lookup, thereby achieving deduplication pre-filtering; and sends the candidate results that pass deduplication pre-filtering to the central processing unit 101.

[0206] According to a preferred embodiment, the method further includes: when the order k of the intersection calculation is greater than 3 or the degree of the candidate hyperedge exceeds a threshold, the central processing unit 101 performs the computation process, and the FPGA processing unit 102 performs the non-computation process in parallel pipeline. Here, the non-computation process includes candidate failure handling, dependent subgraph generation, candidate generation and pruning (for candidates that have not exceeded the threshold), intersection constraint calculation (for regular calculations for k≤3), deduplication pre-filtering, and result writing. These processes are parallel to the complex computation being performed by the central processing unit 101. The computation process includes high-order intersection calculation and candidate expansion and fallback processing for hyperedges with extremely high degrees.

[0207] Higher-order intersection computation occurs when pattern matching requires verifying the vertex intersection relationships between more than three candidate hyperedges (k>3), significantly increasing the logical complexity of multi-way set intersection operations. Implementing such computations in parallel using hardware circuitry on the FPGA processing unit 102 would result in excessive logic resource consumption, making the design inefficient and cumbersome. Therefore, these computations are rolled back to the central processing unit 101, leveraging its flexibility in handling complex and irregular logic to ensure the absolute correctness of the results.

[0208] For candidate expansion and backoff processing of ultra-high degree superedges: When a candidate superedge contains an unusually large number of vertices (degree exceeding the threshold), finding a match for it will face a combinatorial explosion problem. The massive number of intermediate candidates generated will put enormous pressure on the on-chip cache and pipeline control of the FPGA processing unit 102. At the same time, the backtracking (backoff) decision required when a match fails is also extremely complex. Delegating these tasks to the central processing unit 101 can fully utilize its large memory capacity and powerful serial control flow capabilities to more robustly handle these extreme but possible edge cases.

[0209] To better explain this invention, an example is given. There is a pattern hypergraph P with the structure {pe0{u0,u1,u2},pe1{u2,u3},pe2{u0,u...}. 3, Given a hypergraph G with the structure {e0{v0,v1,v2},e1{v2,v3},e2{v1,v3,v5},e3{v0,v3,v4}}, at time t+1, delete an existing data edge e2 and add two new data edges e4={v2,v5} and e5={v1,v5,v6}. First, we briefly introduce the hypergraph pattern mining process when no graph update occurs.

[0210] It should be noted that, for the sake of explaining the process, the following example uses "equal degree (=)" as the screening condition for candidate superedges to simplify the size of the candidate set and facilitate the demonstration of the steps; in actual implementation, this invention uses "lower bound of degree (≥)" as the screening condition, that is, only when the degree of the candidate superedge is not less than the degree of the corresponding pattern superedge is it retained.

[0211] S100: Mining phase in normal supergraph mode.

[0212] In this embodiment, the input candidate result (E) i , pe i Following a streamlined processing path, operations such as pruning, intersection constraint verification, and deduplication are performed sequentially to generate a valid result. The specific steps are as follows: Figure 2 As shown.

[0213] S110: Schema hypergraph analysis (executed by central processing unit 101).

[0214] In this embodiment, the input pattern hypergraph P is first read and parsed. The result is: (1) Degree constraint D(pe) i ): Number of vertices in each pattern hyperedge (and optional vertex / hyperedge label constraints): degree(pe0)=3, degree(pe1)=2, degree(pe2)=3; (2) Matching order: The processing order is determined based on selectivity (fewer candidates are given priority) and degree constraint. In this example, it is {1,0,2}, that is, {pe1>pe0>pe2}. (3) Pattern hyper-graph relationships: If two pattern hyper-edges share a pattern vertex, they are considered to be adjacent. Record the maximum dependency order K in the pattern hyper-graph and record the intersection constraint: |pe i ∩pe j |=k (forming patternCap); In this example, the intersection constraints of the pattern hypergraph are: |pe0∩pe1|=1, |pe0∩pe2|=1, |pe1∩pe2|=1, and the pattern intersection array patternCap is: (4) Symmetry breaking constraint: For interchangeable pattern hyperedge sets (symmetric classes), an ordered binding rule is specified (e.g., ascending order of lexicographical order of (|E|, min V(E), edge_id)) to eliminate symmetric redundancy; in this example, pattern edge pe0 and pattern edge pe2 are interchangeable, so it is specified that their corresponding data hyperedge numbers satisfy edge_id(pe0). <edge_id(pe2)。

[0215] (5) Dissimilarity constraint: Different pattern hyperedges must be mapped to different data hyperedges.

[0216] Simultaneously, a data intersection table, dataCap, is pre-constructed for the data hypergraph G to record the cardinality of the intersection between each pair of hyperedges: The above information serves as a matching plan for subsequent candidate generation and verification, and can be reused in dynamic scenarios. In specific implementations, the table storage of this invention can adopt Compressed Sparse Row (CSR) format or other equivalent sparse storage methods to reduce storage overhead and accelerate access efficiency.

[0217] S120: Candidate generation and pruning (CPU→FPGA collaboration).

[0218] This stage, without traversing the entire graph, utilizes pattern structure to perform pre-pruning of candidates, significantly reducing the candidate size. The process is as follows: S121: Preliminary selection (degree / label).

[0219] For each pattern superedge pe i Candidate set Cand(pe) is obtained by screening in the data hypergraph G. i )={E | |E| = D(pe i The label constraints satisfy: For pe0 (degree = 3): Cand(pe0) = {e0, e2, e3}; For pe1 (degree = 2): Cand(pe1) = {e1}; For pe2 (degree = 3): Cand(pe2) = {e0, e2, e3}.

[0220] Form an initial candidate set (a Cartesian product that is not order-aware and allows duplicates): {R}_0={e0,e1,e0},{e0,e1,e2},{e0,e1,e3},{e2,e1,e0},{e2,e1,e2},{e2,e1,e3},{e3,e1,e0},{e3,e1,e2},{e3,e1,e3}.

[0221] To simplify the explanation, this example only shows cases where |E|=D(pe) i The minimum candidate set of ), in practical implementation, this invention uses a degree lower bound constraint for initial screening, that is, retaining all ) satisfying |E|≥D(pe) i Candidates whose label constraints are met.

[0222] S122: Anchor point / high-selectivity start.

[0223] We select the pattern superedge with the smallest cand size or the one with unique label constraints as the starting point, and only expand its candidates. In this example, pe1 has the smallest size, so we start matching from pe1.

[0224] S123: Pattern-aware adjacency-driven extension.

[0225] The expansion order is {pe1→pe0→pe2}. Each time, a new candidate is generated only within the adjacency domain of the selected candidate, and the intersection must be equal to k required by the pattern (i.e., the number of intersections of pattern edges in the pattern intersection array patternCap).

[0226] When moving from {pe1→pe0}, it is necessary to satisfy |pe0∩pe1|=1, that is, Cand(pe1) only retains the superedges whose intersection with e1 is 1. According to the pattern intersection array patternCap, the intersection of e0, e2, e3 with e1 is 1. Therefore, the candidate of pe0 is still {e0, e2, e3}.

[0227] When moving from {pe0→pe2}, the conditions |pe2∩pe1|=1 & |pe2∩pe0|=1 must be satisfied. Since the intersection of any two edges between {e0,e2,e3} is 1, and their intersection with e1 is also 1, therefore, when selecting: {R}_1 = (e0, e1, e2), (e0, e1, e3), (e2, e1, e0), (e2, e1, e3), (e3, e1, e0), (e3, e1, e2).

[0228] S124: Symmetry-breaking constraint.

[0229] For the pattern edges with symmetry classes in the pattern hypergraph (for example, {pe0, pe2} are interchangeable), the system only retains the combinations that satisfy edge_id(pe0) < edge_id(pe2) in the candidate results, and all other equivalent permutations are pruned. In this example, pe0 and pe2 are interchangeable. By applying the constraint edge_id(pe0) < edge_id(pe2) (according to the numbers e0 < e2 < e3), (e2, e1, e0), (e3, e1, e0), and (e3, e1, e2) are eliminated. The candidate results are as follows: {R}_2 = (e0, e1, e2), (e0, e1, e3), (e2, e1, e3).

[0230] The candidate combinations obtained through this step only cover the local area consistent with the pattern adjacency relationship, avoiding the full-table Cartesian product.

[0231] S130: Intersection constraint screening.

[0232] Two modes of the FPGA processing unit 102 (pairwise / k ≤ 3) and the CPU (large k / witness adjudication).

[0233] In this embodiment, to ensure that the candidate is strictly isomorphic to the pattern, the system performs precise verification on the candidate combinations generated by S120: Multi-way (k-way) intersection and vertex consistency: For multiple pattern edges involving the same pattern vertex (in this example, k = 3), verify |E_{pe0} ∩ E_{pe1} ∩ E_{pe2}| = |pe0 ∩ pe1 ∩ pe2|, and for each pattern common vertex, require that there is a unique data vertex as its image (to avoid ambiguity).

[0234] The three-way intersection of the pattern in this example is 0 (pe0 ∩ pe1 ∩ pe2 = ), so the candidate three-way intersection must also be 0. To improve efficiency, the FPGA processing unit 102 uses the exact calculation of "bitmap AND + popcount" and pre-truncation: terminate immediately when the count can no longer satisfy the equation; the central processing unit 101 is responsible for result aggregation and (if necessary) final adjudication.

[0235] In this example, Candidate 1: (pe0, pe1, pe2) → (e0, e1, e2), e0 ∩ e1 ∩ e2 = {v2} ∩ e2 = →0, consistent with the pattern; Candidate 2: (pe0,pe1,pe2)→(e0,e1,e3), e0∩e1∩e2={v2}∩e3= →0, consistent with the pattern; Candidate 3: (pe0,pe1,pe2)→(e2,e1,e3), e0∩e1∩e2={v3}∩e3={v3}→1, which violates the multi-way intersection equation and is therefore deleted. After precise verification via S130, the candidate results are as follows: {R}_3=(e0,e1,e2),(e0,e1,e3).

[0236] Both then proceed to the deduplication step.

[0237] S140: Deduplication screening (FPGA processing unit 102 pre-filtering + central processing unit 101 data entry).

[0238] In this embodiment, the candidate results obtained after intersection filtering may still have equivalent permutations or duplicate mappings. To ensure the uniqueness of the results, the system generates a normalized mapping key (Canonical Key) for each candidate result.

[0239] Key generation: Candidate results are first arranged according to the pattern hyperedge order and symmetry breaking constraints to form a normalized sequence, such as (pattern_id,e0,e1,e3).

[0240] Deduplication Check and Writing: The system performs deduplication checks in the global result index table ResultIndex. If the key does not exist, create a new record {key, create_ver, delete_ver=varnothing, state=valid}; if the key already exists, skip the write operation to avoid duplicate storage.

[0241] Idempotent mechanism: To ensure correct deduplication detection even in parallel or incremental update scenarios, the system employs a two-level mechanism: FPGA side: Lightweight indexes such as Bloom filters are used for fast pre-filtering to quickly eliminate the vast majority of existing results; On the CPU side: For the small number of candidates that have passed the pre-filtering, further precise deduplication and insertion are performed in the hash table or balanced index structure.

[0242] The final result is Result={(e0,e1,e2),(e0,e1,e3)}; Technical effects: By introducing pattern-aware pruning (adjacency-driven + strict intersection equality + symmetry breaking constraint + distinctness preconditioning) in step S120, the candidate size is significantly reduced; the global intersection and vertex consistency verification in step S130 ensures the correctness of the result; the normalized key and idempotent writing mechanism in step S140 further ensure the uniqueness and reusability of the result.

[0243] Therefore, this embodiment not only eliminates redundant calculations and storage in static scenarios, but also provides direct support for subsequent dynamic incremental updates (when deleting / adding candidates), achieving a balance between correctness, uniqueness, and efficiency.

[0244] S200: Dynamic Hypergraph Update (executed by Central Processing Unit 101).

[0245] In this embodiment, the dynamic hypergraph update operation is performed by the central processing unit 101 (CPU side). When the system receives a graph update signal at time t+1, it is assumed that a composite update operation needs to be performed on the hypergraph: deleting an existing hyperedge e2 and adding two new hyperedges e4={v2,v5} and e5={v1,v5,v6}. The central processing unit 101 synchronously modifies the storage structure in the order of deletion followed by addition: first, e2 is removed from the index, and then the newly added hyperedges e4 and e5 are incorporated into the existing data structure to maintain the consistency of the hypergraph data.

[0246] During the update process, the central processing unit 101 identifies and records the dependencies between the newly added superedges e4 and e5; this identification is based on the current structure after the deletion takes effect. This information is organized into incremental log entries for subsequent incremental computation. The structure of the incremental log array includes: update type, updated edge number, and updated vertex set; in optional implementations, it may also include adjacent edge numbers and intersection cardinality for accelerating subsequent incremental computation. The incremental log entries generated in this embodiment are: {0, 2}: where “0” represents a deletion operation and “2” represents the deleted superedge numbered e2; {1, 4, {2,5}}: where “1” represents the addition operation, “4” represents the newly added superedge number e4, and “{2,5}” represents the vertex set {v2,v5} of e4.

[0247] {1, 5, {1,5,6}}: where “1” represents the addition operation, “5” represents the newly added superedge number e5; “{1,5,6}” represents the vertex set {v1,v5,v6} of e5.

[0248] By using the incremental logs described above, which involve deleting, modifying, and then adding, the system can locate the affected candidate result subgraphs based on a consistent structural view in subsequent stages. It can then perform candidate failure processing and incremental recalculation only on the relevant areas, without needing to perform global matching, thereby significantly reducing computational overhead and improving update response speed.

[0249] S300: Candidate failure handling (executed by FPGA processing unit 102).

[0250] In this embodiment, candidate failure handling applies not only to deletion operations but also to addition and modification operations. The specific rules are as follows: Remove superedges: Any candidate result containing a removed superedge is marked as invalid, and the deletion version number is written to the result index ResultIndex.

[0251] Modify hyperedge: When the vertex set of a hyperedge changes, the candidate results in which the hyperedge participates no longer satisfy the original pattern constraints, so all corresponding candidate results are marked as invalid.

[0252] Adding a new superedge: The newly added superedge serves as the starting point for subsequent incremental recalculation and is used to generate new candidate subgraphs without affecting the validity of the existing candidate results.

[0253] For example, in this embodiment, when the hyperedge e2 is deleted, (e0,e1,e2) in the candidate results is marked as invalid.

[0254] By using the above rules, the system can quickly locate and remove invalid results when dynamic updates occur, while delaying the processing of new results to the S400 incremental calculation stage, thereby ensuring the correctness of candidate results and the efficiency of updates.

[0255] S400: Incremental recalculation.

[0256] In this embodiment, incremental recalculation starts with updating the edges, generates and filters candidate subgraphs within the affected local area, and writes them into the result index after isomorphism removal.

[0257] S410: Subgraph generation dependent (starting from the updated edge).

[0258] In this embodiment, the central processing unit 101 uses the updated edge recorded in step S200 as an anchor point to generate a local dependency subgraph associated with it, which is used for subsequent candidate generation and filtering. The specific process is as follows: S411: Update the edge as the starting point.

[0259] After a new hyperedge e_u is written to the incremental log, the system first retrieves the adjacency relationship of the hyperedge in the data hypergraph to obtain its first-order neighbor set. The neighbor set and the cardinality of the intersection can be obtained directly from the log information recorded by S200, or through table lookup operations.

[0260] S412: Multi-order neighborhood expansion.

[0261] Based on the structural characteristics of the pattern hypergraph, if a pattern contains adjacency dependencies spanning multiple hyperedges, the system recursively expands to a set of K-order adjacency edges (where K is the maximum dependency order of the pattern). For example, when the pattern hypergraph contains two indirectly adjacent pattern hyperedges, the system needs to expand to second-order adjacency edges to ensure that the dependency subgraph covers all possible matching paths. Assuming the pattern hypergraph is {(pe0,{u0,u1}),(pe1,{u1,u2}),(pe2,{u2,u3})}, and K=2, then all e... i The second-order neighboring edges are extended to the dependency graph candidates.

[0262] S413: Dependency graph generation.

[0263] The system extracts the hyperedges recorded in the dependency graph candidate as a dependency graph, whose data structure includes: eid (superedge number, used to uniquely identify a subgraph edge); degree (hyperedge degree, used for quick degree constraint checking); vid (vertices set, used for intersection constraint calculation).

[0264] In this example, K=1 for {pe0{u0,u1,u2},pe1{u2,u3},pe2{u0,u3,u4}}, so only the first-order neighbors {e0,e1} of the updated edges e4,e5 are extended to the dependency subgraph. Therefore, the new dependency graph is: 0,3,{0,1,2}: indicates that the superedge is numbered 0 and has 3 vertices, namely v0, v1, and v2. 1,2,{2,3}: indicates that the superedge is numbered 1 and has 2 vertices, v2 and v3. 4,2,{2,5}: This indicates that the hyperedge is numbered 4 and has 2 vertices, v2 and v5. 5,3,{1,5,6}: This indicates that the superedge is numbered 5 and has 3 vertices: v1, v5, and v6.

[0265] By updating the edge-driven dependent subgraph generation step, the system can strictly limit incremental computation to the updated region and its related neighbors. Compared to full graph recalculation, this method significantly reduces the candidate space, lowers computational overhead, and provides efficient data preparation for subsequent candidate generation (S420), intersection filtering (S430), and deduplication filtering (S440).

[0266] S420: Candidate generation.

[0267] In this embodiment, the logic for candidate generation is the same as that for S120 hyperedge filtering, except that the candidate space is limited to the dependent subgraph generated in S410, rather than the global hypergraph.

[0268] The system generates candidate results within the scope of the dependent subgraph based on the degree constraint, intersection constraint, and symmetry breaking constraint of the mode hypergraph.

[0269] First, the initial selection (degree / label) in step S121 yields the following: For pe0 (degree = 3): Cand(pe0) = {e0, e5}; For pe1 (degree = 2): Cand(pe1) = {e1, e4}; For pe2 (degree = 3): Cand(pe) 2) ={e0,e5}.

[0270] {R}_0=(e0,e1,e0),(e0,e1,e5),(e5,e1,e0),(e5,e1,e5),(e0,e4,e0),(e0,e4,e5),(e5,e4,e0),(e5,e4,e5); Secondly, through step S122 anchor point / high selectivity, the expansion order is {pe0→pe1→pe2}; Then, through the mode-aware adjacency-driven expansion in step S123, it is necessary to ensure that: |pe1∩pe0|=1 & |pe2∩pe1|=1 & |pe2∩pe0|=1; Candidate 1: (pe0,pe1,pe2) → (e0,e1,e0), e0 ∩ e0 = →0, violates "|pe0∩pe2|=1", delete; Candidate 2: (pe0,pe1,pe2) → (e0,e1,e5), e5 ∩ e1 = →0, violates "|pe1∩pe2|=1", delete; Candidate 3: (pe0,pe1,pe2)→(e5,e1,e0), e5∩e1= →0, violating "|pe1∩pe0| = 1", deleted; Candidate 4: (pe0, pe1, pe2) → (e5, e1, e5), e5∩e5 = →0, violating "|pe0∩pe2| = 0", deleted; Candidate 5: (pe0, pe1, pe2) → (e0, e4, e0), e0∩e0 = →5, violating "|pe0∩pe2| = 1", deleted; Candidate 6: (pe0, pe1, pe2) → (e0, e4, e5), satisfying the constraints, retained; Candidate 7: (pe0, pe1, pe2) → (e5, e4, e0), satisfying the constraints, retained; Candidate 8: (pe0, pe1, pe2) → (e5, e4, e5), e5∩e5 = →5, violating "|pe0∩pe2| = 1", deleted.

[0271] Then, through the symmetry-breaking constraints in step S124, the symmetry class {pe0, pe2} stipulates that edge_id(pe0) < edge_id(pe2), and retain the group with a smaller lexicographical order: {(pe0, pe1, pe2) → (e0, e4, e5)}.

[0272] S430: Intersection constraint screening.

[0273] e0∩e4∩e5 = {v2}∩e5 = →0 - Consistent with the pattern; enter the next stage.

[0274] S440: Duplicate removal screening.

[0275] Normalized key: key = (pattern_id, e0, e4, e5) (already satisfying symmetry-breaking and uniqueness). ResultIndex does not exist, insert.

[0276] S500: Result merging, end.

[0277] In this embodiment, after the system completes the recalculation of the dependency subgraph in step S400, it is necessary to merge the newly generated candidate results with the historical result index to form the latest global matching result.

[0278] S510: Invalid result cleaning.

[0279] For the candidate results marked as invalid in step S300, update their delete_ver field in ResultIndex at this time, keeping the record but with the status as invalid; Candidate combinations that become invalid due to the deletion or modification of super-edges will no longer participate in subsequent matching; Cleanup can be achieved on the FPGA processing unit 102 via fast index lookup to reduce the load on the central processing unit 101.

[0280] S520: Write new results.

[0281] S440 has generated a normalized mapping key for the new candidate. During merging, if the key already exists and is valid, it is skipped. If the key already exists but its status is invalid, then perform "version rebirth": update create_ver to the current version and set the status to valid; If the key does not exist, create a new record {key, create_ver, delete_ver= , state=valid}.

[0282] S530: Global index maintenance.

[0283] ResultIndex uses a multi-level index based on (pattern_id, key). Historical versions are distinguished by timestamps / version numbers, supporting backtracking. The system guarantees that at any given time, ResultIndex retains only one globally consistent and valid result set, while historical information is also traceable.

[0284] In this embodiment, it is assumed that there are already valid candidates (e0, e1, e3) at time t. At time t+1, the superedge e3 is deleted, and e4 and e5 are added.

[0285] The deletion operation causes (e0, e1, e3) to be marked as invalid in step S300, and delete_ver=t+1 is written during the merge. In step S400, the new operation finds candidate (e0,e4,e5). However, during the merging process, the ResultIndex does not find this key, so a new record is created: {(pattern_id,e0,e4,e5), create_ver=t+1, state=valid}.

[0286] Ultimately, ResultIndex contains one invalid result and one newly added result, ensuring the correctness and temporal consistency of the result set.

[0287] By merging the results of step S500, the system has the following advantages: Removal of expired results—ensuring that the result set after dynamic updates does not contain expired items; Idempotent writing of new results—avoiding duplicate records and improving storage and query efficiency; Global consistency maintenance – supports continuous querying and historical backtracking under incremental updates.

[0288] Example 3 This embodiment provides one physical hardware implementation of the system of the present invention, and repeated content will not be described again.

[0289] The physical hardware of the central processing unit 101 is preferably a CPU, but it can also be a graphics processing unit (GPU), a dedicated acceleration processor (such as some AI or DSP chips), a field-programmable gate array (FPGA), etc.

[0290] Taking the CPU as an example, the physical hardware of the central processing unit 101 is preferably a CPU, and the internal modules are described. The pattern parsing module 1011, the incremental log management module 1012, the complex consistency check module 1013, and the global result index maintenance module 1014 all share the same physical hardware foundation: CPU cores, cache, and system memory (RAM).

[0291] The internal modules are described using the example of a customized digital circuit on an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA) as the physical hardware of the central processing unit 101.

[0292] The pattern parsing module 1011 can be a dedicated parsing circuit consisting of a state machine, a register set, and matching logic, used to parse input patterns according to fixed or configurable rules.

[0293] The incremental log management module 1012 can be a dedicated storage management circuit, with the core being a cache (SRAM) controller, address generator, and version control logic, used to efficiently manage the writing, reading, and merging of incremental data.

[0294] The complex consistency check module 1013 can be a dedicated verification acceleration circuit consisting of a parallel comparator array, a rule engine (lookup table or microcode controller), and a temporary buffer, used to perform predefined complex constraint checks at high speed.

[0295] The global result index maintenance module 1014 can be a dedicated index maintenance circuit, with the core being a content addressable memory (CAM), a hash calculation unit, and a memory access scheduler, used to implement low-latency index insertion, querying, and updating.

[0296] Dedicated parsing circuits, dedicated memory management circuits, dedicated verification acceleration circuits, and dedicated index maintenance circuits are physically connected within the chip via on-chip interconnect networks (such as buses, crossbar switches, or on-chip network NoC) for high-speed data exchange and collaborative operation. They can be integrated onto the same ASIC chip or FPGA chip.

[0297] A dedicated parsing circuit receives raw pattern data from an external input interface. This circuit performs syntax / structure parsing and feature extraction to obtain structured pattern description data. The dedicated parsing circuit is connected to a dedicated memory management circuit via a high-speed data bus and sends the structured pattern description data to the dedicated memory management circuit.

[0298] The dedicated storage management circuit receives structured schema description data from the dedicated parsing circuit. It performs logging, versioning, and storage management to obtain version-tagged incremental data. The dedicated storage management circuit connects to the dedicated verification acceleration circuit via a high-speed data bus and sends the incremental data to be verified to the dedicated verification acceleration circuit.

[0299] A dedicated verification acceleration circuit receives incremental data to be verified from a dedicated memory management circuit. The circuit performs parallel constraint checks and consistency verification to obtain valid result data that passes verification. The dedicated verification acceleration circuit is connected to a dedicated index maintenance circuit via a high-speed data bus and sends the valid result data to the dedicated index maintenance circuit.

[0300] The dedicated index maintenance circuit receives valid result data from the dedicated verification acceleration circuit. It performs index key value calculation and index structure updates to obtain the updated global index state. This dedicated index maintenance circuit is connected to the dedicated storage management circuit via a feedback data bus and sends an index update confirmation signal to the dedicated storage management circuit to complete the transaction loop.

[0301] Preferably, the dedicated verification acceleration circuit sends incremental log entries, scheduling instructions and pattern matching plans to the FPGA processing unit 102 through a one-way communication line represented by the CPU→FPGA connection line 1031.

[0302] Dedicated memory management circuitry via FPGA The bidirectional communication line represented by CPU connection line 1032 sends candidate results or failure flags to the FPGA processing unit 102 and receives processing completion status or write-back data from the FPGA processing unit 102. All transmission transactions on this bidirectional channel are eventually maintained by the central processing unit 101 to ensure that the asynchronous processing results of the FPGA are synchronized with the master data state on the CPU side.

[0303] The physical hardware of the FPGA processing unit 102 is a programmable field-programmable gate array chip.

[0304] The candidate failure handling module 1021, dependency subgraph generation module 1022, candidate generation and pruning module 1023, intersection constraint calculation module 1024, deduplication pre-filtering module 1025, and result writing module 1026 within the FPGA processing unit 102 are all implemented as dedicated hardware circuits within the field-programmable gate array chip, and form a complete data processing pipeline through the chip's internal high-speed interconnect network. The specific physical hardware configuration and the physical connections between the modules are as follows.

[0305] The physical hardware of the candidate failure handling module 1021 is implemented by a state machine consisting of programmable logic circuits and on-chip registers. The physical hardware of the candidate failure handling module 1021 is collectively referred to as the candidate failure handling circuit.

[0306] The candidate failure handling circuit receives candidate version tags and failure signals from the dedicated memory management circuit via a bidirectional communication line between the FPGA processing unit 102 and the central processing unit 101. The candidate failure handling circuit performs version status checks and failure tag distribution on the received signals, generating valid candidate identifiers or global failure commands. Subsequently, the candidate failure handling circuit broadcasts the processing results to the dependent subgraph generation circuit and the candidate generation and pruning circuit via the high-speed routing resources within the FPGA processing unit 102.

[0307] The physical hardware of the dependency subgraph generation module 1022 is implemented by a parallel data path consisting of programmable logic circuits, a dedicated digital signal processing module, and an on-chip high-speed memory. The physical hardware of the dependency subgraph generation module 1022 is collectively referred to as the dependency subgraph generation circuit.

[0308] The dependent subgraph generation circuit receives valid candidate identifiers from the candidate failure handling circuit and performs graph data traversal and adjacency extraction operations based on these identifiers to generate dependent subgraph data for the target vertex. The generated data is sent to the candidate generation and pruning circuit via the high-speed bus inside the FPGA processing unit 102 for subsequent processing.

[0309] The physical hardware of the candidate generation and pruning module 1023 is implemented by a pipelined processing engine consisting of a highly parallel array of logic cells and distributed on-chip memory. The physical hardware of the candidate generation and pruning module 1023 is collectively referred to as the candidate generation and pruning circuit.

[0310] The candidate generation and pruning circuit simultaneously receives data from two upstream modules: valid candidate identifiers or failure instructions from the candidate failure handling circuit, and dependency subgraph data from the dependency subgraph generation circuit. The candidate generation and pruning circuit performs pattern matching, candidate solution space enumeration, and preliminary pruning calculations to obtain a preliminary candidate solution set. This result is sent to the intersection constraint calculation circuit via the high-speed data stream channel within the FPGA processing unit 102.

[0311] The physical hardware of the intersection constraint calculation module 1024 is implemented by a dedicated computing array consisting of a large number of parallel comparators, hash calculation units, and on-chip static random access memory. The physical hardware of the intersection constraint calculation module 1024 is collectively referred to as the intersection constraint calculation circuit.

[0312] The intersection constraint calculation circuit receives a preliminary set of candidate solutions from the candidate generation and pruning circuit, performs parallel intersection calculation and verification under multiple constraints, and outputs accurate candidate solutions that pass the constraint verification. These accurate candidate solutions are sent to the deduplication pre-filtering circuit through the high-speed data stream channel inside the FPGA processing unit 102.

[0313] The physical hardware of the deduplication pre-filtering module 1025 is implemented by filtering hardware consisting of content-addressable memory, Bloom filter hardware logic, and a high-speed register file. The physical hardware of the deduplication pre-filtering module 1025 is collectively referred to as the deduplication pre-filtering circuit.

[0314] The deduplication pre-filtering circuit receives accurate candidate solutions from the intersection constraint calculation circuit and performs fast deduplication and historical result filtering operations based on hardware hashing to generate the final candidate results after deduplication. The final candidate results are sent to the result writing module 1026 through the high-speed data stream channel inside the FPGA processing unit 102.

[0315] The physical hardware of the result writing module 1026 is implemented by the output interface hardware consisting of a direct memory access controller, a high-speed interface core, and an output buffer first-in-first-out memory. The physical hardware of the result writing module 1026 is collectively referred to as the result writing circuit.

[0316] The result writing circuit receives the final candidate results from the deduplication pre-filtering circuit, encapsulates and schedules their transmission, and formats them into output data packets. Finally, the result writing circuit sends the formatted output data packets back to the dedicated storage management circuit through a bidirectional communication line at the physical board level, thus completing the data processing closed loop of the entire FPGA processing unit 102.

[0317] The physical hardware of the storage module 200 is preferably DRAM, but it can also be on-chip cache or high-bandwidth memory (HBM). Preferably, the CPU and DRAM communicate via the CPU. The bidirectional communication line connection represented by the connection line 1033 of the storage module 200 is used for hypergraph structure modification and log update.

[0318] The CPU and DRAM are also connected via a one-way communication line, represented by CPU→Storage Module 200 connection line 1035, which is used by the central processing unit 101 to send configuration, management or consistency maintenance instructions to the storage module 200.

[0319] The Field Programmable Gate Array (FPGA) chip and DRAM are connected via an FPGA. The connection line 1034 of the storage module 200 represents a bidirectional communication line connection, which is used by the field-programmable gate array chip to batch load vertex sets, adjacency relationships and intersection tables during the candidate generation and intersection calculation stages.

[0320] Example 4 This invention relates to graph data processing technology based on programmable logic devices, and more particularly to a hardware-accelerated architecture for incremental pattern matching for dynamic hypergraphs, which enables rapid generation, pruning, intersection constraint verification, and deduplication of results for candidate mapping sets in scenarios with frequent hyperedge updates.

[0321] In dynamic hypergraph scenarios, a single hyperedge can connect multiple vertices, and the set of hyperedges is constantly being added to or modified over time. For pattern matching tasks, updates cause changes in the set of candidate mappings within the affected region, leading to significant redundant computations in traditional full-graph recalculation methods. Furthermore, hypergraph pattern matching inherently involves higher-order constraints such as set intersection / containment, which can easily create computational bottlenecks if a general graph computation model or software set traversal is used. In addition, incremental output often results in a large number of structurally equivalent but differently enumerated results, leading to increased bus bandwidth and global index access pressure, and decreased throughput.

[0322] Therefore, a hardware-accelerated architecture is needed when hyperedge updates occur: (1) It can automatically define the scope of incremental impact with the update as the center, avoiding full-map recalculation; (2) It can verify the intersection constraint with hardware circuits oriented towards set operations and stop early when it is impossible to satisfy the constraint; (3) It can perform lightweight pre-deduplication on the hardware side, only sending the results that are "possibly new" to the CPU for accurate deduplication / writing, and performing rollback processing when the complexity is too high, so as to ensure correctness and steady-state throughput.

[0323] To address the aforementioned issues, this invention provides an incremental pattern matching hardware accelerator for dynamic hypergraphs, which adopts a "CPU+FPGA" collaborative architecture: the CPU is responsible for pattern matching plan generation, global accurate deduplication / writing, and complexity rollback, while the FPGA is responsible for updating the influence domain definition, candidate generation and pruning, intersection constraint hardware verification, and deduplication pre-filtering.

[0324] In a preferred embodiment, the hardware accelerator includes at least a central processing unit (CPU) 101 and an FPGA processing unit 102 communicatively connected to the CPU 101. The FPGA processing unit 102 internally includes, in the data flow direction, a dependency subgraph generation module 1022, a candidate generation and pruning module 1023, an intersection constraint calculation module 1024, and a deduplication pre-filtering module 1025. These modules can be configured in hardware as a pipeline structure to achieve continuous processing of "updating input—generating candidates—verifying intersection constraints—outputting deduplication".

[0325] The dependency subgraph generation module 1022 is used to construct a local dependency subgraph by using the updated hyperedge as the anchor point and expanding the neighborhood within a limited neighborhood radius when the dynamic hypergraph is updated or modified. This restricts the incremental calculation to the scope of the update and avoids recalculating the entire graph. The candidate generation and pruning module 1023 is used to generate a set of candidate maps and perform pre-pruning within the scope of the local dependency subgraph according to the pattern matching plan. The intersection constraint calculation module 1024 is used to perform hypergraph adjacency relationship and intersection constraint verification on the candidate mapping set. The intersection constraint calculation module 1024 includes a bitmap register, a logic AND operator, a popcount counter, and an early truncation logic unit. It performs intersection calculation and early stopping in a hardware pipeline manner to reduce the computational overhead of the failed candidate results. The deduplication pre-filtering module 1025 includes a normalized key generator and a Bloom filter; the normalized key generator is used to convert the candidate mapping set into order-independent normalized keys, and the Bloom filter is used to perform probabilistic pre-screening of the normalized keys, so that only candidate results that are likely to be new are output to the central processing unit 101 for accurate deduplication, thereby reducing the global index access pressure; and The central processing unit 101 is configured to perform precise deduplication / writing on the candidate results that may be new output by the deduplication pre-filtering module 1025, and to perform rollback processing when the computational complexity of candidate expansion or intersection constraint verification exceeds a preset threshold.

[0326] Preferably, the neighborhood radius is defined by a preset parameter K, and the dependent subgraph generation module 1022 is configured to: retrieve and update the set of hyperedges adjacent to the vertices associated with the hyperedges during the first-order expansion, and continue to perform adjacency expansion on the newly added vertices or hyperedges during the second to Kth-order expansions to form a local dependent subgraph.

[0327] Preferably, the pre-pruning of the candidate generation and pruning module 1023 includes at least: degree / cardinality constraint pruning, local consistency pruning, and resource threshold-aware pruning, wherein resource threshold-aware pruning is used to process candidate expansion in batches or mark them as high-complexity candidates when the candidate size exceeds a preset window.

[0328] Preferably, the early truncation logic of the intersection constraint calculation module 1024 is configured to: maintain the theoretical upper limit of the intersection size during the bitmap segmentation process, and terminate the subsequent logical AND operation and popcount counting in advance when the sum of the counted number of intersections and the maximum possible number of intersections of the remaining segments is still less than the constraint threshold.

[0329] Preferably, the normalized key generator is configured to perform normalization sorting or permutation normalization on the key elements in the candidate mapping set to generate normalized keys that are independent of the enumeration order; the Bloom filter is configured to perform multi-hash mapping on the normalized key and query the bit array, output the candidate result to the central processing unit (CPU) 101 when it is determined that "may not appear", and discard the candidate result on the FPGA side when it is determined that "has appeared".

[0330] Preferably, the preset threshold includes at least one of the candidate size threshold, intersection order threshold, or hyperedge degree threshold; the rollback process of the central processing unit (CPU) 101 includes: performing precise intersection constraint verification of the software path and / or adjusting the pattern matching plan to change the candidate expansion order on the candidate results that trigger the threshold.

[0331] The present invention describes the specific technical details of the above technical solutions.

[0332] The dependency subgraph generation module 1022 is used to update the anchored local dependency subgraph.

[0333] When a new or modified hypergraph is added to the dynamic hypergraph, the dependency subgraph generation module 1022 receives the updated hyperedge as input. Using the updated hyperedge as an anchor point, the dependency subgraph generation module 1022 constructs a local dependency subgraph within a defined neighborhood radius through first-order / multi-order neighborhood expansion. Preferably, the defined neighborhood radius can be given by a system-preset parameter K, representing the number of neighborhood layers expanded from the updated hyperedge in the hypergraph topology.

[0334] In an example flow: (a) mark the updated hyperedge as an anchor point and extract its associated vertex set; (b) during the first-order expansion, retrieve the set of hyperedges adjacent to this vertex set; (c) during the i-th-order expansion (i=2…K), continue adjacency expansion for the vertices / hyperedges added in the previous order; (d) aggregate the vertices and hyperedges involved in the K-order expansion into a locally dependent subgraph. In this way, incremental computation is limited to the scope of the update's influence, avoiding recalculation of the entire graph.

[0335] It should be noted that the local dependency subgraph is not just for data pruning, but serves as the computational boundary for subsequent candidate generation, pruning, and intersection constraint verification, so that the pipeline of the FPGA processing unit 102 only processes the data structures and constraints within this boundary.

[0336] Preferably, the dependency subgraph generation module 1022 is configured to differentiate the extended anchor points based on the dynamically updated operation type: For add (ADD) or modify (MODIFY) operations: When a new hyperedge is added or the vertex set of an existing hyperedge changes, the new or modified hyperedge itself becomes the anchor point. The dependent subgraph generation module 1022 starts from this hyperedge and expands outwards to its associated vertices and other adjacent hyperedges to construct the incremental computation region.

[0337] For the DELETE operation: When an old hyperedge is removed, it no longer exists in the graph topology and cannot be directly used as the starting point for topology expansion. In this case, the set of vertices contained in the original hyperedge is used as the anchor set. The subgraph generation module 1022 retrieves all remaining hyperedges containing any of the aforementioned vertices and expands outward based on these remaining hyperedges.

[0338] This approach ensures that when a deletion operation occurs, the system can accurately identify other candidate mapping relationships that are affected by the deletion (e.g., the intersection constraint is no longer satisfied), thereby promptly cleaning up invalid results in the global index and ensuring the integrity of incremental maintenance.

[0339] The candidate generation and pruning module 1023 is used for pattern matching plan-driven operation.

[0340] The candidate generation and pruning module 1023 generates a set of candidate maps within the local dependency subgraph according to the pattern matching plan and performs pre-pruning. The pattern matching plan can be pre-generated by the central processing unit (CPU) 101 based on the pattern hypergraph structure and issued to the FPGA processing unit 102 via instruction / configuration. Candidate generation expands the maps step by step according to the matching order given in the plan to generate the candidate set.

[0341] In a preferred embodiment, pre-pruning includes at least: (a) degree / cardinality constraint pruning: when the adjacency degree or set size of a candidate vertex / hyperedge does not meet the planning constraints, it is directly eliminated; (b) local consistency pruning: in advance during the expansion phase, the adjacency consistency of the mapped part is checked to reduce the number of candidates entering the intersection constraint verification phase; (c) resource threshold awareness: when the candidate expansion causes the number of candidates to exceed the preset window, batch processing can be triggered or the branch can be marked as a high-complexity candidate.

[0342] The technical effect of the candidate generation and pruning module 1023 is that it prunes a large number of candidates that are bound to fail before the intersection constraint verification, thereby reducing the load on the intersection calculation module and improving the overall pipeline's effective throughput.

[0343] The intersection constraint calculation module 1024 performs bitmap AND operations, popcount counting, and early truncation.

[0344] The intersection constraint calculation module 1024 is used to perform hypergraph adjacency and intersection constraint verification on the candidate mapping set. Unlike ordinary graphs, hyperedges connect multiple vertices, and the key constraints in pattern matching are often manifested as set operation constraints such as "set intersection / containment / overlap". Therefore, this embodiment encodes the vertex set involved in the candidate as a bitmap and uses a hardware pipeline to complete the intersection constraint verification.

[0345] In a preferred embodiment, the intersection constraint calculation module 1024 includes: a bitmap register, a logic AND operator, a popcount counter, and an early truncation logic unit. The bitmap register is used to cache set encoding; the logic AND operator is used to perform bitwise AND operations on multiple bitmaps to achieve intersection calculation; the popcount counter is used to count the number of "1"s in the intersection result, which is used to express the intersection size or to meet the threshold judgment; the early truncation logic unit is used to stop subsequent bit operations and counting in advance when it is detected that the current part of the result can no longer meet the constraint threshold during pipeline processing.

[0346] For example, when the constraint requires the intersection size to be at least T, the early truncation logic can maintain a "theoretical upper limit" when processing bitmap segments. If (the number of counted 1s + the maximum possible number of 1s in the remaining unprocessed segments) is still less than T, then the candidate is determined to fail and terminated early. By stopping early, the computational cost of failed candidate results is significantly reduced.

[0347] Preferably, in the intersection constraint calculation module 1024, the bitmap register may have a fixed hardware physical bit width W (e.g., W = 1024 bits or 2048 bits). This bit width determines the maximum size of the vertex set that the hardware circuit can process in parallel in a single operation.

[0348] To address the possibility of super-large degree hyperedges in dynamic hypergraphs, this embodiment employs a hardware bit-width check and a direct backoff strategy. In the hardware bit-width check, before loading the vertex set of a candidate hyperedge into the bitmap register, the degree D of the hyperedge is checked first. In the direct backoff strategy, if D > W, it indicates that the vertex set of the hyperedge cannot be completely covered by a single hardware register. In this case, the intersection constraint calculation module 1024 does not perform bitmap encoding but directly triggers the aforementioned "backoff request," transferring the candidate verification task containing the super-large degree hyperedge to the central processing unit 101.

[0349] This design represents a significant advancement: it avoids the need for extremely expensive and inefficiently long bit-width registers for a very small number of ultra-high degree vertices, achieving an optimal balance between hardware resource utilization and system processing power. The central processing unit 101 has a larger memory space, making it suitable for handling intersection operations on such long lists.

[0350] Regarding the deduplication pre-filtering module 1025 (normalization key + Bloom filter + CPU precise deduplication).

[0351] The deduplication pre-filtering module 1025 includes a normalized key generator and a Bloom filter. The normalized key generator is used to convert candidate mappings into order-independent normalized keys to uniformly represent different enumeration orders of the same structural result. The Bloom filter is used to perform probabilistic pre-screening of the normalized keys, ensuring that only candidate results that are "likely new" are output to the CPU for precise deduplication / writing, thereby reducing the global index access pressure.

[0352] In a preferred embodiment: (a) The normalized key generator sorts or permutes the key elements in the candidate mapping set to generate fixed-length key values; (b) The Bloom filter performs a multi-hash mapping on the key value and queries the bit array; if it determines that "it has already appeared", the result is discarded directly on the FPGA side; (c) If it is determined that "may not appear", then output to the CPU; the CPU further queries the global index (e.g., hash table / persistent index) to complete accurate deduplication and write the result.

[0353] The probabilistic nature of Bloom filters means they may produce false positives, but not false negatives. Therefore, this implementation significantly reduces invalid accesses and writes on the CPU side while ensuring correctness through a collaborative link of "FPGA pre-filtering + CPU precise deduplication".

[0354] Central Processing Unit (CPU) 101 rollback processing (complexity threshold triggered): When the computational complexity of candidate expansion or intersection constraint verification exceeds a preset threshold, the central processing unit (CPU) 101 performs a rollback. The complexity threshold can be triggered by one or a combination of the following factors: the number of candidates exceeds the threshold, the intersection order exceeds the threshold, the hyperedge degree exceeds the threshold, or pipeline congestion exceeds the threshold.

[0355] The rollback process can employ a software path on the central processing unit (CPU) 101 side to precisely process this subset of candidates, or adjust the pattern matching plan to change the expansion order and improve pruning efficiency. Through this mechanism, the system can maintain stable operation under extremely complex update conditions and ensure the correctness of the results.

[0356] In a preferred embodiment of the present invention, the FPGA processing unit 102 further includes a complexity monitoring and status reporting circuit. This complexity monitoring and status reporting circuit monitors the operating status of the candidate generation and pruning module 1023 and the intersection constraint calculation module 1024 in real time.

[0357] Specifically, the FPGA processing unit 102 sends a fallback request to the central processing unit (CPU) 101 via an interrupt signal or a status register when any of the following occurs: (1) Candidate buffer overflow, where the number of intermediate candidates generated by the candidate generation module exceeds the physical depth limit of the on-chip FIFO or cache; or (2) The intersection order is too high, where the number of bitmaps involved in the intersection operation indicated by the pattern matching plan exceeds the number of parallel input ports of the logic AND operator (e.g., more than 4 or 8 concurrent); the superedge degree is too large, where the degree of the candidate superedge exceeds the maximum bit width of the bitmap register (see description below).

[0358] In response to a rollback request, the central processing unit 101 takes over the computational task for that part. Specifically, the FPGA processing unit 102 marks the current "seed candidate" or "original update entry" that caused the rollback as "Pending" and writes it back to shared memory. The central processing unit 101 reads the entry and initiates a software-based precise verification process. This mechanism ensures that the pipeline of the FPGA processing unit 102 will not be stalled due to a single extreme task, thereby maintaining the overall throughput stability of the system.

[0359] The technical effects of this invention are as follows: (1) To address the problem of full graph recalculation triggered by update: a local dependent subgraph is constructed with the update superedge as the anchor point, so that the incremental calculation is limited to the scope of the update influence, thereby reducing redundant calculation and access to irrelevant data and improving the efficiency of incremental processing.

[0360] (2) To address the high cost of verifying intersection constraints of hypergraph sets: a bitmap AND + popcount + pre-truncation intersection constraint hardware pipeline is adopted to transform set traversal into bit-level parallelism and reduce invalid computation, thereby reducing the overhead of intersection constraint verification.

[0361] (3) To address the bandwidth and index pressure issues caused by redundant results: pre-deduplication is performed using normalized keys and Bloom filters, and the central processing unit (CPU) 101 performs precise deduplication / writing, thereby reducing redundant output and global index access and improving throughput.

[0362] (4) To address the stability issues in extreme complexity scenarios: set a complexity threshold and trigger CPU rollback to maintain steady-state operation of the system while ensuring correctness.

[0363] It should be noted that the specific embodiments described above are exemplary. Those skilled in the art can devise various solutions inspired by the disclosure of this invention, and these solutions all fall within the scope of this invention and its protection. Those skilled in the art should understand that this specification and its accompanying drawings are illustrative and not intended to limit the scope of the claims. The scope of protection of this invention is defined by the claims and their equivalents. This specification contains multiple inventive concepts; terms such as "preferredly," "according to a preferred embodiment," or "optionally" indicate that the corresponding paragraph discloses an independent concept. The applicant reserves the right to file divisional applications based on each inventive concept.

Claims

1. A dynamic supergraph hardware accelerator based on FPGA, characterized in that, The hardware accelerator includes: The central processing unit (101) reads and parses the input pattern hypergraph to obtain a matching plan and sends it to the FPGA processing unit (102); it verifies the constraints involving high-order intersections and the unique mapping conditions of vertices to undertake the candidate expansion and backoff processing of ultra-large degree hyperedges and ensure correctness. The FPGA processing unit (102) locates and marks candidate results that fail due to update operations; expands the neighborhood domain in the data hypergraph with the update edge as the anchor point to construct a local dependency subgraph; within the local dependency subgraph, performs pre-pruning based on the matching plan and performs multi-constraint filtering to reduce redundant candidates; performs bitmap intersection operation on the pruned candidate results to perform constraint verification, and discards candidate results that fail the constraint verification to achieve early truncation; generates normalized keys based on the candidate results that pass the constraint verification to perform fast pre-lookup, thereby achieving deduplication pre-filtering; and sends the candidate results that pass the deduplication pre-filtering to the central processing unit (101).

2. The dynamic supergraph hardware accelerator according to claim 1, characterized in that, The central processing unit (101) includes: The pattern parsing module (1011) parses the pattern hypergraph, generates matching order, degree constraint, intersection constraint and symmetry breaking constraint, thereby forming a matching plan and sending it to the FPGA processing unit (102); the matching plan serves as the guiding basis for the generation and screening of candidate results; The incremental log management module (1012) receives dynamic update requests, maintains the hypergraph storage structure based on the strategy of deleting first and then adding, generates incremental log entries, and sends read-only update views to the FPGA processing unit (102). The complex consistency check module (1013) verifies the constraints involving high-order intersections and the unique mapping conditions of vertices; it is responsible for the candidate expansion and backoff processing of super-large degree superedges to ensure correctness. The global result index maintenance module (1014) stores candidate results in the global index table to ensure the consistency of the result set in dynamic scenarios.

3. The dynamic supergraph hardware accelerator according to claim 1 or 2, characterized in that, The FPGA processing unit (102) includes: The candidate failure handling module (1021) locates and marks candidate results that have undergone dynamic changes based on the incremental log, and adds failure markers to the global index table. The dependency subgraph generation module (1022) uses the updated edge as the anchor point to expand the adjacency structure of the updated edge in a local range, constructs a local dependency subgraph, and narrows the candidate generation range; The candidate generation and pruning module (1023) performs candidate expansion based on the matching plan within the scope of the local dependency subgraph and performs multi-constraint filtering to reduce redundant candidates at the source; The intersection constraint calculation module (1024) calculates pairwise intersections and multi-way intersections for the pruned candidate results to perform constraint verification, and discards candidate results that fail the constraint verification in order to achieve early truncation; The deduplication pre-filtering module (1025) generates normalization keys for candidate results and performs a fast pre-lookup on the normalization keys. The new candidate results obtained after deduplication pre-filtering are sent to the central processing unit (101) for precise lookup. The result writing module (1026) writes the candidate results that have been pre-filtered for deduplication into the global result index table.

4. The dynamic hypergraph hardware accelerator according to any one of claims 1 to 3, characterized in that, The candidate failure handling module (1021) in the FPGA processing unit (102) includes: The input FIFO and operation splitter receive incremental logs and distinguish operation types. The index lookup tool locates candidate results containing updated edges and stores the mapping between superedge numbers and the list of candidate result IDs. The comparator array and failure marker compare the superedge numbers in the incremental log with the candidate index buffer in parallel, and mark the hit candidate results with failure markers. The first writer updates the failure candidate status to the global result index table; The FSM controller coordinates the operation sequence of each sub-unit and returns an ACK signal to the central processing unit (101).

5. The dynamic supergraph hardware accelerator according to any one of claims 1 to 4, characterized in that, The dependency subgraph generation module (1022) includes: Input FIFO and task parser to parse the newly added or modified update edge information; The neighborhood searcher retrieves all adjacent superedges that share vertices with the updated edge; based on the vertex set of the updated edge, it quickly queries the set of all superedges containing the same vertex using an inverted index structure. The K-order neighborhood expander expands the neighborhood of the updated edge by one or more orders according to the maximum dependency order K of the pattern. The dependency subgraph assembler combines the updated edges and the adjacent edge set obtained by their expansion into a local dependency subgraph. The second writer stores the local dependency subgraph into the storage module (200) for subsequent pipeline processing.

6. The dynamic hypergraph hardware accelerator according to any one of claims 1 to 5, characterized in that, The candidate generation and pruning module (1023) includes: Input the parser to resolve the vertices and adjacency relationships of the locally dependent subgraph; The degree / label checker performs preliminary screening of candidate results, eliminating candidates that do not meet the constraints; The distinctness checker checks whether there are duplicate vertices in the mapping table; if the same vertex is found to be assigned to two pattern vertices, the candidate result is immediately discarded. Symmetry breaker, eliminating equivalent candidate permutations caused by the symmetry of the mode hypergraph; The candidate expander generates valid candidate results and outputs them to the intersection constraint calculation module (1024).

7. The dynamic hypergraph hardware accelerator according to any one of claims 1 to 6, characterized in that, The intersection constraint calculation module (1024) in the FPGA processing unit (102) includes: The bitmap register encodes the vertex set of candidate hyperedges into bitmap form; The logical AND operator performs a bitwise logical AND operation on a bitmap with two or more candidate superedges to obtain the intersection result of the bitmaps. The popcount counter counts the number of vertices in the intersection result and compares the number of vertices with the intersection cardinality in the pattern constraint; if the results are consistent, the constraint verification is successful. The logic unit is truncated early. When it is determined that the current candidate cannot satisfy the constraint conditions, the calculation is terminated immediately and the candidate result is discarded.

8. The dynamic hypergraph hardware accelerator according to any one of claims 1 to 7, characterized in that, The deduplication pre-filtering module (1025) in the FPGA processing unit (102) includes: A normalized key generator is used to map candidate results to unique key values; Bloom filters are used to quickly determine whether a candidate already exists. The pre-filtered output is used to send potential new candidate results to the central processing unit (101) for precise querying.

9. A hardware acceleration method for dynamic supergraphs based on FPGA, characterized in that, The method includes: The central processing unit (101) reads and parses the input pattern hypergraph, obtains the matching plan, and sends it to the FPGA processing unit (102); it verifies the constraints involving high-order intersections and the unique mapping conditions of vertices, so as to undertake the candidate expansion and back-off processing of ultra-large degree hyperedges and ensure correctness. The FPGA processing unit (102) locates and marks candidate results that fail due to update operations; expands the neighborhood domain in the data hypergraph with the update edge as the anchor point to construct a local dependency subgraph; within the local dependency subgraph, performs pre-pruning based on the matching plan and performs multi-constraint filtering to reduce redundant candidates; performs bitmap intersection operation on the pruned candidate results to perform constraint verification, and discards candidate results that fail the constraint verification to achieve early truncation; generates normalized keys based on the candidate results that pass the constraint verification to perform fast pre-lookup, thereby achieving deduplication pre-filtering; and sends the candidate results that pass the deduplication pre-filtering to the central processing unit (101).

10. A hardware accelerator for incremental pattern matching of dynamic hypergraphs, characterized in that, It includes a central processing unit (101) and an FPGA processing unit (102) communicatively connected to the central processing unit (101), wherein the FPGA processing unit (102) includes: The dependency subgraph generation module (1022) is used to construct a local dependency subgraph within a limited neighborhood radius by using the updated hyperedge as the anchor point when the dynamic hypergraph is added or modified. This restricts the incremental calculation to the scope of the update and avoids recalculating the entire graph. The candidate generation and pruning module (1023) is used to generate a set of candidate maps according to the pattern matching plan and perform pre-pruning within the local dependency subgraph. The intersection constraint calculation module (1024) is used to perform hypergraph adjacency and intersection constraint verification on the candidate mapping set. The intersection constraint calculation module (1024) includes a bitmap register, a logic AND operator, a popcount counter, and an early truncation logic unit. The intersection calculation and early stopping are performed in a hardware pipeline manner to reduce the computational overhead of the failed candidate results. The deduplication pre-filtering module (1025) includes a normalized key generator and a Bloom filter; the normalized key generator is used to convert candidate mapping relationships into order-independent normalized keys, and the Bloom filter is used to perform probabilistic pre-screening of the normalized keys, so that only potentially new candidate results are output to the central processing unit (101) for accurate deduplication, thereby reducing the global index access pressure; and The central processing unit (101) is configured to perform precise deduplication / writing on the candidate results that may be new output by the deduplication pre-filtering module (1025), and to perform rollback processing when the computational complexity of candidate expansion or intersection constraint verification exceeds a preset threshold.

Images