Dynamic graph neural network reasoning system and method based on FPGA

Abstract

The invention relates to a dynamic graph neural network inference system and method based on an FPGA. In the system, a multi-snapshot data loader is used for classifying vertexes in a plurality of continuous snapshots of a dynamic graph; taking the stable vertexes as root nodes, concurrently prefetching affected vertexes based on the topological structures of the snapshots, and constructing affected sub-graphs; and capturing a complete influenced sub-graph based on a traversal finite-state machine. And the on-chip cache stores the data of the affected sub-graph in an overlapping perception compression sparse row storage format. And the task scheduler reads the calculation tasks stored in the task first-in first-out cache in real time, and uniformly distributes the tasks to the idle DGNN calculation units according to the number of neighborhoods of each vertex. And the DGNN calculation unit completes aggregation and combination calculation of DGNN reasoning on the vertexes in the affected subgraph based on a multi-snapshot concurrent execution mode. The adaptive RNN unit judges the consistency of vertex features and topology between continuous snapshots based on an aggregation result; and dynamically deciding whether to skip unnecessary RNN cell updating or not based on the judgment result.

Description

Technical Field

[0001] This invention relates to the field of graph computing technology for big data processing, and in particular to a dynamic graph neural network inference system and method based on FPGA. Background Technology

[0002] Dynamic Graph Neural Networks (DGNNs), as a key technology integrating the structural information extraction capabilities of Graph Neural Networks (GNNs) and the temporal semantic capture capabilities of Recurrent Neural Networks (RNNs), have become a core tool for analyzing dynamic graph data such as social network interactions, financial transaction links, and traffic flow changes. They are widely used in scenarios such as dynamic node classification, dynamic link prediction, and dynamic graph anomaly detection. However, with the explosive growth in the scale of dynamic graph data (such as temporal snapshot data with millions of vertices and hundreds of millions of edges), existing DGNN inference solutions face multiple challenges in terms of performance, energy efficiency, and hardware compatibility, making it difficult to meet real-time analysis requirements.

[0003] Current CPU / GPU-based solutions (such as DGL-CPU and PiPAD) mostly adopt a "snapshot-by-snapshot execution" mode, which has problems with low data parallelism and poor memory access efficiency: the utilization rate of CPU computing units is less than 30%, and the utilization rate of GPU streaming multiprocessors (SM) is less than 22.3% due to the time data dependence between snapshots (such as RNNs needing the hidden state of the previous snapshot); in addition, vertex features (512-1024 dimensions) are difficult to store on-chip cache, requiring frequent off-chip access. Coupled with the redundant loading of a large number of unaffected vertices between snapshots, memory access time accounts for more than 70% of the total inference time.

[0004] While the industry has proposed hardware acceleration solutions such as DGNN-Booster and E-DGCN, they still have limitations: they do not utilize the topological and feature overlap characteristics between multiple snapshots (the proportion of unaffected vertices in 3-4 snapshots is 47.6%-72.5%), making it impossible to achieve parallel processing of multiple snapshots; they use the static graph CSR storage format, and dynamic addition or deletion of edges / vertices requires frequent reconstruction of the structure, and they do not differentiate between stable and unaffected vertices, resulting in significant redundant access; they do not combine the stability of DGNN inference (the cosine similarity of GNN output features in consecutive snapshots reaches 73.3%), and still perform complete RNN cell updates, resulting in 30%-50% of invalid computations, and they do not alleviate the intra-snapshot dependency between GNN and RNN or the inter-snapshot dependency between RNN.

[0005] While FPGAs offer advantages in high parallelism and low latency, existing FPGA-based acceleration solutions are mostly designed for static GNNs, lacking a multi-snapshot hierarchical processing architecture and failing to efficiently identify affected subgraphs. Furthermore, there is a lack of dedicated units adapted to "GNN+RNN" hybrid operations, making it difficult for general-purpose MAC arrays to balance parallelism and serialism. On-chip caches and pipelines do not consider the timing relationships of dynamic graphs, resulting in a cache miss rate exceeding 40%, and the lack of decoupling between data loading and computation leads to frequent pipeline stalls.

[0006] CN110764799A discloses a method for optimizing remote updates of an FPGA accelerator card, comprising the following steps: in response to receiving information from the FPGA accelerator card that the update is complete, stopping all system activities and creating a memory snapshot image to write to disk; powering off and notifying the server; in response to receiving a power-on wake-up command from the server, retrieving the memory snapshot image from the disk and loading the memory snapshot image into memory; and rescanning the PCIe configuration space based on the memory snapshot image to obtain the updated functions of the FPGA accelerator card. The snapshot in this technical solution is oriented towards the computer system memory, used to ensure system stability and continuity.

[0007] CN116822592A discloses a target tracking method based on event data and a spiking neural network, comprising the following steps: acquiring event data and performing time-dimensional compression processing on the event data to obtain sample data; restructuring the SiamFC network into a spiking neural network, pre-training the SiamFC network using the sample data, and then transferring the obtained weights and biases to the spiking neural network to optimize it; acquiring real-time event data and adjusting the time step to obtain search data; and using the optimized spiking neural network to perform inference and comprehensive similarity estimation on the search data and template data to obtain real-time target tracking results. This target tracking method optimizes the spiking neural network with the trained SiamFC network and accelerates the spiking neural network based on FPGA, improving the real-time performance and accuracy of target tracking with low power consumption. In this technical solution, the similarity calculation of the spiking neural network (SNN) is used for target tracking. Its purpose is to use the spiking neural network to infer from the search data and template data, and finally obtain a comprehensive similarity score to locate the target. The similarity calculation in this technical solution is for localization and recognition. This technical solution is a feature matching method that aims to locate the position of a target object in space by calculating the similarity between the search region and the template. The core of this solution lies in the spatiotemporal encoding of spiking neurons, which utilizes the characteristic of neurons firing pulses to encode and match information.

[0008] If the similarity calculation scheme of spiking neural network (SNN) target tracking in CN116822592A is forcibly applied to DGNN inference, it will face the following serious technical defects: First, there is a mismatch in data representation. SNNs rely on impulse data as input. Impulse data typically comes from an event camera, which only records events when pixel brightness changes; it is a sparse and asynchronous signal. DGNNs, on the other hand, process graph data, which typically consists of vertices (V), edges (E), and their corresponding dense feature vectors (such as features, positions, timestamps, etc.).

[0009] Spurious data and graph data are completely different data types. SNNs cannot directly process dense graph data in DGNNs, nor can they extract valid "events" for spurious neural network computation. To adapt them, a complex and inefficient conversion mechanism is required, which would negate all possible performance advantages.

[0010] Second, it lacks topological awareness. The core advantage of this invention lies in its topological awareness capability. It makes judgments by simultaneously considering feature similarity and topological similarity (i.e., neighbor overlap rate), ensuring that vertices whose features remain unchanged but whose neighbor relationships have changed can be correctly processed. The similarity calculation formula of SNN is based solely on the membrane potential and temporal correlation of the pulse feature map, completely disregarding the graph's topological structure (such as neighbor and edge connectivity). In DGNN inference, if a vertex's features remain unchanged but its neighbors undergo significant changes, traditional SNN schemes will determine it to have "high similarity" and incorrectly skip the calculation, leading to inaccurate or even erroneous inference results.

[0011] Third, it cannot adaptively select the RNN cell update mode. The result of SNN is a comprehensive similarity score, which is mainly used for matching and localization, rather than guiding subsequent incremental calculations. Its output is a scalar and cannot provide the feature differences or hidden state information required for DGNN incremental updates, thus failing to achieve such refined computational optimization.

[0012] Therefore, the present invention aims to provide a dynamic graph neural network inference system and method based on FPGA, overcoming the hardware acceleration deficiencies in the prior art. Summary of the Invention

[0013] To address the shortcomings of existing technologies, this invention provides, from a first aspect, an FPGA-based dynamic graph neural network inference system, comprising a multi-snapshot data loader, an on-chip cache, a task scheduler, a DGNN computation module, and an adaptive RNN unit.

[0014] A multi-snapshot data loader classifies vertices in multiple consecutive snapshots of a dynamic graph, dividing them into unaffected, stable, and affected vertices. Using stable vertices as root nodes, it concurrently prefetches affected vertices based on the topology of each snapshot, constructing an affected subgraph. A traversal finite state machine is used to capture the complete affected subgraph. An on-chip cache employs an overlap-aware compressed sparse row storage format to organize and contiguously store the data of the affected subgraph. The task scheduler reads computation tasks stored in the task FIFO cache in real time and evenly distributes tasks to idle DGNN computation units based on the number of neighbors for each vertex in the batch, thus supporting parallel scheduling of multi-snapshot tasks. The DGNN computation module includes several DGNN computation units. These units perform aggregation and combination computations of DGNN inference on the vertices in the affected subgraph using a multi-snapshot concurrent execution mode, and send the aggregation results to the adaptive RNN unit. The adaptive RNN unit judges the consistency of vertex features and topology between consecutive snapshots based on the aggregation results; based on the judgment results, it dynamically decides whether to skip unnecessary RNN cell updates.

[0015] This technical solution significantly improves the efficiency of dynamic graph neural network inference through multi-snapshot data classification, affected subgraph construction, O-CSR format caching optimization, task scheduling, and an adaptive RNN update mechanism. Its positive impacts are mainly reflected in: accurate identification of unaffected vertices, reducing redundant computation and memory access, and lowering overall computational overhead; the adoption of an overlap-aware compressed sparse row storage format, improving data storage and access efficiency and reducing cache misses; the task scheduler evenly distributes tasks based on the number of neighborhoods, enhancing multi-snapshot parallel processing capabilities; and the adaptive RNN unit dynamically decides whether to skip or simplify updates by judging feature and topology consistency, reducing the proportion of invalid computations. These designs effectively improve system performance and energy efficiency while ensuring inference accuracy, making it particularly suitable for dynamic graph scenarios with low change frequency, such as social networks and academic citation networks, thereby achieving high-throughput, low-energy-consumption dynamic graph processing.

[0016] According to a preferred embodiment, the multi-snapshot data loader includes a pre-configuration module, a vertex extraction module, a snapshot extraction module, an offset extraction module, a neighbor extraction module, a feature extraction module, a vertex recognition and classification module, and a traversal finite state machine.

[0017] The pre-configuration module represents the dynamic graph to be processed as a snapshot sequence. The structure of each snapshot image is stored using a compressed sparse row format; consecutive snapshots are selected from the snapshot sequence based on the sliding window size. KEach snapshot forms a concurrent processing batch. The vertex extraction module identifies vertices to be classified from the snapshots in the concurrent processing batch and marks visited vertices with tags to avoid duplicate processing. The snapshot extraction module checks the existence of vertices in multiple snapshots and initially identifies affected vertices due to topological omissions. The offset extraction module obtains the position offset of the vertex in the adjacency list of each snapshot, preparing for subsequent reading of adjacent vertices. The neighbor extraction module obtains the set of adjacent vertices of the vertex in each snapshot and determines whether the topology has changed. The feature extraction module reads the feature vectors of the vertex itself and its adjacent vertices and determines whether the features have changed. The vertex identification and classification module compares vertex ID consistency, feature changes, and local topological modifications, classifying vertices into unaffected vertices, stable vertices, and affected vertices; and stores the vertex IDs of each type of vertex in the vertex type table. The finite state machine traversal unifies and coordinates the subgraph traversal pipeline, dynamically capturing the boundaries of affected subgraphs with stable vertices as root nodes, and outputting the affected subgraph in an overlap-aware compressed sparse row format; the affected subgraph includes stable vertices, affected vertices, and their topological and feature information.

[0018] This technical solution significantly reduces invalid computation by accurately identifying unaffected vertices and affected subgraphs and performing calculations only on the changed parts; it optimizes data storage by using an overlap-aware compressed sparse row format to reduce memory access overhead; it achieves intelligent allocation of computing resources based on dynamic decision-making based on topology and feature consistency; it supports parallel scheduling of multiple snapshot tasks to maximize hardware parallelism; and it significantly improves the throughput and energy efficiency of dynamic graph neural network inference while ensuring inference accuracy, breaking through the performance and energy efficiency bottlenecks of existing solutions.

[0019] According to a preferred embodiment, the steps of constructing the affected subgraph by the multi-snapshot data loader include: extracting the initial DFS root node set consisting of stable vertices from the vertex type table, allocating an independent traversal thread for each root node, and starting the thread; reading the neighbor ID list of each snapshot of the root node in the concurrent processing batch; querying the vertex type table to obtain the type labels of the neighbors; and classifying the neighbors as affected vertices. Add the vertex set to the affected subgraph, and recursively perform neighbor reading and type judgment operations with the neighbor as the new traversal node; stop subgraph construction when all traversal threads have completed the recursive traversal and no new affected vertices have been added; organize the vertex, edge and feature data of the affected subgraph according to the association relationship of "vertex ID-snapshot ID-edge index-feature vector" to generate a subgraph data list.

[0020] This step accurately identifies the boundaries of the affected subgraph by traversing stable vertices in parallel as the initial root node, and only processes the changed parts instead of calculating the entire graph; it uses recursive depth-first search to dynamically capture affected vertices and avoids invalid calculations; it ensures computational efficiency through an automatic stopping mechanism; it optimizes the data organization by organizing vertex, edge, and feature data according to their relationships to improve data processing efficiency; and it significantly reduces computational overhead, improving the throughput and energy efficiency of dynamic graph neural network inference.

[0021] According to a preferred embodiment, the step of traversing the finite state machine to capture the complete affected subgraph includes: starting with the stable vertex data in the first-in-first-out buffer of the affected subgraph, gradually expanding and capturing the complete affected subgraph: wherein, the subgraph traversal pipeline uniformly coordinated by the finite state machine includes root node extraction, neighbor extraction, type detection, offset extraction and neighbor filtering; when no new affected vertices are filtered out in a certain round of traversal, the traversing finite state machine determines that the affected subgraph associated with the current root node is complete, triggers the subgraph completion signal, and returns to the root node extraction stage to process the next stable vertex.

[0022] This step coordinates the subgraph traversal pipeline through a finite state machine to accurately capture affected subgraphs; employs a first-in-first-out (FIFO) cache mechanism to ensure traversal order and avoid redundant calculations; achieves efficient termination of computation through a mechanism that "automatically stops when no new affected vertices are found"; improves parallel efficiency through pipelined processing (root node extraction, neighbor extraction, type detection, etc.); processes only the changed parts rather than the entire graph, significantly reducing computational overhead; ensures the integrity and consistency of affected subgraphs while maximizing hardware parallelism, improving the inference efficiency and energy efficiency of dynamic graph neural networks.

[0023] According to a preferred embodiment, the DGNN computation unit includes a combination processing unit and an aggregation processing unit; the combination processing unit performs feature combination operations of the GNN based on a MAC array of row matrix multiplication; the aggregation processing unit performs neighborhood feature aggregation operations of the GNN based on a parallel addition tree structure, and sends the aggregation result to the adaptive RNN unit.

