---
title: Verilog Property Graph (VeriPG)
url: https://www.emergentmind.com/topics/verilog-property-graph-veripg
type: topic
---

# Verilog Property Graph (VeriPG)

Searching arXiv for the cited papers to ground the article in the current records.
Verilog Property Graph (VeriPG) is a unified intermediate representation for Verilog RTL in which a Verilog module is modeled as a directed property graph that combines syntactic features from the abstract syntax tree (AST) with semantic information derived from control flow and data dependency graphs. In VerilogLAVD, VeriPG serves as the structural substrate on which LLM-generated vulnerability rules operate: rather than asking an LLM to reason directly over raw Verilog text, the system first converts the design into a graph that explicitly exposes syntax, control flow, and data dependencies, then asks the LLM to generate traversal rules over that graph from Common Weakness Enumeration (CWE) descriptions [2508.13092].

## 1. Conceptual motivation and problem setting

VeriPG was introduced in the context of early-stage hardware vulnerability detection, where timely detection during design is important for reducing remediation costs. The motivating claim is that existing early detection techniques often require specialized security expertise, and that recent efforts using large language models for Verilog vulnerability detection remain limited because LLMs have a weak understanding of Verilog structure and concurrency semantics. The reported consequence is inconsistent detections and a high number of false positives because the models are misled by irrelevant information [2508.13092].

The representation is positioned against three alternatives. Raw Verilog code preserves textual detail, but the system description states that LLM-only reasoning over Verilog text is fragile because it does not reliably capture structure. AST-only methods preserve syntax, but many hardware vulnerabilities depend on control conditions and signal propagation, which are not explicit in the AST alone. The paper uses CWE-1280 as an example: determining how a variable is used before being initialized cannot be reliably captured by syntax alone. Generic software-oriented graph forms, including software Code Property Graphs, are also treated as insufficiently specific because Verilog has concurrency, timing sensitivity, and RTL control-flow properties that differ from software CFGs [2508.13092].

Within this framing, VeriPG is intended to integrate syntax from the AST, execution structure from CFG, and signal semantics from DDG. This gives LLM-generated rules a structured target to traverse, reducing reliance on natural-language reasoning over raw code. A plausible implication is that VeriPG is not merely a storage format for parsed RTL; it is a task-specific program representation designed to expose the dependencies needed for vulnerability detection.

## 2. Constituents of the graph

The paper states that VeriPG integrates three graph representations: AST, CFG, and DDG [2508.13092]. Each contributes a different aspect of Verilog RTL semantics.

The AST provides syntactic structure. The node names, node types, source line numbers, and values are stored as node attributes. This makes the AST the fine-grained carrier of local syntax.

The CFG provides control-flow semantics and is built over procedural blocks such as `Always` blocks, `IfStatement`, and `ForStatement`. The description explicitly notes that Verilog CFG construction must handle parallel statements, unlike conventional software CFGs. That distinction matters because concurrency is one of the reasons a Verilog-specific property graph is required rather than direct reuse of software graph models.

The DDG provides data-dependency semantics by analyzing signal definitions, signal usages, and dependency relationships. Its role is to capture how values flow between statements and signals.

A concise comparison of the three constituents as described for VeriPG is shown below.

| Component | Information captured | Examples stated in the source |
|---|---|---|
| AST | Syntactic structure | node names, node types, source line numbers, values |
| CFG | Control-flow semantics | `Always`, `IfStatement`, `ForStatement`, parallel statements |
| DDG | Data-dependency semantics | signal definitions, signal usages, dependency relationships |

The significance of this decomposition is that no single constituent is treated as sufficient. AST supplies structure, CFG supplies execution ordering and branch semantics, and DDG supplies propagation semantics. The paper’s argument is therefore not simply that graphs are useful, but that vulnerability detection in RTL requires a fused representation of multiple graph semantics [2508.13092].

## 3. Formal definition and graph fusion

The unified representation is given a formal graph definition. The paper states: “Formally, a Verilog module is represented as a directed graph \(G=(V,E,A^V,A^E)\), where \(V\) is AST node (\(V_A\)), \(E\) contains \(E_A\), \(E_C\) and \(E_D\), \(A^V\) is property of \(V\), contains \(name\), \(type\), \(lineno\) and \(value\), \(A^E\) is property of \(E\), contain \(type\), \(condition\)” [2508.13092].

Under this definition, the unified graph contains AST-derived vertices together with CFG/DDG-aligned nodes, and three edge classes: AST edges \(E_A\), CFG edges \(E_C\), and DDG edges \(E_D\). The node attributes are `name`, `type`, `lineno`, and `value`, while the edge attributes are `type` and `condition`.