[0024] This step efficiently performs feature combination operations through the row-matrix multiplication MAC array of the combined processing unit, and accelerates neighborhood feature aggregation through the parallel addition tree structure of the aggregation processing unit, significantly reducing data transmission overhead. It adopts hardware-level optimization design to achieve tight integration of computation and storage, improving GNN inference efficiency. By sending the aggregation results to the adaptive RNN unit, it achieves dynamic intelligent allocation of computing resources. While ensuring model accuracy, it significantly reduces computing energy consumption, improves the processing speed and energy efficiency of dynamic graph neural networks, and breaks through the performance and energy efficiency bottlenecks of traditional computing architectures.

[0025] According to a preferred embodiment, the processing steps of the combination processing unit in the DGNN computing unit include: loading sub-blocks of the weight matrix into the MAC array, splitting the source vertex features into row vector format, and matching them with the weight matrix sub-blocks; performing calculations according to row matrix multiplication of source vertex features × weight matrix; accumulating the feature combination operation results and generating a partial sum; storing the generated feature combination operation results in a private register for optimization, and sending the feature combination operation results and target neighbor features to the aggregation processing unit.

[0026] This step optimizes feature combination calculations using a row-matrix multiplication MAC array, achieving efficient matching between weight matrix sub-blocks and source vertex features; it processes feature data in row vector format to reduce data transmission overhead; it accumulates and generates partial sums to support parallel computation, improving computational efficiency; it stores the results in private registers for optimization, reducing memory access latency; and it efficiently transfers the results to the aggregation processing unit, achieving seamless integration of the computational process. These designs significantly reduce computational resource consumption, improve the processing speed of GNN feature combinations, provide more efficient hardware support for dynamic graph neural networks, while maintaining model accuracy, effectively improving overall inference performance and energy efficiency.

[0027] According to a preferred embodiment, the processing steps of the aggregation processing unit in the DGNN computing unit include: receiving the feature combination operation result and target neighbor features sent by the combination processing unit; integrating the feature data according to the dimensions of the source vertex features and all neighbors; processing the integrated feature data based on a parallel addition tree to obtain the sum of all neighbor features; in the case of mean aggregation mode, dividing the sum by the number of effective neighbors based on a divider to obtain a normalized aggregation result; and after the aggregation result is buffered by a level 1 register, forming the output feature of the vertex in the current snapshot. .

[0028] This step efficiently performs feature aggregation using a parallel additive tree structure, significantly reducing computational latency; dimensionality integration ensures complete information transmission; normalization processing of the mean aggregation pattern improves feature stability; and a level 1 register buffer optimizes data flow and reduces processing latency. These designs make the aggregation process more efficient, reduce computational resource consumption, and maintain feature quality. While ensuring the accuracy of the GNN model, it significantly improves the processing speed and energy efficiency of dynamic graph neural networks, providing high-performance computing support for real-time dynamic graph analysis.

[0029] According to a preferred embodiment, the step of the adaptive RNN unit determining the consistency of vertex features and topology among consecutive snapshots based on the aggregation result includes: calculating the cosine similarity of vertex features in consecutive snapshots and neighbor topology information, wherein, for stable vertices, the similarity score is directly calculated based on the topology consistency coefficient. For affected vertices, first calculate the output features. and The cosine similarity is then combined with the topological consistency coefficient and fused using a multiplier to obtain the similarity score. The similarity score of the GNN output feature results between consecutive snapshots is calculated in real time based on cosine similarity and neighbor topology information, and the similarity score is compared with a preset threshold. If the similarity score is greater than the high threshold, the vertex is determined to be a highly consistent vertex, the RNN unit update calculation is skipped, and the final feature of the vertex in the previous snapshot is directly reused. If the similarity score is between the high threshold and the low threshold, the vertex is determined to be a moderately consistent vertex, a part of the unit RNN update calculation is performed, the difference between the output features of the current snapshot and the previous snapshot is calculated, and the final feature of the previous snapshot is superimposed. If the similarity score is less than the low threshold, the vertex is determined to be a low-consistency vertex, and normal RNN unit update calculation is performed to generate the final feature of the current snapshot.

[0030] This step achieves intelligent allocation of computing resources by dynamically judging the vertex consistency level (high, medium, low): high-consistency vertices directly reuse previous snapshot features, medium-consistency vertices perform partial computation, and low-consistency vertices perform full computation; real-time evaluation based on cosine similarity and topological consistency coefficient ensures model accuracy; by skipping unnecessary computations, computational overhead is significantly reduced; and while ensuring inference accuracy, the processing speed and energy efficiency of dynamic graph neural networks are greatly improved, breaking through the performance bottleneck of traditional computing architectures.

[0031] According to a preferred embodiment, the adaptive RNN unit includes a similarity calculation unit, a compression unit, an RNN cell update unit, and an activation unit; the similarity calculation unit calculates the similarity score of the GNN output feature results between consecutive snapshots in real time; and compares the similarity score with a preset threshold; the preset threshold includes a low threshold. and high threshold If the similarity score is greater than the high threshold The previous snapshot RNN result can be reused directly; if the similarity score is between the low threshold... With high threshold Between these steps, the compression unit generates feature differences and compresses them into a dense format, updating incrementally based on the differences; if the similarity score is less than a low threshold... The RNN cell update unit performs RNN cell updates; the activation unit supports non-linear activation functions and outputs the final vertex features to the output buffer.

[0032] This step achieves intelligent allocation of computing resources through adaptive RNN units: highly consistent vertices directly reuse previous snapshot results, avoiding redundant computation; moderately consistent vertices generate feature differences through compression units and compress them into a dense format for incremental updates; low-consistency vertices perform full RNN computations. This hierarchical processing strategy significantly reduces invalid computations (avoiding 30%-50% of RNN cell updates) while maintaining model accuracy; compression units optimize data transmission and reduce memory access overhead; activation units ensure nonlinear transformation of features. While ensuring inference quality, this significantly improves the processing speed and energy efficiency of dynamic graph neural networks, breaking through the performance bottlenecks of traditional computing architectures.

[0033] This invention provides a second aspect of an FPGA-based dynamic graph neural network inference method. The method includes: classifying vertices in multiple consecutive snapshots of a dynamic graph into unaffected vertices, stable vertices, and affected vertices; using stable vertices as root nodes, concurrently prefetching affected vertices based on the topology of each snapshot to construct an affected subgraph; capturing the complete affected subgraph using a traversal finite state machine; organizing and continuously storing the data of the affected subgraph using an overlap-aware compressed sparse row storage format; real-time reading of computational tasks stored in a task first-in-first-out cache, and evenly distributing tasks to idle DGNN computation units according to the number of neighborhoods of each vertex, thereby supporting parallel scheduling of multi-snapshot tasks; the DGNN computation unit generating an aggregation result of DGNN inference for the vertices in the affected subgraph based on a multi-snapshot concurrent execution mode; judging the consistency of vertex features and topology between consecutive snapshots based on the aggregation result; and dynamically deciding whether to skip unnecessary RNN cell updates based on the judgment result.

[0034] Compared to the technical solution in CN110764799A, the snapshot of this invention is a snapshot of a dynamic graph, referring to a static view of the dynamic graph at a certain moment. Each snapshot contains the vertices, edges, and their features at that moment, and is a slice in the dynamic graph sequence. Multiple snapshots are used to capture the evolution of the graph over time for subsequent vertex classification, message passing, and incremental computation. The snapshots here are graph-oriented data structures used to represent changes in network topology and features over time.

[0035] The similarity calculation in this invention is used to optimize the inference of DGNN (Dynamic Graph Neural Network). Its core principle is to determine whether to skip or simplify calculations based on the features and topological changes of vertices between snapshots, thereby improving efficiency. It is a heuristic method that aims to determine whether to perform calculations by measuring the temporal changes of vertices, with temporal and topological changes as its core focus. If the features and neighbor relationships of a vertex do not change significantly between different snapshots, calculations can be skipped or simplified; this is a pruning strategy based on local changes. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the hardware architecture of the FPGA-based dynamic graph neural network inference system provided by the present invention; Figure 2 This is one schematic diagram of the multi-snapshot data loader architecture provided by the present invention; Figure 3 This is another schematic diagram of the multi-snapshot data loader architecture provided by the present invention; Figure 4 This is a flowchart of vertex classification provided by the present invention; Figure 5 This is a flowchart of the affected subgraph construction process provided by the present invention; Figure 6 This is a schematic diagram of converting the affected subgraph into an O-CSR table provided by the present invention; Figure 7 This is a schematic diagram illustrating the dynamic data update of the O-CSR table provided by the present invention; Figure 8 This is a flowchart of the similarity-aware unit skipping algorithm provided by the present invention; Figure 9 This is a schematic diagram comparing the normalized performance of the FPGA-based dynamic graph neural network inference system and the DGL-CPU provided by the present invention. Figure 10 This is a schematic diagram illustrating the performance of different solutions to the standardization to Cambricon-G provided by this invention.

[0037] List of reference numerals 100: Off-chip cache; 110: Vertex features; 120: Cell update data; 130: Graph structure; 140: Timestamp data; 150: Weight matrix; 200: Dynamic graph neural network inference system; 210: Multi-snapshot data loader; 211: Vertex extraction module; 212: Snapshot extraction module; 213: Offset extraction module; 214: Neighbor extraction module; 215: Feature extraction module; 216: Vertex recognition and classification module; 217: Traversal finite state machine; 218: Graph snapshot partitioning module; 219 220: Pre-configuration module; 221: Task FIFO cache; 222: Structure memory; 223: Feature memory; 224: O-CSR table; 230: Task scheduler; 240: Control unit; 250: DGNN computation module; 251: DGNN computation unit; 252: Private register; 260: Adaptive RNN unit; 261: Similarity calculation unit; 262: Activation unit; 263: Compression unit; 264: RNN cell update unit; 270: Output buffer; 280: On-chip cache. Detailed Implementation

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

[0039] This invention proposes a dynamic graph neural network inference system and method based on FPGA, which can also be called a hardware accelerator for dynamic graph neural network inference based on FPGA.

[0040] This invention proposes a dynamic graph neural network inference system and method based on FPGA. Its core idea is to deeply explore the topological and feature overlap characteristics between multiple time snapshots of dynamic graphs, and combine the high parallelism and flexible configurability advantages of FPGA hardware to build a data-driven dedicated acceleration architecture. While ensuring inference accuracy, it maximizes the parallelism of dynamic graph neural network (DGNN) inference, reduces memory access overhead and invalid computation, thereby breaking through the performance and energy efficiency bottlenecks of existing solutions. Specifically, the core ideas are reflected in four aspects: First, through a topology-aware snapshot concurrent execution mechanism, unaffected vertices and affected subgraphs are accurately identified, and only the changed parts are fully computed, achieving parallel processing of multiple snapshot data; Second, a cache-friendly O-CSR storage format is adopted, and data is compactly organized according to timestamps and topological features, reducing redundant storage and off-chip access; Third, based on a similarity-aware unit skipping strategy, RNN results are dynamically reused or incrementally updated, significantly reducing the timing computation overhead within a controllable range of accuracy loss; Fourth, a multi-stage adaptive computing architecture is constructed, deeply adapting to FPGA hardware characteristics, decoupling data loading and computation processes, maximizing hardware resource utilization and data parallelism, and ultimately achieving high throughput and low power consumption dynamic graph neural network inference.

[0041] Example 1 This embodiment provides an FPGA-based dynamic graph neural network inference system 200, i.e., a hardware accelerator, such as... Figure 1 As shown, the hardware accelerator includes a multi-snapshot data loader 210, an on-chip cache 280, a task scheduler 230, a DGNN computing module 250, and an adaptive RNN (Recurrent Neural Network) unit 260. Figure 1 The hardware accelerator's hardware module structure, data flow, and control logic are illustrated. Preferably, the hardware accelerator is built on an FPGA (Xilinx Alveo U280) platform, with "data-driven, topology-aware, and high-efficiency parallelism" as its core design principles. The functional modules work together to achieve multi-snapshot concurrent inference and redundant computation elimination.

[0042] In this invention, the hardware accelerator operates around the process of "data loading - task scheduling - computation execution - result processing" of DGNN inference.

[0043] like Figure 1As shown, the hardware accelerator and the off-chip cache 100 are connected via a wired connection. Preferably, both the hardware accelerator and the off-chip cache 100 are equipped with high-speed data ports (such as AXI, PCIe, or HBM interfaces) to achieve high-bandwidth, low-latency data exchange. When the hardware accelerator and the off-chip cache 100 are connected via a wired connection, this data port is a wired data port. When the hardware accelerator and the off-chip cache 100 are connected wirelessly, this data port is a communication port. The communication signal of this communication port is, for example, a WiFi signal, a Bluetooth signal, an infrared signal, etc.

[0044] The off-chip cache 100 stores information such as vertex features 110, cell update data 120, graph structure 130, timestamp data 140, and weight matrix 150.

[0045] In the hardware accelerator, the multi-snapshot data loader 210 is connected to the off-chip cache 100 via a data port to read multi-snapshot data from the off-chip cache 100, as shown in step ①. The data stream between the multi-snapshot data loader 210 and the off-chip cache 100 includes information such as vertex features 110, cell update data 120, graph structure 130, timestamp data 140, and weight matrix 150.

[0046] The multi-snapshot data loader 210 is configured to: classify vertices in multiple consecutive snapshots of a dynamic graph, dividing them into unaffected vertices, stable vertices, and affected vertices; using stable vertices as root nodes, concurrently prefetch affected vertices based on the topology of each snapshot to construct an affected subgraph; and capture the complete affected subgraph based on a traversal finite state machine.

[0047] Preferably, the multi-snapshot data loader 210 is connected to the task FIFO cache 220. The multi-snapshot data loader 210 stores the generated O-CSR table 223 and task metadata into the task FIFO cache 220, i.e., task FIFO, see [link to documentation]. Figure 1 Step ② and Figure 3 Step ⑤ in the process. That is, the task first-in-first-out cache 220 uses an overlap-aware compressed sparse row storage format to organize and store the data of the affected subgraphs contiguously.

[0048] The task FIFO cache 220 is also connected to the task scheduler 230. The task scheduler 230 reads the computation tasks stored in the task FIFO cache 220 in real time (see step ③).

[0049] The task scheduler 230 is connected to the DGNN computing module 250. The DGNN computing module 250 includes several parallel DGNN computing units 251 (DCUs). The task scheduler 230 evenly distributes tasks to idle DGNN computing units 251 according to the number of neighbors of each vertex (see step ④), thereby supporting parallel scheduling of multiple snapshot tasks.

[0050] DGNN computation unit 251 performs aggregation and combination computations of DGNN inference on vertices in the affected subgraph based on a multi-snapshot concurrent execution mode. DGNN computation module 250 is connected to adaptive RNN unit 260. DGNN computation module 250 sends the aggregation results of each DGNN computation unit 251 to adaptive RNN unit 260 (see step ⑤).

[0051] The adaptive RNN unit 260 determines the consistency between vertex features 110 and topology across consecutive snapshots based on the aggregation results; based on the determination results, it dynamically decides whether to skip unnecessary RNN cell updates. Figure 1 As shown, when the adaptive RNN unit 260 determines that a vertex is a low-consistency vertex, it generates the final feature of the current snapshot and passes it to the activation unit 262. The activation unit 262 activates the received final feature and sends the activation result to the output buffer 270 (see step ⑥). The output buffer 270 temporarily stores the final result and writes it back to the off-chip buffer 100 or transmits it downstream as needed (step ⑦ on the right).

[0052] According to a preferred embodiment, such as Figure 2 and Figure 3 As shown, the multi-snapshot data loader 210 includes a pre-configuration module 219, a vertex extraction module 211, a snapshot extraction module 212, an offset extraction module 213, a neighbor extraction module 214, a feature extraction module 215, a vertex recognition and classification module 216, a traversal finite state machine 217, and a graph snapshot partitioning module 218.

[0053] Preferably, the pre-configuration module 219 is connected to the off-chip cache 100 and the vertex extraction module 211, respectively. Preferably, the pre-configuration module 219 represents the dynamic graph to be processed as a snapshot sequence. The graph structure 130 of each snapshot is stored using a compressed sparse row format. The pre-configuration module 219 selects consecutive snapshots from the snapshot sequence based on the sliding window size. K Each snapshot is composed of a concurrent processing batch. Each concurrent processing batch contains a predefined number of snapshots.

[0054] Preferably, such as Figure 3As shown, the front-end configuration module 219 is also connected to the graph snapshot partitioning module 218 (GSPM). The front-end configuration module 219 sends concurrent processing batches of snapshots to the graph snapshot partitioning module 218. The graph snapshot partitioning module 218 (GSPM) is used to provide multiple snapshot data blocks for the first pipeline. The graph snapshot partitioning module 218 supports multiple partitioning strategies, dividing multiple consecutive snapshots in the current concurrent processing batch into partitions that can be processed in parallel. Each partition contains vertex ID, adjacency relationship, vertex feature 110, and timestamp information. The graph snapshot partitioning module 218 stores the partition data in a stack for subsequent processing by the first pipeline.

[0055] The multi-snapshot data loader 210 uses a multi-data loading hardware pipeline to identify and prioritize loading unaffected vertices, while also capturing affected subgraphs across multiple snapshots.

[0056] Preferably, such as Figure 3 As shown, the vertex extraction module 211, snapshot extraction module 212, offset extraction module 213, neighbor extraction module 214, feature extraction module 215, and vertex recognition and classification module 216 are connected in sequence to form the first pipeline.

[0057] Preferably, the vertex recognition and classification module 216 is connected to the traversal finite state machine 217. The traversal finite state machine 217 outputs an O-CSR table 223 and sends the O-CSR table 223 to the task first-in-first-out buffer 220.

[0058] The first pipeline's processing steps are as follows: Vertex extraction module 211 identifies vertices to be classified from snapshots in concurrent processing batches and marks them with visited tags to avoid duplicate processing. Snapshot extraction module 212 checks the existence of vertices in multiple snapshots and initially identifies vertices affected by topological omissions. Offset extraction module 213 obtains the position offset of the vertex in the adjacency list of each snapshot, preparing for subsequent reading of adjacent vertices. Neighbor extraction module 214 obtains the set of adjacent vertices of the vertex in each snapshot and determines whether the topology has changed. Feature extraction module 215 reads the feature vectors of the vertex itself and its adjacent vertices and determines whether the features have changed. Vertex identification and classification module 216 compares vertex ID consistency, feature changes, and local topological modifications, classifying vertices into unaffected vertices, stable vertices, and affected vertices; and stores the vertex IDs of each type of vertex in the vertex type table.

[0059] The finite state machine is used to coordinate the subgraph traversal pipeline (second pipeline). The boundary of the affected subgraph is dynamically captured with stable vertices as the root nodes, and the affected subgraph is output in accordance with the overlap-aware compressed sparse row format. The affected subgraph includes stable vertices, affected vertices and their topological and feature information.

[0060] The on-chip cache 280 adopts a hierarchical storage architecture, including 2MB feature memory 222 (caching vertex feature data), a 1MBO-CSR table (storing topology and timestamp information of affected subgraphs), 512KB structure memory 221 (storing graph structure offsets and other information), 128KB output cache (temporarily storing final inference results), and 256KB task FIFO cache 220. All on-chip caches 280 use ping-pong buffering technology to decouple data loading, computation, and storage operations, reducing access latency; and features of unaffected vertices and stable vertices are only loaded into the cache once, and reused repeatedly in multi-snapshot inference, reducing the access volume of the off-chip cache 100.

[0061] Preferably, the present invention describes the dynamic graph neural network inference method running on a hardware accelerator as follows.

[0062] S100: Data preprocessing.

[0063] The pre-configuration module 219 in the Multi-Snapshot Data Loader (MSDL) 210 divides all snapshots of the dynamic graph into several batches, each batch containing a pre-specified number of snapshots. The inference process of the dynamic graph neural network begins with the Graph Snapshot Partitioning Module 218 (GSPM). This module extracts a data partition from the current batch. The GSPM supports multiple partitioning strategies, and for each extracted partition, the required data (denoted as...)... It will be stored in a stack structure.

[0064] S110: The front-end configuration module 219 divides the received snapshots into batches.

[0065] The pre-configuration module 219 divides all snapshots of the dynamic graph into several parallel processing batches according to the predefined batch size.

[0066] Preferably, the pre-configuration module 219 represents the dynamic graph to be processed as a snapshot sequence. .

[0067] In the above formula, each snapshot is , Let be the vertex set at time t. For edge set, is the vertex feature matrix.

[0068] Preferably, the front-end configuration module 219 uses Compressed Sparse Rows (CSR) format to store the graph structure 130 of each snapshot.

[0069] Set the sliding window size The pre-configuration module 219 retrieves data from the snapshot sequence each time. G Selecting continuous KEach snapshot constitutes a concurrent processing batch. The concurrent processing batch is denoted as: .

[0070] In the above formula, The index of the currently processed snapshot and .

[0071] Taking the Flicker dataset (containing 134 snapshots) as an example, when the default batch size is set to 4 snapshots, it will be automatically divided into 34 batches, with the first 33 batches each containing 4 snapshots and the last batch containing 2 snapshots.

[0072] The front-end configuration module 219 sends the snapshots of the parallel processing batch to the graph snapshot partitioning module 218.

[0073] S120: Snapshot partitioning module 218 extracts partition data.

[0074] The graph snapshot partitioning module 218 extracts data partitions from the snapshots of the current batch. The graph snapshot partitioning module 218 supports multiple partitioning strategies to adapt to the characteristics of different dynamic graph datasets (such as the high-density edge graph of HepPh and the large-scale vertex graph of Flicker).

[0075] One partitioning strategy is a uniform partitioning strategy based on the number of vertices: the dynamic graph is partitioned according to a pre-set threshold for the number of vertices (e.g., each partition contains 1000 to 2000 vertices), ensuring that the amount of data in each partition remains balanced and preventing hardware pipeline blockage caused by an excessive number of vertices in a single partition. This strategy is suitable for dynamic graph scenarios where the vertex feature dimensions are consistent and the edge distribution is relatively uniform (e.g., the MovieLens dataset).

[0076] Another partitioning strategy is an adaptive partitioning strategy based on edge density: real-time statistics of the edge density of each region in the dynamic graph snapshot (defined as the ratio of the number of edges to the number of vertices). When the edge density exceeds a set threshold (e.g., 0.6), the size of the corresponding partition is automatically reduced (e.g., the number of vertices in the original partition is halved) to reduce the number of cross-accesses of neighboring data in high edge density regions and reduce the frequency of irregular memory access. This strategy is suitable for dynamic graph scenarios with uneven edge distribution (e.g., the Epinions dataset).

[0077] S130: The snapshot partitioning module 218 performs partitioned data storage.

[0078] For each extracted partition data, the image snapshot partitioning module 218 divides the partition data ( , , See also Figure 3 ) Stored on-chip stack (see Figure 3 In the process of partitioning, the partition data preferably includes basic information such as vertex ID, edge index, and feature pointer.

[0079] S200: The multi-snapshot data loader 210 classifies vertices and constructs the affected subgraphs.

[0080] like Figure 1 As shown in steps ① to ②, the multi-snapshot data loader 210 identifies unaffected vertices and loads them preferentially through the first and second pipelines, while capturing affected subgraphs across multiple snapshots to reduce redundant data processing.

[0081] S210: Beginning, as shown Figure 4 As shown.

[0082] Activate the first and second production lines.

[0083] The multi-snapshot data loader 210 starts a preset number of parallel data loading pipelines (the number of pipelines can be dynamically configured according to FPGA resources). Each pipeline group independently corresponds to 1-2 snapshots in the current batch, and establishes a data path through the on-chip cache 280 and the off-chip cache 100.

[0084] S211: Vertex extraction module 211 extracts vertices, such as... Figure 4 As shown.

[0085] Preferably, the vertex extraction module 211 is a dedicated hardware circuit. When the partition data of a new graph snapshot (generated by GSPM) is sent to the multi-snapshot data loader 210, the vertex extraction module 211 is triggered as the starting functional module of the pipeline. The core function of the vertex extraction module 211 is to randomly select a vertex to be processed from the structure memory 221, which is dedicated to storing graph topology information (e.g., selecting a vertex from snapshot t-1). ).

[0086] To prevent the same vertex from being processed repeatedly in subsequent pipeline stages or other parallel pipelines, once a vertex is selected, the vertex extraction module 211 will immediately set the bit corresponding to the vertex ID in the global "traversed vertex bitmap" to "1" (i.e. "visited"), ensuring that each vertex enters the pipeline only once.

[0087] Vertex extraction module 211 sends the extracted vertices and their tags to snapshot extraction module 212.

[0088] S212: Snapshot extraction module 212 extracts snapshots, such as... Figure 4 As shown.

[0089] For the vertices selected by vertex extraction module 211 The snapshot extraction module 212 is responsible for verifying its existence in all snapshots to be processed in the current batch (such as consecutive snapshots t, t+1, t+2).

[0090] Preferably, the snapshot extraction module 212 is a vertex ID comparison circuit. The processing steps of the vertex ID comparison circuit are as follows.

[0091] Vertex The vertex ID is compared one by one with the vertex ID list of each snapshot to be processed. If the ID is not found in any snapshot to be processed, it means that the vertex has undergone a structural change of "disappearance" during the cross-snapshot process. At this time, the vertex ID comparison circuit will directly generate an "affected vertex" mark and skip the subsequent part of the inspection process. If the vertex exists in all snapshots to be processed, the vertex ID comparison circuit will send the snapshot to the offset extraction module 213.

[0092] S213: Offset extraction module 213 extracts the offset, such as... Figure 4 As shown.

[0093] Preferably, the offset extraction module 213 is a dedicated hardware circuit, which can be called an offset extraction circuit.

[0094] The offset extraction module 213, based on the Compressed Sparse Line (CSR) format, calculates the vertex offset by accessing the pre-stored Vertex_Offset array (which records the starting position of each vertex in the edge index array). The start and end offsets of the neighbor index in each snapshot to be processed.

[0095] For example, in snapshot t, if the vertex If the starting offset is 100 and the ending offset is 150, it means that the IDs of its adjacent vertices are stored in bits 100 to 149 of the edge index array. The offset extraction module 213 sends the offset to the neighbor extraction module 214 to provide the address range for accurately reading neighbor data in the next stage.

[0096] S214: Neighbor extraction module 214 extracts neighbors, such as... Figure 4 As shown.

[0097] Preferably, the neighbor extraction module 214 is a dedicated hardware circuit, which can be called a neighbor extraction circuit.

[0098] Based on the offset range output by offset extraction module 213, neighbor extraction module 214 extracts data from structure memory 221 (see [link]). Figure 1 Read vertices from the adjacency list of ) A complete list of neighbor IDs. Structure memory 221 is a dedicated on-chip cache 280 configured to store topological data of a dynamic graph. This topological data includes, but is not limited to, vertex IDs of graph snapshots and adjacency relationships between vertices. Adjacency relationships can be, for example, vertex offset arrays (Vertex_Offset) in CSR format, adjacency lists, etc. Structure memory 221 stores the aforementioned topological data to support the execution of core operations such as vertex classification and affected subgraph construction.