The fusion procedure is organized around common-node alignment. The paper states that CFG nodes \(V_C\) and DDG nodes \(V_D\) represent complete code statements, and that these identifiers maintain correspondence with their AST counterparts. The aligned identifiers are extracted as fusion anchors, described as “\(V_{common} \cup V_A \to V\).” This means AST provides the anchor space for the final graph, while CFG and DDG semantics are attached through statement-level correspondences [2508.13092].

Before fusion, the AST is restructured. The paper says that it preprocesses the AST by breaking the AST edges between common nodes, “\(e_A\in E_A, e_A=(v_{common}^i,v_{common}^j) \to e_A=\varnothing\),” and decomposing the AST into multiple syntax subtrees rooted at the identified common nodes. In effect, AST edges between certain common nodes are removed so that the syntax can be segmented into subtrees corresponding to CFG/DDG statement nodes.

Semantic enrichment is then performed by mapping CFG and DDG edges onto the corresponding common nodes. The paper states: “\(\exists v_{common}^i\in v_C^i,\exists v_{common}^j\in v_C^j,e_C=(v_C^i,v_C^j)\to e_C=(v_{common}^i,v_{common}^j)\), similarly \(e_D=(v_{common}^m,v_{common}^n)\).” In operational terms, a CFG edge between two control statements becomes an edge between their corresponding common AST anchor nodes, and the same remapping is applied to DDG edges.

The resulting VeriPG is therefore a single directed property graph whose nodes are syntactic anchors enriched with AST structure, and whose edges include syntax, control-flow, and data-dependency relations. This suggests that VeriPG is designed to support traversals that move continuously from local syntax into execution semantics and signal semantics without changing representations.

## 4. Rule generation from CWE descriptions

VeriPG is tightly coupled to a validation-based rule generation pipeline in VerilogLAVD. The paper states: “We first extract the vulnerability conditions from the CWE descriptions by LLMs.” The extraction uses a CoT-based approach that identifies vulnerability manifestations and root causes, which are then transformed into formal conditions for detection [2508.13092].

Instead of asking the LLM to inspect code directly, the system asks it to produce traversal rules over VeriPG. The rule language is built from a small set of traversal primitives. These include generic graph traversal primitives such as DFS, BFS, and traversal along AST edges; Boolean operations such as `AND` and `OR`; and VeriPG-specific traversal primitives including direct indexing of critical syntax nodes, control-aware traversals, and dataflow-aware traversals [2508.13092].

Two primitive examples are explicitly described. The node primitive is
\[
\text{Node}(t)=\{n|V^A_{type}(n)=t \},
\]
which returns all nodes whose `type` equals \(t\). The branch primitive is described as returning all nodes reachable from an `IfStatement` node along CFG edges. Together, these examples show that the rule language mixes attribute predicates on syntax nodes with edge-typed reachability over control structure [2508.13092].

The detection rules are built from three components: Functions, Filters, and Paths. Functions encapsulate basic traversal operations with parameters and result filters. Filters apply Boolean logic through `AND` and `OR`. Paths represent sequential chains where the output of one Function feeds the next. The rules are stored in JSON format. A plausible implication is that the representation is intended to be machine-checkable and executable rather than free-form natural language.

## 5. Execution and rule validation

The rule executor consumes the VeriPG graph and the validated vulnerability rules, then traverses the graph to search for patterns matching vulnerability conditions. Its architecture has three components: Primitive Executor, Filter Executor, and Path Executor [2508.13092].

The Primitive Executor is the core entry point. It resolves arguments of a rule, invokes the corresponding traversal primitives, and applies filters to results. The Filter Executor evaluates Boolean conditions and combines intermediate results from nested Functions or Paths. The Path Executor interprets sequential traversal chains and manages step-by-step execution along the graph.

The traversal process is described at a high level as follows: the executor starts from a rule-specified node or node type, applies a sequence of traversal primitives, follows the correct edge types—AST, CFG, and DDG—and checks whether the resulting subgraph or path satisfies the vulnerability condition [2508.13092].

The paper’s case study of CWE-1280 illustrates how semantic traversal operates. The executor uses a `Variable` primitive to collect all signals, filters the relevant ones, traverses from each signal to its usage via `LoadStatement` along DDG edges, moves to the corresponding blocking assignment using `AssignStatement`, and applies `Exist` to determine whether the vulnerable pattern exists. This example is used to show that VeriPG is actively traversed semantically rather than functioning as passive structural metadata [2508.13092].