[0099] For example, extract the vertices based on the offset of 100-150 in snapshot t. All neighbor IDs in this snapshot (such as , (etc.). To improve efficiency, this stage adopts a multi-port memory access design, which supports parallel reading of the edge index arrays of different snapshots.

[0100] S215: Feature extraction module 215 extracts features, such as... Figure 4 As shown.

[0101] Preferably, the feature extraction module 215 is a dedicated hardware circuit, which can be referred to as a feature extraction circuit.

[0102] The goal of feature extraction module 215 is to obtain vertices. The input feature data of the data and all its neighbors in each snapshot to be processed.

[0103] Specifically, the feature extraction module 215 locates the starting address in the feature memory 222 based on the vertex ID, and then reads the complete feature vector according to the feature dimensions—including vertices. The feature data includes the features of the vertex itself, as well as the features of its neighbors. Feature memory 222 is a dedicated on-chip cache 280 configured to store feature data of vertices in a dynamic graph. This feature data includes, but is not limited to, the original input features of vertices in each snapshot, and intermediate features obtained through preliminary processing by the DGNN computation module 250.

[0104] To address the pipeline throughput imbalance issue in the first pipeline and prevent blocking of preceding stages due to excessive feature reading time, the feature extraction module 215 parallelizes the neighbor extraction module 214 and the feature extraction module 215 through hardware replication. The neighbor extraction module 214 and the feature extraction module 215 operate independently, reading neighbor IDs and feature data respectively. The neighbor extraction module 214 and the feature extraction module 215 synchronously transmit neighbor and feature data to the next stage via an internal bus, thus balancing the processing time of each stage in the first pipeline.

[0105] S216: Vertex Recognition and Classification Module 216 identifies vertex categories.

[0106] Specifically, the vertex recognition and classification module 216 determines the vertex ID, its own characteristics, and changes in its neighbors, such as... Figure 4 As shown.

[0107] Preferably, the vertex recognition and classification module 216 includes three sets of hardware comparison circuits and result summarization logic circuits.

[0108] As the core component of vertex classification, the vertex recognition and classification module 216 completes cross-snapshot attribute comparison through three sets of hardware comparison circuits.

[0109] The first hardware comparison circuit is used to perform vertex ID consistency checks: confirming the vertex ID consistency. Does it and its neighbors maintain the same ID (without additions or deletions) in all pending snapshots?

[0110] The second hardware comparison circuit is used to perform feature change checks: for vertices The feature vectors of the feature vectors and their neighbors are compared one-dimensionally using floating-point methods to determine whether there are significant changes (differences exceeding a preset threshold).

[0111] The third hardware comparison circuit is used to perform local topology change checks: comparing vertices. The differences in the list of neighbor IDs across different snapshots are used to determine if any neighbors have been added, deleted, or had their order adjusted.

[0112] Based on the above inspection results, the three sets of hardware logic circuits of the vertex recognition and classification module 216 accurately classify the vertices into unaffected vertices, stable vertices, and affected vertices.

[0113] Preferably, the three sets of hardware comparison circuits are integrated inside the logic circuit of the vertex recognition and classification module 216, and adopt a parallel interconnection structure.

[0114] On the input side, three sets of hardware comparison circuits are connected in parallel to the common input port of the vertex recognition and classification module 216 through internal signal lines, and jointly receive the vertex data to be processed (including vertex ID, feature vector, neighbor ID list, etc.) and multiple snapshot information to realize the parallel distribution of input signals.

[0115] In terms of internal connectivity, each group of hardware comparison circuits independently completes its own exclusive comparison logic (namely ID consistency check, feature change check, and local topology change check), and achieves timing synchronization through internal control lines to ensure that cross-snapshot comparisons of the same vertex are completed within the same clock cycle.

[0116] On the output side, the comparison results of the three sets of hardware comparison circuits (such as consistency flags, feature changes, topological difference information, etc.) are transmitted to the result aggregation logic circuit in the vertex recognition and classification module 216 via dedicated signal lines. The result aggregation logic circuit then integrates the three sets of results to determine the vertex category. This connection method, through parallel processing and synchronous control, can efficiently complete multi-dimensional attribute comparison and adapt to the real-time requirements of dynamic graph vertex classification.

[0117] Preferably, such as Figure 4 As shown, if a vertex's ID, its own characteristics, and the IDs and characteristics of all its neighbors remain unchanged across snapshots, it is marked as an unaffected vertex. If a vertex's ID and its own characteristics remain unchanged across snapshots, but the IDs or characteristics of its neighbors change across snapshots, it is marked as a stable vertex. If its own vertex ID is missing or its own characteristics have changed, it is marked as an affected vertex.

[0118] The classification result of vertex recognition and classification module 216 will trigger different subsequent processing flows: such as Figure 4 As shown, the vertex identification and classification module 216 sends unaffected vertices to the task scheduler 230 to directly generate computation tasks. The vertex identification and classification module 216 sends stable vertex data to the affected subgraph's first-in-first-out (AS FIFO) buffer to await subgraph traversal. The vertex identification and classification module 216 marks affected vertices as core nodes of the subgraph.

[0119] S217: Vertex classification process ends.

[0120] S230: Enqueuing stable vertex data and generating tasks for unaffected vertices.

[0121] like Figure 3 As shown in steps ②-③, after the vertex recognition and classification module 216 outputs the classification result, for vertices marked as stable vertices, the vertex recognition and classification module 216 encapsulates the core data of the stable vertices according to a fixed format. (See also...) Figure 3 The core data encapsulated is, for example, The core encapsulated data includes vertex IDs, a list of neighbor IDs, a list of snapshot IDs, and a type label bitmap (see [link]). Figure 3 The encapsulated data frame is transmitted by the vertex recognition and classification module 216 to the affected subgraph first-in-first-out buffer (AS FIFO) via a dedicated data channel.

[0122] Preferably, the affected subgraph first-in-first-out buffer (AS FIFO) is implemented using a dual-port BRAM with a depth of 4096, supporting parallel operations that "write stable vertex data on one side and provide a read interface for the subgraph traversal pipeline on the other".

[0123] When writing, the vertex recognition and classification module 216 first checks the remaining space in the first-in-first-out buffer (AS FIFO) of the affected subgraph. If the space is insufficient, it triggers a "pause writing" signal and continues after the previous data is read to avoid data overflow.

[0124] For unaffected vertices determined by the vertex identification and classification module 216, since the vertex ID, its own features, and the vertex IDs and features of its neighbors do not change across snapshots, there is no need to enter the subgraph traversal process (second pipeline). Instead, the task scheduler 230 in the multi-snapshot data loader 210 directly generates the computation task.

[0125] Preferably, the task scheduler 230 extracts key information of unaffected vertices from the 0-CSR table 223 and assembles it into a task tuple in the format of "vertex type, source vertex ID, neighbor ID list, source vertex feature, target neighbor feature, timestamp".

[0126] The task scheduler 230 writes the generated task tuples into the task first-in-first-out buffer 220. The task tuples share the same queue as the affected vertex tasks, but are marked as "high priority" by a 2-bit priority field.

[0127] When the task scheduler 230 retrieves task tuples from the task first-in-first-out cache 220 and assigns tasks, it will prioritize processing tasks of high-priority unaffected vertices because their computation logic is fixed (without dynamic topology adjustment), which can be completed quickly and improve the overall pipeline utilization.

[0128] S240: Traverse the finite state machine 217 to capture the complete affected subgraph.

[0129] The finite state machine 217 is a hardware circuit.

[0130] like Figure 3 As shown in sections ③-④, the 5-level subgraph traversal pipeline (second pipeline) is uniformly coordinated by the traversal finite state machine (TFSM) 217. Starting with the stable vertex data in the first-in-first-out buffer (AS FIFO) of the affected subgraph, it gradually expands and captures the complete affected subgraph.

[0131] Preferably, the subgraph traversal pipeline coordinated by the finite state machine 217 includes root node extraction, neighbor extraction, type detection, offset extraction, and neighbor filtering.

[0132] S241: Traverse the finite state machine 217 to extract the root node, such as Figure 5 As shown.

[0133] Extract the initial root node set of DFS consisting of stable vertices from the vertex type table, allocate an independent traversal thread for each root node, and start the thread.

[0134] Traversing the finite state machine 217 triggers the start of the root node extraction phase, reading the first stable vertex data frame from the affected subgraph's first-in-first-out buffer (ASFIFO). The stable vertex data frame includes information such as vertex ID and a list of neighbor IDs.

[0135] Traversing the finite state machine 217, the stable vertex is marked as the "root node".

[0136] Traversing the finite state machine 217 first verifies the integrity of the data frame (such as checking the vertex ID format and snapshot ID range). If the verification passes, the basic information of the root node (ID, snapshot range) is stored in the on-chip cache 280 as the starting point for subgraph expansion. If the verification fails, the data frame is skipped and the next frame is read.

[0137] S242: Traverse the finite state machine 217 to extract the list of neighbor IDs, such as Figure 5 As shown.

[0138] The finite state machine 217 is traversed to read the neighbor ID list of each snapshot of the root node in the concurrent processing batch, and all neighbor information is extracted by the neighbor ID. The neighbor ID list comes from the data encapsulated by the vertex recognition and classification module 216.

[0139] The finite state machine 217 extracts all neighbor IDs of the root node from the structure memory 221; that is, the list of neighbor IDs. During the extraction process, the finite state machine 217 processes them separately according to the snapshot dimension. For example, it distinguishes and stores the neighbor IDs of the root node in snapshots t and t+1, and marks the snapshot number to which each neighbor belongs, providing context for subsequent type detection.

[0140] Traverse the finite state machine 217 to check if the neighbor ID list is not empty, such as Figure 5 As shown, if not, i.e., the neighbor ID list is empty (the root node has no neighbors), then the traversal process of the current root node is terminated directly, and the process returns to the root node extraction stage to read the next stable vertex. Figure 5 As shown, if the neighbor ID list is not empty, then the finite state machine 217 is traversed to extract the neighbors.

[0141] S243: Traverse the finite state machine 217 to perform type checking, such as Figure 5 As shown.

[0142] Traverse the finite state machine 217 to query the vertex type table to obtain the type labels of the neighbors.

[0143] Specifically, if the neighbor is an affected vertex, such as Figure 5As shown, the finite state machine 217 marks the neighbor as a subgraph vertex and adds the subgraph vertex to the vertex set of the affected subgraph. The neighbor is then used as the new traversal node, and the neighbor reading and type judgment operations are recursively performed.

[0144] If the neighboring vertices are stable vertices, such as Figure 5 As shown, the node marked as a potential expansion root node is sent to the first-in-first-out (AS FIFO) buffer of the affected subgraph. The potential expansion root node is not added to the subgraph for the time being, but its vertex ID is recorded for subsequent traversal.

[0145] If the neighbor is an unaffected vertex, such as Figure 5 As shown, traversing the finite state machine 217 directly marks the neighbor as not requiring processing and not included in the subgraph.

[0146] S244: Traverse the finite state machine 217 to extract the offset, such as Figure 5 As shown.

[0147] For the subgraph vertices marked in the type detection phase (i.e., affected neighbors), the finite state machine 217 is traversed in this phase to obtain the start and end offsets of the neighbor indexes of these affected neighbors in each snapshot.

[0148] Similar to the offset extraction process of offset extraction module 213, these offsets are used for the recursive construction of the subgraph in the next stage, providing address basis for reading the neighbors of the affected neighbors (i.e., the secondary nodes of the subgraph) in the next step, and realizing the recursive expansion of the subgraph.

[0149] S245: Traverse the finite state machine 217 to filter neighbors and recursively construct the subgraph.

[0150] Based on the offset extracted during the offset extraction phase, the finite state machine 217 is traversed to read the list of neighbor IDs of the affected neighbors, and the type detection logic is repeated: (e.g.) Figure 5 Check if there are any unvisited affected vertices; if not, terminate; if so, add the affected vertices to the vertex set of the affected subgraph, update the edge relationships of the subgraph, and recursively construct the subgraph, such as... Figure 5 As shown.

[0151] The process of updating the edge relationships of the subgraph by traversing finite state machine 217 is as follows: record the connection between the vertex and the parent node. At the same time, traversing finite state machine 217 adds the selected stable vertices to the tail of the queue of the task first-in-first-out buffer 220 of the affected subgraph, as new root nodes for the next round of traversal.

[0152] When all traversal threads have completed the recursive traversal and no new affected vertices have been added, the traversal finite state machine 217 stops subgraph construction. That is, when no new affected vertices are selected in a certain round of traversal, the traversal finite state machine 217 determines whether there are any unvisited affected vertices. If not, that is, the affected subgraph associated with the current root node is complete, the "subgraph complete" signal is triggered, and then the machine returns to the "root node extraction" stage to process the next stable vertex; if so, the subgraph is recursively constructed again.

[0153] S300: Storage and task assembly queuing of O-CSR table 223.

[0154] Traversing the finite state machine 217, the vertices, edges, and feature data of the affected subgraph are organized according to the association relationship of "vertex ID-snapshot ID-edge index-feature vector" to generate a subgraph data list.

[0155] like Figure 3 As shown in steps ④ and ⑤, after capturing the affected subgraphs through a 5-level subgraph traversal pipeline, the affected subgraph data is stored in a compact O-CSR format, forming an O-CSR table 223, which facilitates rapid retrieval of vertex, feature, and timestamp information. Next, based on the O-CSR table 223, a discrete computation task is assembled, including "vertex type, source vertex ID, neighbor ID list, source vertex features, target neighbor features, and timestamp," and sequentially passed into the task first-in-first-out buffer 220 (see also [reference]). Figure 1 (Parts ②-③)

[0156] S310: Initialization and parameter configuration of the O-CSR array.

[0157] The task first-in-first-out cache 220 uses an overlap-aware compressed sparse row (O-CSR) storage format to organize the data of the affected subgraph. For example... Figure 3 and Figure 6 As shown, the data in the O-CSR table 223 of the O-CSR format includes source vertex ID (Sindex array), neighbor ID list (Tindex array), timestamp (Timestamp array), edge count (Enum array), and feature (Feature array). Preferably, five core arrays are initialized in the on-chip cache 280.

[0158] like Figure 3 and Figure 6 As shown, the Sindex array records the source vertex ID and total number of vertices for each outgoing edge in the affected subgraph, with an additional "total number of vertices" flag at the end. Figure 3 As shown, the source vertex ID is , ... Finally, it ends with a -1 flag. For example... Figure 6 As shown, the source vertex ID is , , The "Total number of vertices" flag at the end is 4.

[0159] The Tindex array is used to record the target vertex IDs corresponding to the source vertices, following the order of the source vertices in the Sindex array. For example... Figure 3 As shown, in the Tindex array, the source vertex... The corresponding target vertex is a vertex. and vertex , and the source vertex The corresponding target vertex is a vertex. With source vertex The corresponding target vertex is a vertex. Finally, it ends with a -1 flag. For example... Figure 6 As shown, in the Tindex array, the source vertex... The corresponding target vertex is a vertex. and vertex , and the source vertex The corresponding target vertex is a vertex. With source vertex The corresponding target vertex is a vertex. .

[0160] The Timestamp array corresponds one-to-one with the Tindex array elements, used to record the snapshot ID to which each target vertex belongs. For example... Figure 3 As shown, in the Timestamp array, the source vertex... The corresponding timestamp is , and the source vertex The corresponding timestamp is , and the source vertex The corresponding timestamp is Finally, it ends with a -1 flag. For example... Figure 6 As shown, in the Timestamp array, the source vertex... The corresponding timestamp is , , , and the source vertex The corresponding timestamp is , and the source vertex The corresponding timestamp is .

[0161] The Enum array is used to record the number of edges spanning multiple snapshots for each source vertex, i.e., the number of neighbor IDs corresponding to that source vertex in the Tindex. For example... Figure 3 As shown, in the Enum array, the source vertex... The corresponding number of edges is That is, the source vertex have Edge; with source vertex The corresponding number of edges is That is, the source vertex There is an edge connecting to the source vertex. The corresponding number of edges is That is, the source vertex have Edge; ends with a -1 flag. For example... Figure 6 As shown, in the Enum array, the source vertex... The corresponding number of edges is That is, the source vertex There are four edges; connected to the source vertex. The corresponding number of edges is That is, the source vertex There is an edge connecting to the source vertex. The corresponding number of edges is That is, the source vertex There is one edge.

[0162] The `Feature` array stores the features of subgraph vertices across all snapshots, storing only the features of stable vertices once, while affected vertices store dynamic features according to snapshots. For example... Figure 3 As shown, in the Feature array, the source vertex... The corresponding feature at time t-1 is and ; and the source vertex The corresponding feature at time t is , and the source vertex The corresponding feature at time t+1 is Finally, it ends with a -1 flag. For example... Figure 6 As shown, in the Feature array, the source vertex... The corresponding features at times t-1, t, and t+1 are respectively , , , and ; and the source vertex The corresponding feature at time t is and , and the source vertex The corresponding feature at time t+1 is and .

[0163] The array length is dynamically adjusted based on the characteristics of the current dynamic graph dataset being processed (such as vertex ID range and feature dimension). For example, when processing the Flicker dataset (2.3 million vertices), the maximum length of the Sindex array is configured to be 2.3 million + 1, and the Feature array reserves storage space according to "number of vertices × feature dimension (162)".

[0164] This invention achieves continuous storage of affected subgraph data through O-CSR table 223, thereby reducing cache misses, lowering the access latency of off-chip cache 100, and supporting the insertion, update, and deletion operations of edges and vertices in dynamic graphs.

[0165] S320: The multi-snapshot data loader 210 writes the affected subgraph data into the O-CSR table 223.

[0166] After the complete affected subgraph data is output by the 5-level subgraph traversal pipeline, the finite state machine 217 writes the affected subgraph data into the O-CSR table 223 in the order of source vertex → edge → feature.

[0167] Iterate through each source vertex (including stable and affected vertices) in the affected subgraph, writing the source vertex IDs sequentially into the Sindex array; simultaneously, count the total number of edges for each source vertex across all snapshots. For example... Figure 6 As shown, source vertex There are 2 edges in snapshot t-1, 1 edge in t, and 1 edge in t+1, for a total of 4 edges. Write the edge count into the Enum array, corresponding one-to-one with the source vertex IDs in the Sindex array.

[0168] For each source vertex, read its neighbor ID list and corresponding snapshot ID in snapshot order (t→t+1→t+2), write the neighbor ID list into the Tindex array, and write the corresponding snapshot ID into the Timestamp array. For example... Figure 6 As shown, source vertex The neighbor ID list "5, 6, 5, 6" is written into the Tindex array in sequence, and the corresponding Timestamp array is written into "t-1, t-1, t, t+1".

[0169] For stable vertices, only their feature data from the first snapshot is read and written to the Feature array (e.g., source vertex). The feature only stores the feature version at time t-1.

[0170] For affected vertices, their dynamic features are read in snapshot order and written sequentially to the Feature array. An address mapping circuit records the association between features and vertex IDs and snapshot IDs to avoid duplicate storage. For example, the source vertex... The features need to be stored in two versions, t-1 and t.

[0171] S330: Create an O-CSR index.

[0172] A "source vertex-neighbor offset" index is constructed based on the Enum array. The finite state machine 217 is traversed to calculate the starting offset of each source vertex in the Tindex array (e.g., the starting offset of the first source vertex is 0, the starting offset of the second source vertex is equal to the number of edges of the first source vertex, and so on). The offset is stored in the Enum array. When the task scheduler 230 reads the neighbor data later, it can quickly locate the offset range through the source vertex ID, reducing the address calculation latency.

[0173] S34: Task scheduler 230 converts O-CSR table 223 into computation tasks.

[0174] The task scheduler 230 extracts data one by one according to the source vertex order in the Sindex array. First, it obtains the source vertex ID from the Sindex array, determines the number of neighbors of the source vertex from the Enum array, then reads the corresponding number of neighbor ID lists from the Tindex array, reads the source vertex features and target neighbor features from the Feature array, extracts the snapshot ID range from the Timestamp array, and finally supplements the "vertex type" field by combining the vertex classification results.

[0175] S350: Enqueueing and priority management of task FIFO cache 220.

[0176] The task FIFO cache 220 is implemented using a dual-port BRAM with a depth of 4096, supporting parallel operations of "writing task tuples while simultaneously allowing the task scheduler 230 to read them". Before writing, the task scheduler 230 queries the "full status" register of the task FIFO cache 220.

[0177] If the task FIFO buffer 220 is not full, the task tuple is written, and the "task count" register is updated simultaneously. If the task FIFO buffer 220 is full, writing is paused until the task scheduler 230 reads the task before continuing to avoid data overflow.

[0178] Add a 2-bit priority to the task tuple based on the "Vertex Type" field—unaffected vertex tasks are marked as "11" (highest priority), stable vertex tasks are marked as "10" (medium priority), and affected vertex tasks are marked as "01" (low priority).

[0179] When the task scheduler 230 allocates tasks, it processes them from high to low priority, prioritizing unaffected vertex tasks with simple computational logic to improve hardware utilization. When the number of tasks in the task FIFO cache 220 reaches a preset threshold (e.g., 75% of the total depth), the task scheduler 230 triggers a "high task load" signal, notifying the multi-snapshot data loader 210 to slow down task generation. When the number of tasks is below the threshold (e.g., 25%), the task scheduler 230 triggers a "low task load" signal to accelerate task generation and achieve flow control.

[0180] S400: Task scheduler 230 performs task scheduling and allocation.

[0181] like Figure 1 As shown in step ④, when the task first-in-first-out buffer 220 is not empty and the task scheduler 230 is triggered, the task scheduler 230 reads information from the task first-in-first-out buffer 220 to generate fine-grained tasks, and distributes them evenly to the idle DGNN computing units 251 according to the number of vertex neighbors, so as to ensure high utilization of computing units.

[0182] S500: DGNN computing unit 251 performs calculations and outputs aggregation results.

[0183] The DGNN computing unit 251 includes a combination processing unit (CPE) and an aggregation processing unit (APE). Each DGNN computing unit 251 is configured with a private register 252.

[0184] The combination processing unit is a MAC array based on row matrix multiplication, which performs feature combination operations on the GNN. The aggregation processing unit performs neighborhood feature aggregation operations on the GNN based on a parallel addition tree structure, and sends the aggregation results to the adaptive RNN unit 260.

[0185] S510: DGNN computing unit 251 receives tasks and prepares for computation.

[0186] When the task first-in-first-out buffer 220 is not empty and the DGNN computing unit 251 is in an idle state, the DGNN computing unit 251 receives the computing task assigned by the task scheduler 230 through the task receiving interface and temporarily stores the task in the private register 252 inside the DGNN computing unit 251.

[0187] Once caching is complete, the DGNN computation unit 251 sends a "task reception confirmation" signal to the task scheduler 230, marking itself as "busy." The DGNN computation unit 251 has a built-in data distribution circuit that splits key data in the task tuple according to computational requirements and transmits it to the corresponding ensemble processing unit. Specifically, the data distribution circuit transmits the source vertex features, target neighbor features, and model weight matrix 150 (read from the on-chip cache 280 and adapted to the current DGNN model layer) to the ensemble processing unit. The data distribution circuit also transmits the target neighbor features and the preliminary calculation results of CPE to the aggregation processing unit. The data distribution circuit records the Timestamp field in the task to ensure that the computation matches the snapshot batch.

[0188] S520: Combinatorial Processing Unit (CPE) performs the calculation of feature combinations.

[0189] Specifically, the combined processing unit consists of 256 32-bit floating-point multiply-accumulate (MAC) units, arranged in a 16×16 array to form a MAC array.

[0190] Before computation, the MAC array loads sub-blocks of weight matrix 150 and splits the source vertex features into row vectors, matching them with the sub-blocks of weight matrix 150. The combination processing unit performs calculations using row-matrix multiplication of source vertex features × weight matrix. Preferably, each MAC unit is responsible for multiplying one feature element with one weight element. The combination processing unit accumulates the feature combination operation results. The combination processing unit stores a partially calculated sum (Psum) from the generated feature combination operation results into a private register (PR) 252 for optimization, and sends the feature combination operation results and target neighbor features to the aggregation processing unit.

[0191] For example, given a 162-dimensional source vertex feature and a 162×64-dimensional weight matrix 150, the combination processing unit divides the weight matrix 150 into 10 16×16 sub-blocks (filling the remaining dimensions with zeros), performing multiplication and accumulation block by block to avoid pipeline blockage caused by excessive data volume in a single processing. After each sub-block is calculated, the intermediate result is stored in the private register 252. Once all sub-blocks have been processed, the complete combination result is transmitted to the aggregation processing unit via the internal bus, while a copy is temporarily stored in the private register 252 of the DGNN calculation unit for possible subsequent retry calculations.

[0192] S530: Aggregation Processing Unit (APE) performs the calculation of neighbor feature aggregation.

[0193] Specifically, the aggregation processing unit adopts a 4-level parallel addition tree structure, with each level containing 32 32-bit floating-point adders. It supports two aggregation modes: summation and averaging, which are switched by a 2-bit configuration signal and determined by the current DGNN model parameters. For example, GCN uses averaging aggregation.

[0194] The aggregation processing unit receives the feature combination operation results and target neighbor features sent by the combination processing unit. The aggregation processing unit integrates the feature data according to the dimension of the source vertex and all neighbors ("source vertex + all neighbors"). The aggregation processing unit processes the integrated feature data based on a parallel addition tree to obtain the cumulative sum of all neighbor features.

[0195] The addition tree starts from the lowest level, with each adder summing two feature elements, and the process is passed up level by level until the final output is the cumulative sum of all neighbor features. In the mean aggregation mode, after the accumulation is complete, the aggregation processing unit calls the divider to divide the cumulative sum by the number of valid neighbors (obtained from the neighbor ID list of the task tuple), obtaining the normalized aggregation result. The aggregation result is buffered in private register 252 and forms the output feature of the DGNN calculation module 250 with the vertex in the current snapshot. If the task involves multiple snapshots (such as t and t+1), repeat the above steps to generate the snapshots. .

[0196] S540: Signal interaction between the aggregation processing unit and the adaptive RNN unit 260.

[0197] The aggregation processing unit sends the aggregation result or the normalized aggregation result to the adaptive RNN unit 260. The aggregation processing unit packages the output features, vertex types and vertex IDs of the generated consecutive snapshots and transmits them to the feature receiving buffer of the adaptive RNN unit 260.

[0198] Once feature transfer is complete, the DGNN computation unit 251 sends a "feature ready" signal to the adaptive RNN unit 260 and simultaneously sends a "GNN computation complete" signal to the task scheduler 230, marking itself as "idle" and waiting to receive new tasks. Upon receiving the signal, the adaptive RNN unit 260 initiates the subsequent similarity calculation process.

[0199] S600: Adaptive RNN unit 260 judges the consistency between vertex features 110 and topology between consecutive snapshots based on the aggregation results.

[0200] like Figure 1 As shown, the adaptive RNN unit 260 includes a similarity calculation unit 261, a compression unit 263, an RNN cell update unit 264, and an activation unit 262.

[0201] like Figure 1As shown in sections ⑤-⑥, the adaptive RNN unit 260 first calculates the vertex similarity score and matches the update pattern. The update patterns include reusing the result above the threshold, calculating the feature difference between the threshold and the threshold, and updating completely below the threshold. The compression unit 263 is used to generate the feature difference, the RNN cell update unit 264 performs cell update, the activation unit 262 (AU) performs nonlinear transformation, and the final result is stored in the output buffer 270 for reading or writing back to the off-chip cache 100.

[0202] The core logic of the execution strategy of the adaptive RNN unit 260 is: based on the consistency between vertex features 110 and topology between consecutive snapshots, dynamically decide whether to skip unnecessary RNN cell updates, thereby improving computational efficiency while ensuring minimal loss of accuracy.

[0203] Changes in vertices in a dynamic graph manifest in two dimensions: changes in their own characteristics (such as updates to user attributes or changes in device status values) and changes in topology (such as the addition or removal of neighbors or changes in neighbor characteristics). A single-dimensional consistency assessment may lead to misjudgments; for example, a vertex whose characteristics remain unchanged but whose core neighbors have all changed needs to be recalculated. Therefore, similarity scores... The calculation needs to integrate both feature and topological information to achieve more accurate consistency determination.

[0204] S610: Similarity Calculation Unit 261 (SCU) determines update mode.

[0205] like Figure 8 As shown, the similarity calculation unit 261 extracts features and topology.

[0206] Similarity calculation unit 261 reads from DGNN calculation module 250 and Read vertex neighbor overlap information from on-chip cache 280 Intersection and stable public neighbor set Preferably, the neighbor overlap information of the vertex. Intersection, stable public neighborhood set It is derived from the Tindex and Timestamp arrays in O-CSR Table 223.

[0207] Preferably, This represents the number of neighbors of v when snapshot t is taken. This represents the number of neighbors of v at snapshot t+1. The number of neighbors can be obtained from O-CSR table 223.

[0208] Vertex neighbor overlap information The derivation process of the intersection is as follows.

[0209] and The number of neighbors is first determined by locating the source vertex using the Sindex array in O-CSR table 223. v The range of neighboring data in the Tindex array is determined by combining the Enum array, and then the Tindex elements of the corresponding snapshots t and t+1 are filtered and counted according to the Timestamp array.

[0210] Indicates in Vertices in snapshot t+1 The stable set of vertices among the common neighbors. This can also be obtained from O-CSR table 223.

[0211] Stable public neighborhood set The derivation process is as follows: First, take the intersection of the two snapshot neighbors mentioned above, then combine the vertex type label (from structure memory 221) to filter out stable vertices, and finally form a set and count them.

[0212] like Figure 8 As shown, the similarity calculation unit 261 determines whether a vertex is affected.

[0213] Specifically, for stable vertices, since the feature vectors do not change across snapshots, the similarity calculation unit 261 skips the "feature vector difference calculation" and directly bases the similarity on the topological consistency coefficient. Calculate similarity score .

[0214] For the affected vertices, similarity calculation unit 261 first calculates... and The cosine similarity (dot product ÷ modulus product) is combined with the topological consistency coefficient and then fused using a multiplier to obtain the similarity score. .

[0215] Similarity calculation unit 261 calculates similarity scores. The process is as follows.

[0216] Calculate the cosine similarity of vertex features 110 in consecutive snapshots and the neighbor topology information.

[0217] like Figure 8 As shown, the formula for calculating the feature cosine similarity by the similarity calculation unit 261 is as follows: .

[0218] Cosine similarity is a measure of vertex similarity. In consecutive snapshots The output features after processing by DGNN computing unit 251 in t+1 and The "vector direction consistency" refers to the comprehensive encoding of vertex attributes and local topology. The closer the directions are, the more stable the core information of the vertex (such as category and function). and Vertices In snapshot and the neighbor set of t+1, Extract the set of adjacent vertices that exist in both snapshots to reflect "persistently related neighbors". The larger the intersection, the more stable the underlying topology. As vertices In snapshot The set of stable vertices in the common neighbors at time t+1 is further filtered from the intersection to identify stable vertices (vertices whose own features remain unchanged across snapshots, but whose neighbors may change). The features of stable vertices are stable. The influence of topological stability is continuous and is the core basis for assessing topological stability.

[0219] like Figure 8 As shown, the similarity calculation unit 261 calculates the topological consistency coefficient. Preferably, the similarity calculation unit 261 obtains the topological consistency coefficient by dividing the number of stable common neighbors by the total number of intersections.

[0220] The formula for calculating the topology consistency coefficient is: .

[0221] In the above formula, To extract vertices In the neighbor set of snapshot t; Extracting Vertices In the neighbor set of snapshot t+1; The intersection of two neighbor sets The stable common neighbors set composed of stable vertices selected from the data; Indicates the number of elements in the set. The range is [0,1]. The larger the value, the higher the stability of the core neighbors. The smaller the change in the topological environment.

[0222] like Figure 8 As shown, the similarity calculation unit 261 calculates the similarity score: the similarity calculation unit 261 calculates the similarity score of the GNN output feature results between consecutive snapshots in real time based on cosine similarity and neighbor topology information.

[0223] Therefore, the similarity score is: .

[0224] .

[0225] In the above formula, and Vertices In snapshot and Output features after processing by the DGNN computation module 250 and Output features and The norm of .

[0226] In the above formula, the similarity score The value range is [-1, 1].

[0227] The similarity score is a weighted fusion of features and topology, using multiplicative fusion instead of additive fusion to ensure that "if the stability of any dimension of features or topology is low, the overall similarity score will be low." "The values ​​are all low." For example, when the features remain unchanged but all core neighbors change, , ,final .

[0228] like Figure 8 As shown, the similarity calculation unit 261 determines the relationship between the similarity score and a preset threshold. Specifically, the similarity calculation unit 261 compares the similarity score with the preset threshold and outputs a signal indicating the calculation mode.

[0229] Set two similarity thresholds (Low threshold) and (High threshold), and satisfy For example, the similarity calculation unit 261 will assign a similarity score. With low threshold (Default -0.5), High Threshold (Default 0.5) Comparison. Similarity calculation unit 261 calculates similarity scores based on... The comparison result with the preset threshold selects the computation mode of RNN cell update unit 264, such as... Figure 8 As shown.

[0230] .

[0231] As mentioned above, if the similarity score is greater than the high threshold The similarity calculation unit 261 determines that the vertex is a highly consistent vertex and outputs a "skip mode" signal, that is, it skips the update calculation of the RNN cell update unit 264 and directly reuses the final features of the vertex in the previous snapshot. .

[0232] If the similarity score is within a low threshold With high threshold Between these steps, the similarity calculation unit 261 determines that the vertex is a moderately consistent vertex and outputs a "similarity calculation mode" signal. That is, the RNN cell update unit 264 performs a part of the RNN unit update calculation, calculates the difference between the output features of the current snapshot and the previous snapshot, and superimposes the final features of the previous snapshot. The compression unit 263 generates feature differences and compresses them into a dense format, and updates based on the difference increment.

[0233] If the similarity score is less than the low threshold The similarity calculation unit 261 determines that a vertex is a low-consistency vertex and outputs a normal mode signal. For example... Figure 8 As shown, RNN cell update unit 264 initiates a standard RNN cell update, that is, performs normal RNN cell update calculations to generate the final features of the current snapshot. Activation unit 262 supports non-linear activation functions and outputs the final vertex features 110 to output buffer 270.

[0234] S620: Performs RNN cell updates in different modes.

[0235] If the output signal is in skip mode, the similarity calculation unit 261 sends the result to the "intermediate cache" (which stores the previous snapshot RNN result). With state value Send a "read and reuse" signal, and the intermediate buffer directly outputs the result of the previous snapshot of the RNN. With state value As the final feature of the current snapshot With new state value Skip all RNN computations to reduce latency.

[0236] If the output signal is in normal mode, the similarity calculation unit 261 will output the features. The data is transmitted to RNN cell update unit 264, initiating a standard RNN cell update. RNN cell update unit 264 utilizes the complete output features. State value compared to the previous snapshot Perform the entire calculation process to generate new final features. With state value The data is transmitted to the activation unit 262.

[0237] Compression unit 263 includes an incremental generation module and a mask generation module. If the output signal is a similarity calculation mode, such as... Figure 8 As shown, the incremental generation module in compression unit 263 calculates the feature difference between the output features of consecutive snapshots: .

[0238] like Figure 8As shown, the mask generation module in compression unit 263 generates a zero-value mask, and extracts non-zero values ​​based on the zero-value mask. Element. A zero-value mask refers to: The absolute value of the element is less than the preset microvalue. The value is 0 if the value is not zero, otherwise it is 1. The RNN cell update unit 264 only records non-zero values. Element performs RNN cell updates (see Figure 8 ), to obtain the final features At the same time, update the status value. .

[0239] Because the role of the RNN cell update unit 264 is to fuse the temporal features of vertices and capture dynamic changes, when the similarity score θ is sufficiently high, it indicates that the vertex changes are minimal, and the computation of the RNN cell update unit 264 can be simplified or skipped. The above method, through dual evaluation of feature vector direction and core neighbor stability, allows the similarity score θ to more accurately reflect the degree of dynamic change of vertices. This avoids invalid reuse when features remain unchanged but the topology changes drastically, and reduces redundant computation when features are fine-tuned but the core remains stable. Under the premise of controlling the accuracy loss to within 1%, it significantly improves the computational efficiency of the RNN cell update unit 264.

[0240] S630: Activation unit 262 receives and activates the output feature, then ends. Figure 8 As shown.

[0241] Activation unit 262 receives the final features from each computing mode. Perform a nonlinear transformation on the final features based on the current model configuration. Activation is performed. Activation unit 262 will activate the final feature. Write to output buffer 270, and simultaneously set the new status value. Write back to the "intermediate cache" to overwrite the original state value. This ensures consistency in the state of the next batch of calculations.

[0242] S640: Write back output buffer 270.

[0243] When the number of final features in the output buffer 270 reaches a preset threshold, or when the current snapshot batch processing is completed, the output buffer 270 triggers a "result write-back" signal, writing the final features back to the off-chip cache 100 for storage via the PCIe interface or loading them into the multi-snapshot data loader 210 for subsequent applications to read.

[0244] S700: Results summary and batch completion notification.

[0245] The adaptive RNN unit 260 sends an "RNN calculation completed" signal to the control unit 240. The control unit 240 summarizes the status of the DGNN calculation unit 251 and the adaptive RNN unit 260. If all tasks in the current batch are completed, the "batch inference completed" signal is triggered, which notifies the multi-snapshot data loader 210 to start loading the next batch of data.

[0246] To verify the effectiveness of the method and device of this invention, hardware implementation and system evaluation were performed on a Xilinx Alveo U280 FPGA board. This accelerator card is equipped with an XCU280 FPGA chip, featuring 1.08 million lookup tables (LUTs), 4.5 MB of on-chip block RAM (BRAM), 30 MB of on-chip UltraRAM, 9024 digital signal processing (DSP) slices, and two 4GB high-bandwidth memory 2 (HBM2) stacks, resulting in a total memory bandwidth of 460 GB / s. To determine the clock frequency, Xilinx Vivado 2019.1 was used, and the operating frequency was conservatively set to 280 MHz in the experiments.

[0247] Benchmarking and Dynamic Datasets: Table 1 summarizes the five real-world dynamic graph neural network (GNN) research datasets used for evaluation: HepPh (HP), Gdelt (GT), MovieLens (ML), Epinions (EP), and Flicker (FK). This invention was evaluated using three widely accepted GNN models: CD-GCN, GC-LSTM, and T-GCN, configured with 4, 3, and 2 layers, respectively. Table 2 shows the resource utilization of this invention across all the GNN models used for evaluation.

[0248] Table 1 Real-world dynamic graphics dataset

[0249] Table 2 Resource utilization of this invention on Xilinx ALVEO U280 FPGA

[0250] Baseline and evaluation metrics: This invention was compared with five solutions: DGL-CPU (v2.4.0), PiPAD, DGNN-Booster, E-DGCN, and Cambricon-DG. DGL-CPU was the best-performing solution on the CPU platform, while PiPAD is the most advanced framework for Dynamic Graph Neural Networks (DGNN) on a GPU. In the experiments, DGL-CPU was run on an Intel Xeon 6151 processor with 65 cores, a clock speed of 3.0 GHz, and 696 GB of memory; PiPAD was run on an NVIDIA Tesla A100 GPU with 6912 cores and 80 GB of High Bandwidth Memory (HBM). DGNN-Booster, E-DGCN, and Cambricon-DG are cutting-edge hardware dynamic graph neural network accelerators. CPU power consumption was estimated using Intel product specifications. GPU power consumption was obtained through the NVIDIA System Management Interface (nvidia-smi). Please note that, to evaluate the effectiveness of this invention, DGL has also been modified to support DGNN inference using the topology-aware concurrent execution method of this invention. In the experiments below, this invention was run on the aforementioned NVIDIA Tesla A100 GPU, and it achieved an average performance increase of 4.8 times compared to the version running on the aforementioned CPU platform. Furthermore, the default batch snapshot number is set to 4 in this invention.

[0251] Comparison with mainstream systems: like Figure 9 As shown, the hardware implementation of this invention is compared with mainstream systems (DGL-CPU, PiPAD) and the system implementation of this invention, with DGL-CPU as the baseline for comparing the speedup of each method. The overall performance of the system implementation of this invention is better than PiPAD, mainly because PiPAD produces higher data access time and lower data parallelism than this method. Specifically, in the test instance, PiPAD's memory access time is 2.7 to 4.1 times that of the method of this invention. This difference stems from PiPAD needing to transfer the features of all vertices, even if the features of most vertices remain consistent across four snapshots. However, due to the higher runtime overhead, the performance of the system implementation of this invention is only slightly better than PiPAD. Compared with the system implementation, the hardware implementation of this invention not only guarantees less redundant computation and memory access, but also significantly reduces runtime overhead. Figure 9 The hardware implementation of the present invention is shown to be 415.2-612.6 times (average 535.2 times) and 92.8-166.4 times (average 84.3 times) faster than DGL-CPU and PiPAD, respectively; and energy consumption is reduced by 742.6 times and 104.9 times, respectively.

[0252] Comparison with mainstream DGNN accelerators: like Figure 10 As shown, the performance of this invention significantly outperforms Cambricon-G, DGNN-Booster, and RACE, with average speed improvements of 13.5x, 10.2x, and 6.5x, respectively. This performance advantage primarily stems from the fact that, compared to DGNN-Booster, E-DGCN, and Cambricon-DG, this invention reduces redundant and unnecessary memory accesses by 78.3%-84.6%, 69.2%-72.5%, and 52.1%-63.4%, respectively. Compared to existing accelerators, this invention effectively avoids redundant accesses to unaffected and stable vertices in multiple snapshots, reduces unnecessary RNN computations, and improves data parallelism. Furthermore, due to the significant reduction in redundant and unnecessary computations, as well as fewer off-chip memory transfers, this invention achieves average power consumption reductions of 15.9x, 11.7x, and 7.8x compared to these hardware accelerators, respectively.

[0253] Example 2 This embodiment illustrates the operating steps in Embodiment 1; repeated content will not be repeated.

[0254] The pre-configuration process for starting the Multi Snapshot Data Loader (MSDL) 210.

[0255] The dynamic graph to be processed is represented as a snapshot sequence. , where each snapshot . Let be the vertex set at time t. For edge set, It is a vertex feature matrix, and the snapshot image structure is stored in O-CSR format. The sliding window size is set. Each time from the snapshot sequence G Selecting continuous K A batch of snapshots constitutes a concurrent processing batch. A concurrent processing batch is denoted as... , The index of the currently processed snapshot and .

[0256] The first hardware pipeline of the Multi Snapshot Data Loader (MSDL) 210 is launched to process batches concurrently. Each vertex Parallel reading of its in Features in a snapshot Neighbor set and characteristics of neighbors.

[0257] Start the multi-snapshot data loader 210 for vertices Judge based on feature consistency: If for any and All satisfy (If the numerical values ​​match perfectly in each dimension), then the vertex is determined. If the self-feature remains unchanged across snapshots, it is determined that the self-feature has changed across snapshots.

[0258] Vertices whose features are invariant across snapshots The multi-snapshot data loader 210 is then started to further determine its topology consistency. If for any and All satisfy (The neighbor ID sets are completely identical), and for any All meet Then, the multi-snapshot data loader 210 will be started to load the vertex data. The vertex is classified as unaffected.

[0259] If it exists and , making Or exist and Then, the Multi Snapshot Data Loader (MSDL) 210 will be started to load the vertices. It is classified as a stable vertex.

[0260] Vertices whose own features change across snapshots Or add / delete in some snapshots (i.e., exist) Make And exist Make The vertex of ) The multi-snapshot data loader 210 is launched to directly classify them as affected vertices.

[0261] The multi-snapshot data loader 210 is launched to complete the vertex for each classification. Generate type labels. The type label uses a 2-bit binary identifier, where "00" represents an unaffected vertex, "01" represents a stable vertex, and "10" represents an affected vertex. The vertex ID and the corresponding type label are stored in the vertex type table.

[0262] The multi-snapshot data loader 210 extracts all stable vertices from the vertex type table to form the initial root node set for DFS. An independent traversal thread is assigned to each root node. The number of traversal threads is the same as the number of root nodes, m, and all threads start in parallel. The multi-snapshot data loader 210 is started to read the root nodes. In concurrent batch processing The list of neighbor IDs for each snapshot, extracted from the list of neighbor IDs in O-CSR table 223. For each snapshot of the neighbors ( ), query the "vertex type table" to obtain neighbors. The type tag.

[0263] like If the type label is "10" (affected vertex) and it has not been added to the affected subgraph, then the neighbor will be... Add to the vertex set of the affected subgraph, and by neighbor. For the new traversed node, recursively perform neighbor read and type judgment operations.

[0264] If neighbors If the type label is "00" (unaffected vertex), then only neighbors are recorded. With the root node The relationship between neighbors, not neighbors Add the affected subgraph.

[0265] If neighbors If the type label is "01" (stable vertex) and it has already been used as the root node of another thread, then skip that neighbor. To avoid repeated traversal.