Before execution, generated rules are validated using a finite state machine built from VeriPG structure. In that mechanism, VeriPG nodes are treated as states, graph connections are state transitions, validation begins at a common node chosen by the LLM, traversal primitives drive transitions, invalid transitions are stopped immediately, and all possible branches are tracked when multiple valid transitions exist. The stated purpose is to prevent malformed traversal logic from being executed [2508.13092].

## 6. Empirical behavior and reported effects

The empirical evaluation in VerilogLAVD uses a dataset collected from open-source repositories and synthesized data. On 77 Verilog designs encompassing 12 CWE types, VerilogLAVD achieves an F1-score of 0.54 and improves F1-score by 0.31 over the LLM-only baseline and by 0.27 over the LLM with external knowledge baseline. The abstract also reports 69.49% recall [2508.13092].

The paper further reports per-system totals for two VeriPG-based configurations. A DeepSeek-V3 + VeriPG-based system reaches Precision 40.21, Recall 66.10, and F1 0.50. A GPT-4o + VeriPG-based system reaches Precision 47.25, Recall 72.88, and F1 0.57. Both are stated to outperform their LLM+knowledge counterparts [2508.13092].

A central ablation concerns traversal primitive misuse and the effect of rule validation.

| Method | IPTR | IPMR |
|---|---:|---:|
| LLM+Knowledge | 27.04 | 13.83 |
| VerilogLAVD (w/o PV) | 23.96 | 12.88 |
| VerilogLAVD (with PV) | 3.49 | 6.61 |

The accompanying totals in the source are 40.87 for LLM+Knowledge, 36.84 for VerilogLAVD (w/o PV), and 10.10 for VerilogLAVD (with PV). The paper highlights that the illegal rule rate is reduced to 3.49% and that total misuse is reduced from 40.87% to 10.10% [2508.13092]. This suggests that the benefits of VeriPG are partly representational and partly procedural: the graph enables not only traversal-based detection, but also structural validation of generated rules.

The reported efficiency results indicate that execution time does not clearly increase with code length. Instead, the number of traversal primitives is more closely related to runtime than line count, and long files can even be faster if irrelevant code is ignored. The CWE-1280 case study is presented as confirming that data dependencies, control flow, and syntax anchors are jointly necessary. The paper uses this to support the claim that semantic graph structure enables vulnerabilities to be detected in a way raw text or AST-only methods cannot reliably do [2508.13092].

## 7. Relation to adjacent RTL graph and Verilog-representation work

VeriPG should be distinguished from other graph-oriented and Verilog-oriented representations in contemporary RTL research. Verilog-to-PyG (V2PYG) is an open-source framework that translates RTL designs into graph representation foundations that can be integrated with PyTorch Geometric, supports label generation via open EDA flows, and provides functional augmentation that preserves design equivalence. In the summary provided for that work, V2PYG can be understood as constructing a graph where RTL entities become nodes, connectivity becomes edges, and node annotations carry properties such as gate type, inverter polarity, or technology-mapped cell identity [2311.05722].

The relationship, however, is not identity. V2PYG is described around technology-independent Boolean networks such as AIGs and around technology-dependent mapped netlists, with graph extraction yielding structural information in the edgelist and initial functional embeddings for graph learning tasks. By contrast, VeriPG is introduced specifically as a unified Verilog property graph that merges AST syntax, CFG control flow, and DDG data dependencies using common AST-aligned nodes as fusion anchors. This suggests that V2PYG is closer to an RTL/netlist graph-learning substrate, whereas VeriPG is a source-level semantic program graph for traversal-based vulnerability detection [2311.05722; 2508.13092].

A second point of contrast comes from VeriLoC, which is explicitly positioned against intermediate graph representations for hardware design-quality prediction. VeriLoC leverages CL-Verilog embeddings for line-level and module-level prediction of timing and routing congestion, and the summary states that it does not construct a Verilog property graph, control-flow graph, data-flow graph, or any explicit program graph. Its context mechanism is purely sequential line concatenation rather than graph traversal or property-graph propagation [2506.07239].

Taken together, these comparisons delimit the role of VeriPG. It is neither a Boolean-network graph extraction framework in the style of V2PYG nor a purely embedding-based representation learning approach in the style of VeriLoC. Instead, it is a Verilog-specific property graph designed so that LLM-generated rules can traverse syntax, control flow, and data dependencies in a single directed property graph [2508.13092]. A plausible implication is that VeriPG occupies the portion of the design space where explicit, typed semantic relations are required for rule-driven reasoning about RTL vulnerabilities.

Source: https://www.emergentmind.com/topics/verilog-property-graph-veripg