[0266] When all traversal threads have completed the recursive traversal and no new affected vertices have been added, the multi-snapshot data loader 210 stops subgraph construction. At this point, the vertex set of the affected subgraph is the union of the stable vertex set and the newly added affected vertex set, and the edge set is the sum of all vertices in the concurrent processing batch. The set of associated edges in the image. Stable vertices in the set of associated edges store only one cross-snapshot feature, while affected vertices store the features corresponding to each snapshot. The multi-snapshot data loader 210 organizes the vertex, edge, and feature data of the affected subgraph according to the association relationship of "vertex ID-snapshot ID-edge index-feature vector" to generate a subgraph data list.

[0267] The DGNN computation module 250 processes unaffected vertices as follows: During the initialization phase of each inference layer, it reads the feature data and neighbor feature data of all unaffected vertices from the off-chip cache 100 and stores them in the "unaffected vertex cache" of the on-chip cache 280. This "unaffected vertex cache" uses ping-pong buffering technology to support parallel data read and write. During the inference process of this layer, batches are processed concurrently. All snapshot computation tasks read the data of unaffected vertices directly from the "unaffected vertex cache", without having to load it repeatedly from the off-chip cache 100. The computation of unaffected vertices is only executed once, and the computation results are reused by all snapshots.

[0268] The DGNN computation module 250 processes the affected subgraph as follows: it splits it into fine-grained tasks according to the "vertex-snapshot" principle and stores them in the task FIFO cache 220. The task scheduler 230 evenly distributes the tasks to multiple DGNN computation units (DCUs) 251 according to the number of neighbors. The task scheduler 230 handles tasks where the number of neighbors exceeds a threshold. Tasks (50-200) are assigned to the high-priority DGNN computation unit 251.

[0269] Each DGNN computation unit 251 reads data from the O-CSR table 223 and performs GNN aggregation and combination computations in parallel. The DGNN computation unit 251 stores intermediate results in a private register (PR) 252. The DGNN computation unit 251 merges the results of affected vertices with the results of unaffected vertices output by itself to generate the complete inference result for that layer, which is then passed to the subsequent RNN cell update unit 264 for temporal feature fusion, completing the concurrent batch processing. This layer of reasoning.

[0270] The process of initializing the array of O-CSR table 223 is as follows.

[0271] Initialize the Sindex array: Iterate through all source vertices of the affected subgraph, recording the ID of each source vertex in ascending order of vertex ID, and add a terminating element to the end of the array. The value of this terminating element is the total number of vertices in the affected subgraph, used to identify the array boundary. For example, if the affected subgraph contains source vertices... and vertex Then the Sindex array is initialized to [4, 5, total number of vertices].

[0272] Initialize the Tindex array: For each source vertex, according to the source vertex in the concurrent processing batch. (including) K The edge connection order of each snapshot in a series of consecutive snapshots is recorded sequentially, along with the corresponding target vertex IDs.

[0273] For example, source vertex In snapshot connect , In snapshot connect In snapshot connect Then the corresponding Tindex array The entries are [5,6,5,6].

[0274] Initialize the Timestamp array: It corresponds one-to-one with the entries in the Tindex array, recording the snapshot ID of each target vertex. For example, the Timestamp array entry corresponding to [5,6,5,6] in the Tindex array is [t-1,t-1,t,t+1].

[0275] Initialize the Enum array: Record the total number of edges contained in the K snapshots for each source vertex, in the order of the source vertices in the Sindex array. For example, source vertex... exist There are a total of 4 edges in each snapshot, then the corresponding edge in the Enum array is... The number of entries is 4.

[0276] Initialize the Feature array: Iterate through the vertices of the affected subgraph. For stable vertices, store only their complete feature vector in any snapshot (because features remain unchanged across snapshots).

[0277] For affected vertices, their feature vectors in each snapshot are stored in order of snapshot ID; for example, stable vertices. storage Affected vertices storage , .

[0278] like Figure 6 As shown, O-CSR Table 223 compactly organizes the affected subgraph data of multiple snapshots according to the "source vertex-target vertex-snapshot" dimension, while storing only the single features of stable vertices.

[0279] exist Figure 6 In the affected subgraph on the left, the vertices For stable vertices, vertices , , These are the affected vertices. Vertices With vertex The arrow between them and the adjacent (t-1, t) represent the vertices in snapshots with snapshot numbers (timestamps) t-1 and t. To the top It has edges. Vertex With vertex The arrows between them and the adjacent (t-1, t+1) indicate the vertices in snapshots numbered t-1 and t. To the top It has edges. Vertex With vertex The arrow between them and the t+1 next to it indicate the vertex in snapshot number t+1. To the top It has edges. Vertex To the top The arrow and the 't' next to it indicate the vertex in snapshot number 't'. To the top It has edges. The Sindex array records the ID of each source vertex in the affected subgraph, and appends "total number of vertices" (the content enclosed in a dashed box) to the end to mark the array boundaries, which is used to quickly locate the source vertex data. Figure 6 In the middle, [4, 5, 6, 7] is the ID of the source vertex, and the last [4] is the total number of vertices.

[0280] like Figure 6 As shown, the Tindex array corresponds to Sindex. According to the edge connection order of the source vertex in multiple snapshots, the target vertex ID is recorded sequentially to achieve continuous edge storage. Figure 6 In the diagram, [5, 6, 5, 6] is the source vertex. The target vertex ID, followed by [6] is The target vertex ID, [5] is The target vertex ID.

[0281] like Figure 6 As shown, the entries in the Timestamp array and the Tindex array correspond one-to-one, recording the snapshot ID to which each edge belongs, establishing an "edge-time" association. [t-1, t-1, t, t+1] represent vertices respectively. To the top , , The timestamp of the edge snapshot, where [t] indicates the vertex. To the top The timestamp of the edge, the last [t+1] represents the vertex. To the top The timestamp of the edge.

[0282] like Figure 6 As shown, the Enum array, ordered by the Sindex array, records the total number of edges for each source vertex across multiple snapshots, used to determine the reading range of the Tindex / Timestamp array. Figure 6 [4] in the text represents the source vertex. There are 4 target adjacent vertices. The part of the Tindex / Timestamp array with indices 0 to 3 should be read, and the latter [1] represents the source vertex. There is one target vertex. The part of the Tindex / Timestamp array with index 4 should be read, and the following [0] indicates... There is no target vertex; the last [1] represents the source vertex. There is one target vertex; the portion of the Tindex / Timestamp array at index 5 should be read.

[0283] like Figure 6 As shown, the Feature array stores vertex features, and the affected vertices store their own and their neighbors' features in snapshot order. Because of the vertices... Since the vertices are stable, the features only need to be stored once, so the Feature array with indices 0-4 is used to store them. ], with vertex The corresponding features and neighbor features are [ ], stored in the Feature array with indices 5-6, and related to the vertices Corresponding features and neighbor features [ It is stored in the Feature array with indices 7 to 8.

[0284] like Figure 7 As shown, the process of dynamically updating the data in O-CSR Table 223 is as follows.

[0285] When an edge insertion operation occurs in a dynamic graph (such as in a snapshot) New source vertex in China To the vertex that is the target vertex When finding the edge, locate the source vertex in the Tindex array. Add vertices to the end of the corresponding edge sequence Find the position with the same index as Tindex in the Timestamp array and add it. and the source vertices in the Enum array The corresponding edge count is incremented by 1. When an edge deletion operation occurs in the dynamic graph (such as in a snapshot), the edge count is incremented by 1. Delete source vertex To the target vertex When locating the edge (the vertex), locate the Tindex array containing the vertex. Corresponding and Timestamp is For entries that are invalid, mark them as invalid (using a special value such as -1), and skip the invalid entries on subsequent visits.

[0286] When a vertex addition operation occurs in the dynamic graph (such as adding an affected vertex), When adding a vertex to the end of the existing source vertex ID sequence in the Sindex array, add the vertex. Add edge connections to new vertices in the Tindex array. The target vertex ID; add the corresponding snapshot ID to the edge connection relationship of the added vertex in the Timestamp array; add the vertex in the Enum array. The number of edges in the Feature array, if a new vertex is added. For stable vertices, only one copy of their features that remain unchanged across snapshots is stored; for affected vertices, their features in each snapshot are stored in snapshot order, while the feature access index is updated to support fast location.

[0287] like Figure 7 As shown, the elements enclosed in dashed boxes represent the changed content. For example, when a vertex with snapshot number t+2 is added... To the top When finding the edge (the edge enclosed in the dashed ellipse), the Tindex array finds the edge that is related to the source vertex. [7] is added to the end of the corresponding Tindex array range (i.e., the position with index 4), and [t+2] is added to the end of the corresponding Timestamp array range (i.e., the position with index 4). The vertices in the Enum array... The corresponding array element (i.e., the position with index 0) is incremented by 1, because To stabilize the vertex, it only needs to be stored once, so the Feature array is added at the corresponding end (i.e., at index 5). .

[0288] The process of optimizing data access in O-CSR Table 223 is as follows.

[0289] When the DGNN computing unit 251 performs GNN aggregation calculation, it locates the starting index of the source vertex to be accessed in the Sindex array according to the ID of the source vertex to be accessed, and determines the reading range of the corresponding data in the Tindex array and the Timestamp array by combining the number of edges of the source vertex in the Enum array, so as to realize continuous address access.

[0290] For example, source vertex If the starting index in the Sindex array is 0 and the Enum value is 4, then the DGNN computing unit 251 reads entries with indices 0-3 in the Tindex array and entries with indices 0-3 in the Timestamp array. When reading target neighbor features, the DGNN computing unit 251 quickly locates the corresponding feature vector in the Feature array based on the target vertex ID and snapshot ID. For stable vertices, the DGNN computing unit 251 directly reads the uniquely stored feature vector. For affected vertices, the DGNN computing unit 251 indexes the corresponding feature vector based on the snapshot ID, avoiding address jumps caused by snapshot switching and reducing cache misses.

[0291] The process of controlling the space complexity in O-CSR Table 223 is as follows.

[0292] Based on the number of edges of the affected subgraph Number of vertices Snapshot count and feature dimensions The total space complexity of controlling O-CSR table 223 is Preferably, 2 The space overhead of the corresponding Tindex array and Timestamp array The space overhead corresponds to the Sindex array, Enum array, and Feature array. By storing only the single-time features of stable vertices and marking invalid edges instead of physically deleting them, the actual storage space usage is further reduced, ensuring that the data stored in the O-CSR table 223 can be adapted to the on-chip cache 280 capacity and reducing the access frequency of the off-chip cache 100.

[0293] Similarity score θ The calculation process is as follows.

[0294] Adaptive RNN unit 260 extracts the same vertex from two consecutive snapshots t and t+1. Output features after processing by the DGNN computation module 250 and The output feature is a vector of dimension D.

[0295] Through formula Calculate the final similarity score Similarity score The value range is [-1, 1].

[0296] The dynamic decision-making mechanism of the DGNN computation unit 251 on the computation mode of the RNN cell update unit 264 is as follows.

[0297] When similarity score At that time, determine the vertex For highly consistent vertices, skip the current RNN unit update calculation in RNN cell update unit 264 and directly reuse the vertex. In snapshot The final feature As a snapshot The final feature : .

[0298] when At that time, determine the vertex For vertices with moderate consistency, calculate the eigenvalue difference. The differences are sparsified to filter out values ​​whose absolute values ​​are less than a preset minimum value. The dimension; only the non-zero difference dimension is updated using the RNN part to generate the final feature: .

[0299] In the above formula, This indicates an RNN computation submodule that only processes non-zero differences.

[0300] .

[0301] when At that time, determine the vertex For vertices with low consistency, perform a complete RNN cell update computation, i.e., the final feature. .

[0302] In the above formula, This represents the RNN computation submodule that processes the complete feature vector.

[0303] The final feature of all computational models All of these require nonlinear transformation using activation functions (such as tanh or ReLU) to ensure the numerical stability of the output features.

[0304] The core idea of ​​this step is to precisely prune redundant computations based on the consistency of vertices across snapshots, retaining only the necessary update operations. This significantly reduces computational overhead at the expense of minimal precision. Compared to the traditional RNN model that performs full computation on all vertices, it can reduce a large amount of RNN computation (the specific proportion depends on the frequency of change in the dynamic graph), especially in scenarios with low vertex change rates (such as social networks and academic citation networks).

[0305] The implementation principle of the dynamic decision-making mechanism of the DGNN computing unit 251 for the computing mode of the RNN cell update unit 264 is as follows.

[0306] When the characteristics of the vertices are highly consistent with the topology ( When the RNN output feature H changes, the change is negligible and it can be directly reused. As This eliminates the gated computations of RNNs (such as the forget gate, input gate, and output gate operations of LSTM) and matrix multiplications, reducing the computational cost to zero. For example, in social networks, "users who are long-term active and have stable social relationships" have features that change very little with their neighbors, and reusing historical results can avoid redundant computations. When the vertex features and topological consistency are within two threshold ranges ( When this happens, only a portion of the RNN output features change significantly, and this is addressed by partially updating the submodule. For the feature difference Sparsification and filtering The system performs gating operations only on dimensions with non-zero differences to avoid invalid calculations on dimensions with meaningless changes, while also using incremental stacking. Preserving valid information from historical features allows for a significant reduction in computational cost with minimal loss of precision. This applies only to features or vertices undergoing dramatic topological changes. Perform a complete RNN computation These types of vertices typically account for a small percentage in dynamic graphs, so the overall computational cost is still significantly lower than that of a full, complete computation.

[0307] The adaptive adjustment strategy for the threshold parameter is as follows.

[0308] During the initialization phase, a low threshold is set based on the dynamic graph dataset type. and high threshold The default value. For example, the default value for social network class graphs. Academic citation class diagram (default) .

[0309] After processing every 100 consecutive snapshots, the vertex counts in the current batch are calculated. Distribution and inference accuracy loss. If accuracy loss... Then the high threshold Increase the value by 0.05 (not exceeding 0.5) to expand the range of vertices skipped in the calculation. This will result in a loss of accuracy. Then the low threshold Reduce the threshold by 0.05 (but not lower than -0.5) to narrow the range of vertices skipped in the calculation; ensure that the adjusted threshold always meets the requirements. Furthermore, the accuracy loss is controlled within 1%.

[0310] Because different types of dynamic graphs exhibit significant differences in their vertex change patterns, static thresholds cannot adequately address all these variations. Adaptive strategies, however, achieve a "scenario-customized start" by matching default values ​​to dataset types during the initialization phase. This avoids the drawbacks of a "one-size-fits-all" static threshold, ensuring that the threshold aligns with the scenario's characteristics from the outset and reducing decision-making errors in the initial stage. The vertex change rate of dynamic graphs fluctuates over time and during the inference phase. For example, on social networks, user interaction surges during "holiday marketing periods," leading to an increased change rate; while on academic networks, new citations decrease after "conference deadlines," resulting in a lower change rate. Static thresholds can suffer from either "over-precision" or "under-efficiency" due to these fluctuations in change rate. Adaptive strategies, by adjusting every 100 snapshots, achieve "real-time dynamic calibration," effectively resisting noise interference and avoiding error accumulation. Accuracy is adjusted upwards only when there is minimal loss. Expand the calculation skip range to improve efficiency, and lower the threshold when the loss is large. Narrow the skip range to maintain accuracy, balancing accuracy and efficiency; adjustments will always meet the requirements. Furthermore, the accuracy loss was controlled within 1%, balancing the effectiveness of the mechanism with the reliability of the results.

[0311] Example 3 This embodiment is an example of Embodiment 1 and Embodiment 2, and repeated content will not be repeated.

[0312] The physical hardware of the multi-snapshot data loader 210 is an FPGA-based first hardware accelerator used to efficiently process multi-snapshot data and realize the hardware-based loading and preprocessing of data. The core of the first hardware accelerator is a 6-stage pipeline structure, which completes vertex classification (unaffected / stable / affected vertices), affected subgraph construction, and O-CSR format conversion through hardware logic.

[0313] The physical hardware of the on-chip cache 280 is the FPGA on-chip storage resource, belonging to a multi-level cache system (L1 / L2), including 2MB feature memory 222 (caching vertex feature data), 1MB O-CSR table (storing topology and timestamp information of affected subgraphs), 512KB structure memory 221 (storing graph structure offsets and other information), 128KB output cache (temporarily storing final inference results), and 256KB task FIFO cache 220. All on-chip caches 280 adopt ping-pong buffering technology to decouple data loading, computation, and storage operations, reducing access latency; and unaffected vertices and stable vertex features are only loaded into the cache once, and reused repeatedly in multi-snapshot inference, reducing the access volume of the off-chip cache 100.

[0314] The physical hardware of the task scheduler 230 is a hardware-based real-time task scheduler based on FPGA. It is written in VHDL and implements a load balancing scheduling algorithm based on vertex neighborhood through combinational logic circuits and sequential logic circuits. This algorithm allocates computing resources according to the number of adjacent edges (Enum array) of vertices in the O-CSR table 223 to avoid load skew.

[0315] The physical hardware of the DGNN computing module 250 is an FPGA-based parallel computing array (containing multiple DGNN computing units 251).

[0316] Parallel computing arrays refer to dedicated or reconfigurable hardware architectures that integrate multiple physical computing elements (PEs) on the same hardware chip or circuit board according to a specific interconnection topology (such as meshes, rings, trees, hypercubes, etc.). These physical computing elements can perform computational operations simultaneously, working together through shared or local storage and high-speed interconnects to achieve high-throughput, low-latency parallel processing of computationally intensive tasks (such as matrix operations, signal processing, graph computation, neural network inference, etc.).

[0317] Each physical computing unit consists of a combination processing unit (CPE, including a MAC array) and an aggregation processing unit (APE, including an additive tree). It realizes the aggregation and combination calculation of dynamic graphs through electronic circuits and supports the parallel execution of multiple snapshot tasks.

[0318] The Combinator Processing Unit (CPE) is a dedicated hardware processing unit implemented based on electronic circuits. Its core physical structure consists of a MAC (multiply-accumulate) array, which is a key component of the physical computing unit. Preferably, the MAC array in the Combinator Processing Unit (CPE) is implemented using electronic circuit elements such as transistors, logic gates, and registers. Together with dedicated data paths (including registers and multiplexers) and control logic (state machine and instruction decoder), it is specifically designed for efficiently executing feature combination operations of the GNN.

[0319] The physical hardware of the Aggregation Processing Unit (APE) is a hardware module built on a dedicated FPGA arithmetic unit (such as a DSP Slice). Its core is an addition tree structure, implemented using a tree-like circuit composed of multiple levels of full adders and half adders, supplemented by data buffers (registers and FIFO buffers) and control units (counters and state machines), used to perform neighborhood feature aggregation operations for the GNN. The Aggregation Processing Unit (APE) sends the aggregation results to the Adaptive RNN unit 260 via an internal bus.

[0320] The physical hardware of the adaptive RNN unit 260 is a second hardware accelerator based on FPGA, which integrates a similarity calculation unit and a dynamic RNN circuit to realize the dynamic allocation of RNN computing resources: by comparing the vertex features of consecutive snapshots with topological similarity, the hardware-level decision is made on whether to skip RNN cell updates, thereby reducing redundant computation.

[0321] The physical hardware of the control unit 240 is an FPGA-based control logic circuit. The control logic circuit is physically connected to the first hardware accelerator, the cache structure, the real-time task scheduler, the parallel computing array, and the second hardware accelerator via an internal bus to coordinate the timing of each module (such as ping-pong buffer control and pipeline handshake signals) to ensure that data flow and computation are synchronized.

[0322] The first hardware accelerator is physically connected to the off-chip cache 100 and receives consecutive snapshots of the dynamic graph from it. The first hardware accelerator classifies the vertices in the multiple consecutive snapshots of the dynamic graph into unaffected vertices, stable vertices, and affected vertices. After classifying the vertices, using stable vertices as root nodes, the first hardware accelerator constructs the affected subgraph by concurrently prefetching affected vertices through a finite state machine (TFSM) 217. The first hardware accelerator is connected to the on-chip cache 280 via an internal bus and sends the affected subgraph to the on-chip cache 280.

[0323] After receiving the affected subgraph from the first hardware accelerator, the on-chip cache 280 uses the O-CSR format (including arrays such as Sindex, Tindex, and Timestamp) to organize and store the data of the affected subgraph contiguously, thereby achieving single-copy storage of stable vertex features and reducing redundancy.

[0324] The on-chip cache 280 is physically connected to the real-time task scheduler via an internal bus. The real-time task scheduler is connected to the task FIFO cache 220 within the on-chip cache 280. The physical hardware of the task FIFO cache 220 is an FPGA-based FIFO cache structure. The real-time task scheduler reads the computational tasks stored in the FIFO cache structure in real time. The real-time task scheduler distributes tasks evenly based on the number of neighbors at each vertex.

[0325] The real-time task scheduler is physically connected to the parallel computing array via an internal bus. The real-time task scheduler sends tasks to idle physical computing units within the parallel computing array, thereby supporting parallel scheduling of multiple snapshot tasks.

[0326] After receiving a task from the real-time task scheduler, the physical computing unit performs parallel aggregation (such as mean aggregation, attention aggregation) and combination (such as matrix multiplication) calculations on the vertices in the affected subgraph and outputs intermediate aggregation results.

[0327] The physical computing unit is physically connected to the second hardware accelerator via an internal bus, sending the aggregation results to the second hardware accelerator. After receiving the aggregation results from the physical computing unit, the second hardware accelerator determines the consistency of vertex features and topology between consecutive snapshots based on the aggregation results, and dynamically decides the RNN cell update strategy (skip or execute).

[0328] The second hardware accelerator is physically connected to the control logic circuit via an internal bus. After the second hardware accelerator completes its calculation, it sends an "RNN calculation complete" signal to the control logic circuit. The control logic circuit summarizes the status of the physical computing unit and the second hardware accelerator. If all tasks in the current batch are completed, it triggers a "batch inference complete" signal, notifying the first hardware accelerator to start loading the next batch of data.

Claims

1. A dynamic graph neural network inference system based on FPGA, characterized in that, The system includes: A multi-snapshot data loader (210) is used to classify vertices in multiple consecutive snapshots of a dynamic graph, dividing the vertices into unaffected vertices, stable vertices, and affected vertices; using the stable vertices as root nodes, the affected vertices are prefetched concurrently based on the topology of each snapshot to construct an affected subgraph; and the complete affected subgraph is captured based on a traversal finite state machine (217). The on-chip cache (280) uses an overlap-aware compressed sparse row storage format to organize and store the data of the affected subgraph contiguously; The task scheduler (230) reads the computation tasks stored in the task first-in-first-out cache (220) in real time and distributes the tasks evenly to the idle DGNN computing units (251) according to the number of neighbors of each vertex, thereby supporting parallel scheduling of multiple snapshot tasks. The DGNN computation module (250) includes several DGNN computation units (251). The DGNN computation units (251) perform aggregation and combination computation of DGNN inference on the vertices in the affected subgraph based on a multi-snapshot concurrent execution mode, and send the aggregation result to the adaptive RNN unit. The adaptive RNN unit (260) determines the consistency of vertex features and topology between consecutive snapshots based on the aggregation results; and dynamically decides whether to skip unnecessary RNN cell updates based on the determination results.

2. The system according to claim 1, characterized in that, The multi-snapshot data loader (210) includes: The pre-configuration module (219) represents the dynamic graph to be processed as a snapshot sequence. The structure of each snapshot image is stored using a compressed sparse row format; consecutive snapshots are selected from the snapshot sequence based on the sliding window size. K Each snapshot constitutes a concurrent processing batch; The vertex extraction module (211) identifies vertices to be classified from snapshots of concurrent processing batches and marks visited vertices with tags to avoid duplicate processing; The snapshot extraction module (212) checks the existence of vertices in multiple snapshots and initially identifies the affected vertices due to topological omissions; The offset extraction module (213) obtains the position offset of the vertex in each snapshot adjacency list, in preparation for subsequent reading of adjacent vertices; The neighbor extraction module (214) obtains the set of adjacent vertices of each vertex in each snapshot and determines whether the topology has changed; The feature extraction module (215) reads the feature vectors of the vertex itself and its adjacent vertices and determines whether the features have changed. The vertex identification and classification module (216) compares vertex ID consistency, feature changes and local topology modifications, classifies vertices into unaffected vertices, stable vertices and affected vertices; and stores the vertex IDs of each type of vertex in the vertex type table. Traverse the finite state machine (217), coordinate the subgraph traversal pipeline, dynamically capture the boundary of the affected subgraph with stable vertices as root nodes, and output the affected subgraph that conforms to the overlap-aware compressed sparse line format. The affected subgraph includes the stable vertices, the affected vertices, and their topological and feature information.

3. The system according to claim 1 or 2, characterized in that, The steps of the multi-snapshot data loader (210) in constructing the affected subgraph include: Extract the initial root node set of DFS consisting of stable vertices from the vertex type table, allocate an independent traversal thread for each root node, and start the thread; Read the list of neighbor IDs of each snapshot of the root node in the concurrent processing batch; Query the vertex type table to obtain the type labels of the neighbors; Add the neighbors of the affected vertex category to the vertex set of the affected subgraph, and recursively perform neighbor reading and type judgment operations with the neighbors as the new traversal nodes; Subgraph construction stops when all traversal threads have completed the recursive traversal and no new affected vertices have been added. The vertex, edge, and feature data of the affected subgraph are organized according to the association relationship of "vertex ID-snapshot ID-edge index-feature vector" to generate a subgraph data list.

4. The system according to any one of claims 1 to 3, characterized in that, The steps of traversing the finite state machine (217) to capture the complete affected subgraph include: Starting with the stable vertex data in the first-in-first-out cache of the affected subgraph, gradually expand and capture the complete affected subgraph: The subgraph traversal pipeline, which is uniformly coordinated by the traversal finite state machine (217), includes root node extraction, neighbor extraction, type detection, offset extraction, and neighbor filtering. When no new affected vertices are selected in a certain round of traversal, the traversal finite state machine (217) determines that the affected subgraph associated with the current root node is complete, triggers the subgraph completion signal, and returns to the root node extraction stage to process the next stable vertex.

5. The system according to any one of claims 1 to 4, characterized in that, The DGNN computing unit (251) includes a combination processing unit and an aggregation processing unit; The combined processing unit performs feature combination operations of GNN based on the MAC array of row matrix multiplication; The aggregation processing unit performs neighborhood feature aggregation operations of GNN based on a parallel addition tree structure and sends the aggregation results to the adaptive RNN unit (260).

6. The system according to any one of claims 1 to 5, characterized in that, The processing steps of the combined processing unit in the DGNN computing unit (251) include: The MAC array loads sub-blocks of the weight matrix and splits the source vertex features into row vector format, matching them with the sub-blocks of the weight matrix; The calculation is performed using row-matrix multiplication of the source vertex features and the weight matrix; The results of feature combination operations are summed and a partial sum is generated. The generated feature combination operation results are stored in a private register for optimization, and the feature combination operation results and target neighbor features are sent to the aggregation processing unit.

7. The system according to any one of claims 1 to 6, characterized in that, The processing steps of the aggregation processing unit in the DGNN computing unit (251) include: Receive the feature combination operation results and target neighbor features sent by the combination processing unit; Feature data is integrated according to the source vertex features and the dimensions of all neighbors; The integrated feature data is processed based on a parallel addition tree to obtain the sum of all neighbor features; In the mean aggregation mode, the sum is divided by the number of valid neighbors using a divider to obtain a normalized aggregation result. The aggregation result, after being buffered by a level 1 register, forms the output features of the vertices in the current snapshot. .

8. The system according to any one of claims 1 to 7, characterized in that, The steps of the adaptive RNN unit (260) in determining the consistency between vertex features and topology between consecutive snapshots based on the aggregation results include: Calculate the cosine similarity of vertex features in consecutive snapshots and the neighbor topology information. For stable vertices, the similarity score is directly calculated based on the topological consistency coefficient. For affected vertices, first calculate the output features. and The cosine similarity is then combined with the topological consistency coefficient and fused using a multiplier to obtain the similarity score. ; The similarity score of the GNN output feature results between consecutive snapshots is calculated in real time based on cosine similarity and neighbor topology information, and the similarity score is compared with a preset threshold. If the similarity score is greater than the high threshold, the vertex is determined to be a highly consistent vertex, the RNN unit update calculation is skipped, and the final feature of the vertex in the previous snapshot is directly reused; If the similarity score is between the high and low thresholds, the vertex is determined to be a moderately consistent vertex. A portion of the RNN unit update calculation is performed, the difference between the output features of the current snapshot and the previous snapshot is calculated, and the final features of the previous snapshot are superimposed. If the similarity score is less than the low threshold, the vertex is determined to be a low consistency vertex, and normal RNN unit update calculation is performed to generate the final features of the current snapshot.

9. The system according to any one of claims 1 to 8, characterized in that, The adaptive RNN unit (260) includes a similarity calculation unit (261), a compression unit (263), an RNN cell update unit (264), and an activation unit (262). The similarity calculation unit (261) calculates the similarity score of the GNN output feature results between consecutive snapshots in real time; and compares the similarity score with a preset threshold; the preset threshold includes a low threshold. and high threshold ; If the similarity is greater than the high threshold The RNN result from the previous snapshot can be reused directly; If the similarity is within a low threshold With high threshold Between these, the compression unit (263) generates feature differences and compresses them into a dense format, updating based on the difference increment; If the similarity is less than the low threshold The RNN cell update unit (264) performs RNN cell update; The activation unit (262) supports non-linear activation functions and outputs the final vertex features to the output buffer (270).

10. A dynamic graph neural network inference method based on FPGA, characterized in that, The method includes: The vertices in multiple consecutive snapshots of the dynamic graph are classified into unaffected vertices, stable vertices and affected vertices; the affected vertices are prefetched concurrently based on the topology of each snapshot using the stable vertices as the root nodes, and the affected subgraph is constructed; the complete affected subgraph is captured based on the traversal finite state machine (217); The data of the affected subgraph is organized and stored contiguously using an overlap-aware compressed sparse row storage format; The computation tasks stored in the task first-in-first-out cache (220) are read in real time, and the tasks are evenly distributed to the idle DGNN computation units (251) according to the number of neighbors of each vertex, thereby supporting parallel scheduling of multiple snapshot tasks. Aggregated results of DGNN inference are generated for the vertices in the affected subgraph based on a multi-snapshot concurrent execution mode; The consistency of vertex features and topology between consecutive snapshots is judged based on the aggregation results; the judgment results are used to dynamically decide whether to skip unnecessary RNN cell updates.

Images