SymRTLO: Enhancing RTL Code Optimization with LLMs and Neuron-Inspired Symbolic Reasoning
Authors: Yiting Wang
Wanghao Ye
Ping Guo
Yexiao He
Ziyao Wang
Bowei Tian
Shwai He
Guoheng Sun
Zheyu Shen
Sihan Chen
Ankur Srivastava
Qingfu Zhang
Gang Qu
Ang Li
Venue: NeurIPS 2025 poster ()
Keywords: RTL Optimization
Neuron-Symbolic
Electronic Design Automation
Primary area: applications
TL;DR: SymRTLO is a state-of-the-art neuron-symbolic RTL optimizer that combines LLM-based rewriting, symbolic reasoning, and fast verification to achieve up to 48% lower power, 91% faster timing, and 47% reduced area.

Abstract: Optimizing Register Transfer Level (RTL) code is crucial for improving the efficiency and performance of digital circuits in the early stages of synthesis. Manual rewriting, guided by synthesis feedback, can yield high-quality results but is time-consuming and error-prone. Most existing compiler-based approaches have difficulty handling complex design constraints. Large Language Model (LLM)-based methods have emerged as a promising alternative to address these challenges. However, LLM-based approaches often face difficulties in ensuring alignment between the generated code and the provided prompts. This paper introduces SymRTLO, a neuron-symbolic framework that integrates LLMs with symbolic reasoning for the efficient and effective optimization of RTL code. Our method incorporates a retrieval-augmented system of optimization rules and Abstract Syntax Tree (AST)-based templates, enabling LLM-based rewriting that maintains syntactic correctness while minimizing undesired circuit behaviors. A symbolic module is proposed for analyzing and optimizing finite state machine (FSM) logic, allowing fine-grained state merging and partial specification handling beyond the scope of pattern-based compilers. Furthermore, a fast verification pipeline, combining formal equivalence checks with test-driven validation, further reduces the complexity of verification. Experiments on the RTL-Rewriter benchmark with Synopsys Design Compiler and Yosys show that SymRTLO improves power, performance, and area (PPA) by up to 43.9%, 62.5%, and 51.1%, respectively, compared to the state-of-the-art methods. We will release the code as open source upon the paper's acceptance.

SymRTLO: Enhancing RTL Code Optimization with LLMs and Neuron-Inspired Symbolic Reasoning
Yiting Wang
Wanghao Ye!.*
Ping Guo 2.
Yexiao Hel-*
Ziyao Wang'
Bowei Tian
Shwai He! Guoheng Sun
Zheyu Shen
Sihan Chen
Ankur Srivastava' Qingfu Zhang² Gang Qu' Ang Li
University of Maryland (ywang144, wy891, yexiaohe, angliece) edu
"City University Hong Kong University of Southern California
pingguo5-cGmy cityu.edu.uui edu.
Abstract
Optimizing Register Transfer Level (RTL) code crucial for improving the effi- ciency and performance of digital circuits in the early stages of synthesis. Man- ual rewriting, guided by synthesis feedback, can yield high-quality results but is time-consuming and error-prone. Most existing compiler-based approaches have difficulty handling complex design constraints. Large Language Model (LLM)-based methods have emerged as promising alternative to address these challenges. However, LLM-based approaches often face difficulties in ensuring alignment between the generated code and the provided prompts. This paper introduces SymRTLO, a neuron- symuooi-yymooiic framework that integrates LLMs with symbolic reasoning for the efficient and effective optimization of RTL code. Our method incorporates a retrieval-augmennt stract Syntax Tree (AST))baaed templates, enabling I.L.-based rewriting that maintains syntactic correctness while minimizing undesired circuit behaviors. A symbolic module is proposed for analyzing and optimizing finite state machine (FSM) logic, allowing fine-grained state merging and partial specification handling efficient verifica-
system of optimization rules and Ab-
beyond the scope of pattern-based compilers. Furthermore, tion pipeline, combining formal equivalence checks with test-driven validation, further reduces the complexity of verification. Experiments on the RTL-Rewriter benchmark with Synopsys Design Compiler and Yosys show that SymRTLO im- proves power, performance, and area (PPA) by up to 43.9%, 62.5%, and 51. %, respectively, compared to the state-of-the-art methods. Our code is available at https::/gitta com Htt/NNeelyyyyyylm
1 Introduction
Register Transfer Level (RTI.) optimization is a cornerstone of modern circuit design flows, serving as the foundation for achieving optimal Power, Performance, and Area (PPA). As the earliest phase in the hardware design lifecycle, RTL development provides engineers with the most significant degree of flexibility to explore design patterns, make architectural trade-offs, and influence the overall design quality [ Engineers use hardware description languages (HDLs) like Verilog to describe circuit functionality. At this stage, decisions made have far-reaching implications, as the quality of the RTL implementation directly impacts subsequent stages, including synthesis, placement, and routing [40] well-optimized RTL not only ensures better design outcomes but also prevents suboptimal designs from propagating through the flow, leading to significant inefficiencies and costly iterations
[3 49
'Equal contribution Corresponding author
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

Despite its importance, RTL optimization remains a challenging and inter-intensive task. Engineers must iteratively refine their designs through multiple rounds of synthesis and layout feedback to ensure functionality and meet stringent PPA targets. This process becomes increasingly cumbersome as design complexity grows, with synthesis times scaling disproportionately. often taking hours or even days for single iteration [3]. Consequently, designers frequently face numerous synthesis cycles to evaluate trade-off's and reach acceptaale results. While modern electronic design automation (EDA) tools provide compiler-based methods to aid optimization, these approaches are inherently limited H6. They rely heavily on predefined heuristics, making them ill-suited for adapting to unconventional design patterns, complex constraints, or dynamic optimization scenarios. As result, the RTL optimization process demands significant expertise and effort.
Recent advances in artificial intelligence, particularly the advent of large language models (LLMs). have introduced a new paradigm for automating and optimizing RTI. code [23] 25
5 1 37 15
46
41 16 26). Leveraging the powerful generative capabilities of L.Mss, researchers have demonstrated their potential to rewrite and optimize Verilog code automatically [46]. However, existing LLM-based approaches face critical challenges that limit their effectiivneess. First, these models often fail to align their generated outputs with specified optimization objectives. The inherent limitations in logical reasoning within LLMs can lead to deviations from intended transformations, resulting in suboptimal or incorrect outputs. Second, despite their potential for automating code generation, current methods still heavily rely traditional synthesis feedback loops for optimization. This reliance results in the inefficiencies of the synthesis process, failing to address the core issue of long design cycles.
14
42
Our Proposed Framework. To address the critical challenges in RTL optimization, we introduce SymRTLO, the first neuron-symbolic system that seamlessly integrates LLMs with symbolic reason- ing to optimize RTL code. SymRTLO significantly reduces the reliance on repeated synthesis tool invocations and enhances the alignment of LLM generated results with intended optimization rules.
Designing such a system introduces significant challenges, which we address through the integration of carefully designed modules. The first challenge lies in the generalization of optimization rules. Traditionally, optimization patterns are scattered across code samples, books, and informal notes, making it difficult for compiler- methods to formalize apply them effectively. SymRTLO tackles this by employing an LLM-based rule extraction system, combined with a retrieval- retrieva--augmented generation (RAG) mechanism and search engine. This ensures that optimization rules are not only generalized but also efficiently retrievable from a robust library built from diverse sources.
Another critical challenge is the alignment of LLM-generated RTL code with the intended transfor- mations, as L.MSs often struggle to produce outputs that strictly adhere to the specified optimization objective, leading to unreliable and unexplainable results. To ensure alignment, SymRTLO employs Abstract Syntax Tree (AST)-based templates, which guide the L.MM to generate code that satisfies syntactic and semantic correctness. For complex control flows or edge cases that exceed the capabili- ties of AST templates, the framework utilizes a symbolic generation module, designed to handle such scenarios dynamically while maintaining optimization quality.
In addition to alignment, conflicts often arise when different design patterns are required to meet distinct PPA goals. To address this, SymRTLO introduces a goal-oriented approach, where each optimization rule is explicitly tied to its intended objective. This enables selective application based on user-defined optimization goals, efficiently balancing these conflicts to deliver optimized designs without disproportionately compromising PPA metrics.
Verificaation in traditional RTL. workflows demands significant manual effort for test case development. To address this, SymRTLO integrates an automated test case generator, streamlining verification while ensuring functional correctness.
Our key contributions are summarized as follows:
SymRTLO, the first framework to combine LLM-bbsed rewriting with symbolic reasoning for RTL optimization.
LLM Symbolic Optimization:
Data Path and Control Path Optimization: SymRTLO addresses critical challenges in both traditional EDA compilers and purely LL.M-based approaches, particularly by aligning generated code with FSM and data path algorithms, balancing conflicting optimization rules, and improving explainability.
2

---

PPA Improvements: SymRTLO demonstrates its efficacy industrial-scit and benchmark circuits, surpassing manual coding, classical compiler flows (e.g.. Synopsys DC Com- piler), and state-of-the-an L.LM-based methods, achieving up to 43.9%, 62.5%, and 51.1% % improvement power, delay, and area.
2
Background and Motivation
LLMs have emerged as powerful tools for RTI. design automation, with various approaches being developed since 2023. As summarized in Table [ these approaches fall into three primary categories:
RTL code generation 23 25 I debugging 15], and optimization [46]. This growing body of research demonstrates the significant potential of LLMs to improve the efficiency and effectiveness of EDA workflows. However, RTL code optimization has always been a significant challenge RTL design, even for human experts, as it has the greatest impact the performance of downstream tasks.
Challenges in RTL Code Optimization with LLMs. Aligning generated code with intended opti- mization goals is a major challenge in LLM-based RTL optimization. Due to inherent randomness, LLMs often produce incomplete, incorrect, or suboptimal results. For example, RTLRewriter [46] employs setrivall-augment correctness but still struggles with fundamental misalignment between generated code and opti- mization objectives. Additionally, the need for multiple synthesis rounds significantly increases optimization time as design complexity increases, limiting the scalability of current L.L.-based methods for large industrial-scale designs. Current Approaches: Underutilization of Knowledge and Manual Verification. Traditional RTL design optimization relies on established patterns such as subexpres- sion elimination
prompts and iterative wynthesis-feddaae loops to enhance functional
Table 1: Comparative analysis of LLM--bseed methods for RTL design. V indicates the presence of the feature, x indicates absence the feature, and indicates non- applicable.
dead code elim- ination (20, [7]. strength reduction [T0] algebraic simplification 3,4 4 Mux reduc- tion 66 43, and memory sharing (7]. While these techniques are effective, these optimizations typically operate at the gate- level netlist, making the relationship be- tween optimized output and original RTL code less transparent. Additionally, opti- mization patterss from design manuals and codebases remain underutilized due to the lack of centralized repository, forcing gineers to rely on their expertise rather than automated tools. Furthermore, verification requires the creation of test benches and test cases manually, making the RTL design flow both time-consuming and error-prone.
Category
Method
Verification Capability
Rule -Based
Output Alignment Resolution
Conflict
ChipNeMo
x
x
VeriGon 36
VerilogEival 24
X
X
Generation
KTLCoder 25
ChipChat
X
ChipGPT 5
X
X
Debug
RTLFixer
37
V
X
X
LLM45ecHW
X
Optimization
RTl.eeriier
46
X
X
SynRTLD (Ours)
Optimization Conflicts and Limited Compiler Capabilities. Existing compiler-base based methods face additional challenges, particularly in managing optimization goal confficts and handling complex patterns. For instance, optimizing for one metric, such as delay, often conflicts with another, such power consumption. Striking the right balance between these competing objectives is crucial, especially as trade-offs between power and delay directly impact overall system performance. As shown in Table each optimization method has its specific goal, which often clashes with others. Compiler-basee methods also lack the flexibility to adapt to such conflicts, limiting their effectiveness in optimizing designs with diverse and competing constraints.
Table 3: Performance Comparison Across Dif- ferent Approaches.
Table Conflicts Between Design Goals Op-
timization Patterns.
Approach il States
Time (ns)
Power (mW)
Area (jum²
Design Pattern
Goal
Conflict Goal
Conffict Design Pattern
Pipelining
Timing
Resource Sharing
Baseline
0.041
2.250
833.000
Clock Gating
Low Power
Low Timing
Rotiming
GPT-01
10
0.041
2.280
993,480
Optimized
0.025
1.170
403.920
Advancing LLM-bbased RTL Optimization with Neuron-Symbolic Integration. Recent research
has shown growing trend toward combining symbolic reasoning with LLM [45] 39
7
12

---

RAC
Flow Optimization
IF not Cunctional eguivalent
? Code
Books
Rtte decrtytions
AS1 Tumplates Desctjctio
Template Writing
Instesctions
WAST Opsimization Templase Modale
Opiimized Code
AST bourd
Equitalere
Check
O Manual
Seanch Englnee
Optimization
Rule Search Resalts
Input Code
Libray
Final Opeimiraation
FLLM Optimizse
Optinstaed
Eiqutsalence
Input
Diepaecher
Codt
Check
Flow Optimization
Symbolic Repessentation
Daymbolic
Optimized Symbelic Results
Equiveliace Check
I:: net Eunctional equivalent
icoomeedds Coutrol
Piazi Output Code
Optimitation
Feattional Squivallnn
Figure 1: SymRTLO Architecture.
bringing new inspirations for more efficient and reliable LLM-based RTL code optimization with better prompt-code alignment. These integrated approaches have seen broad application across various fields. from automated theorem proof and knowledge representation to robotics and medical diagnostics, demonstrating how the combination of pattern recognition and generative capabilities of LLM with the interpretability and logical rigor of symbolic systems can significantly improve the alignment between LLM output and the given prompt.
Motivation Experiments. To highlight the limitations of current LLM-based RTL optimization, we conduct experiment using of-te-of-the-ar commercial LLM, GPT-O1, to optimize an 11-ttaee FSM design. The goal was to minimize and merge unnecessary states to enhance PPA metrics. GPT-O1 receives detailed state reduction algorithm guide the optimization process. We compare its results with an optimized design that directly applied the state reduction algorithm. As shown in Table 3 GPT-O1 struggles align its outputs with the algorithm, resulting an under-optimized FSM with little state reduction and degradation in PPA. Although GPT-OI achieves some state reduction, it fails to consider switching activity minimization and efficient state encoding, resulting poor code choices that increase Hamming distances between frequently transitioning states and generate more complex combinational logic [48]. In contrast, sygorithm-driver optimization achieves significantly better results, highlighting current LLM limitations in complex RTL optimization tasks.
3 Methodology
SymRTLO takes a Verilog RTL module as input and optimizes it for specific design goals, such as low power, high performance, or reduced area. As illustrated in Figure I the workflow begins by entering the RTL code and the user-specified optimization goal ()) into the LLM Dispatcher (2)
This dispatcher analyzes the input circuit and determines the appropriate optimization path: either proceeding solely with Data Flow Optimization ($2.)) incorporating Control Flow Optimization ($3.3) as well, depending on the characteristics of the design. For Data Flow Optimization, a search engine with serieval-auumentee module extracts optimization rules and constructs AST-based templates. For Control Flow Optimization, an LLM--diven symbolic system generator performs FSM-specific transformations. Finally, the Final Optimization Module ($3.4) integrates both paths and incorporates a verification system to ensure the functional correctness of the optimized design.
3.1
LLM Dispatcher
The LLM Dispatcher
(2) receives the input RTL code and the specified optimization goal (e.g.. low power) ( before any optimization begins. It first summarizes the code and generates potential optimization suggestions. These suggestions are then passed the Retrieval-Augmenner Generation (RAG) system to identify the relevant optimization rules. Additionally, the Dispatcher evaluates the presence of Finite State Machine (FSM) in the original code to determine whether control flow optimization is necessary.
3.2 Data Flow Optimization
Data Flow represents the process by which information is propagated, processed, and optimized within an RTI. design. Efffective data flow optimizations improve system efficiency by simplifying computations, reducing redundancy, and enhancing PPA metrics. Common techniques include sub-

---

expression elimination, constant folding, and resource sharing. The proposed Data Flow Optimization Module addresses three key challenges: (I) generalizing diverse optimization patterns into accurate, reusable rules; (2) aligning L.L.--eeerated optimizations with functional and logical requirements; and (3) resolving conflicts between optimization goals inherent in distinct design patterns.
Optimization Rule Search Engine Optimization knowledge is often scattered across books, lecture notes, codebases, and design manuals, with no generalized repository to serve as a unified knowledge base. Furthermore, optimization patterns frequently confficr due to divergent goals, for example, power reduction versus performance improvement. To tackle these challenges, we developed a cettrevallaugmeette generation (RAG) system equipped with an optimization goal-based rule extraction module.
Optimization Library. The RAG system aggregates raw RTL optimization data from sources such as lecture notes, manuals, and example designs 388 35
32 30 into a comprehensive knowledge base
) LLMs then summarize and structure these data into optimization library (4). Each rule is abstracted to include its description. applicable optimization goals (e.g., area, power, or timing), and its category (e.g.. data flow, FSM. MUX, memory, or clock gating). A similarity engine identifies overlaps with existing entries, prompting merges or exclusive labels to ensure the scalability of the rule library. To align optimization goals with generated outputs, the rules specify detailed instructions for constructing AST templates, enabling precise application of optimization patterns. Rules with clearly defined requirements include template-wrie writing guidelines, while more abstract rules are stored as descriptive text and used directly as optimization prompts. See Appendix Cl example RAG.
Enforcing Rule Alignment and Resolving Conflicts To improve the structure and alignment of optimization rules, the LLM Dispatcher (1) provides both summary of the input RTL code and suggestions for potential optimizations. These inputs are passed to the search engine along with user-specified optimization goals, performing a similarity search to identify the most relevant rules from the RAG system.
Given the potential for conflicts between optimization goals, it is critical to prevent the inclusion of conflicting rules while ensuring no critical optimizations are overlooked. To achieve this balance, we employ the elbow method to analyze the similarity scores between the query and the candidate rules. This approach identifies a natural cutoff point where adding more rules no longer yields significant benefits. Let the similarity scores between the query and candidate rules be ordered as: 81 2 82 2- 2 SM, where denotes the similarity score for i-th rule, ordered from highest to lowest, and M is the total number of candidates.
The optimal cutoff index i* is determined by maximizing the difference between consecutive similarity scores: i* = arg max, (s: 8141).
13K
Rules with similarity scores above the threshold Telbow are selected for application. The similarity between the query embedding (Cquery) and the rule embedding (Crute) is computed as shown below:
Equery
erule
sim sim(equery emlee
2
Telhow-
Equery
|ruiel
This method ensures that only the most relevant rules are selected, striking an optimal balance between comprehensiveness and precision. The output of the search engine contains two components: and abstract rules described only by their
rules with detailed template-writing instructions (7) optimization properties (6)
AST Template Building To ensure that LLM-generated RTL code aligns with functional and logical optimization goals, we enforce rules using AST-based symbolic systems, which have been proven to be effective in hardware debugging [37] Compared to -.M--eeeertted symbolic systems, AST-based templates offer several advantages: (1) parsing Verilog into an AST ensures accurate and structured design representations; (2) limiting each template to a single optimization goal maintains conciseness, facilitating correct generation and application by LLMs; and (3) the modular approach allows selection of templates to balance conflicting optimization patterns, enhancing flexibility.
For rules that include template-writing instructions, we prompt the LLM to generate an AST-based template that serves as general optimization framework (8) Let A denote the set of all AST
5

---

nodes in the Verilog design, and let the matching condition: Φb A + ftrue, false), determine whether a node qualifies for optimization. The process begins by identifying the Target Node Type, such as Always, Instance, Assign or Module Instantiation For each node of the specified type, we apply + to decide whether requires rewriting. Once the target nodes are identified, the Transformation Rule is applied as follows: T {a E A ((a) = true) -+ A, where T replaces the matched node with an optimized AST subtree (e.g., merging nested if else statements, folding constants, simplifying expressions; code example see Appendix (B). To ensure functional correctness, the transformed design undergoes an equivalence check using LLM-generated testbenches. If the template passes verification, it is stored in the RAG system reusable content.
As shown in Figure the RTL design is initially interpreted as an AST representation. The RAG system provides the L.LM with multiple template options. Due to the varying optimization goals and scenarios, the system avoids relying on fixed sequence of templates. Instead, the LLM determines which templates to apply and in what order, tailoring the optimization process to the design's 's specific requirements. To further pre- vent conflicts between templates failures in the symbolic system, we introduce a feedback loop. This loop allows the LLM to re-select templates and adjust its strategy based on prior failures, ensuring robustness and adaptability.
AST Construction
RTL Design
Pyceillgg
APMIT
CBV
TEG
XAG syatem
Templates
falespmnian reaooul
Yomplix
Sdlctad
Doad cade diriination
NiThael Optrimbook
Cosical Puth edlccios
Frelhack Jucy Be sileet fatiel symtbodie oue
Figure 2: SymRTLO AST template optimization workflow.
3.3 Control Flow Optimization
Control Flow, unlike Data Flow's 's focus on how information is processed and propagated, defines the execution paths and sequencing of operations in RTI. designs through finite-state machines (FSMs) that capture states, transitions, and outputs. These FSMs are tightly coupled with design constraints (i.e., partial specifications, clock gating, and reset logic), making generic symbolic systems fragile incomplete. Addressing these challenges requires deeper semantic analysis beyond simple pattern matching or generic AST templates. To enhance alignment between optimized code and the FSM minimization algorithm, we propose a Control Flow Optimization module utilizing an LLM-based symbolic system. An FSM can be formally represented as: M = (Q, Σ, 6, qo, F), where Q is the finite set of states, Σ is the input alphabet, 8 : Q x Σ + Q is the transition function, E Q is the initial state, and F S Q is the set of accepting states.
For a partially specified FSM Mp. the transition function is extended to handle non-deterministic transitions: o, : Q x Σ + 29, where 29 represents the power set of Q.
Classical minimization algorithms (e.g.. Hoperoft's 's 18 or Moore's 28) are effective for completely specified FSMs but are limited by real-world complexities. Practical RTL designs often integrate control logic with data path constraints, and undefined states and transitions make FSM minimization an Nomcleplete problem with a general complexity of ( ). A single pre-b AST script cannot efficiently handle all such incomplete specifications. Let d : Q x D + represent the data path constraints, where D is the data path state space and B is the boolean domain. Pure FSM-focused AST-baasd optimization scripts can overlook these data path side effects, failing to capture deeper control semantics.
Inspired by [1), we propose leveraging LLMS to transform each circuit into a symbolic repre- sentation focused solely on FSM components, i.e., isolating states, transitions, and relevant out- puts, as illustrated in Figure 3 Instead of re- lying on a one-size-fits--l script, we prompt the LLM dynamically generate a special- ized minimization script tailored to the spe- cific FSM structure and constraints. We show an example workflow in Appendix
Tranelommrd Syathelic Repromtttion
Optiniited Sprehsile Reperurabutio
Theasber
Spmbaie
Figure 3: SymRTLO FSM optimization workflow.

---

3.4 Verification and Final Optimization
To address the challenges of manual verification and unreliable automated methods, we introduce an automated verification module that integrates functionality testing and formal equivalence checking. After AST-based optimization and the LLM-assisted symbolic system generate initial results, the I.LM combines extracted rules, template-optimizzed code, and symbolic outputs to produce the final
optimized RTL design (11) Verification is essential to ensure correctness, as LLL--genertted rewrites may introduce unintended behavioral deviations. We employ two-step verification pipeline: (1) the LLM generates test benches validate basic functional correctness, acting as a rapid filter to reject invalid rewrites early; and (2) for designs that pass initial tests, we perform formal equivalence checking to formally confirm functional equivalence to the original design. For combinational logic and straightforward synchronous sequential circuits, we apply standard Boolean Satisfiability Problem (SAT)- equivalence checking. While more complex designs like asynchronous resets, CDC paths, retimed logic, we employ advanced sequential equivalence checking with robust state matching and translormation-tollraatt verification techniques.
Experiments
4.1 Experimental Setup
Baseline We compare SymRTLO with several state-of-the-art LLM and open source RTL optimiza- tion frameworks. The LLM baselines include GPT-O1, GPT-4o, GPT-4 [2]], GPT-3.5(47), and GPT-4o-mini. Additionally. we include two specialized open-source -asedd tools: Verigen 36 and RTI--Coder- Deeese-- (25). For a comprehensive evaluation, we analyze SymRTLO perfor- mance using circuits from the RTT Rewriter Benchmark. Although the Rewritee environment is reproducible using Yosys 44 for wires and cells analysis, the exact test case they use is not provided. Moreover, comparing PPA results is even more challenging due to its reliance on Yosys + ABC with unknown libraries. To demonstrate SymRTLO's capabilities, we subject it to a broader evaluation scope, selecting examples that are diverse in size and functionality, while including cases reported in RTLRewriter's benchmark for direct comparison.
The SymRTLO framework takes GPT-4o as its primary LLM for optimization strategy selection, symbolic system generation, and iterative HDL synthesis, leveraging its robust inference, low inference cost, and coding capabilities. While the framework is model-agnostic by design, alternatives like GPT-3.5 and GPT-O1 were excluded after preliminary tests showed poor results GPT-3.5 lacked sufficient coding capability, and GPT-O1 incurred high latency and API costs, reducing overall efficiency. Pyverilog [34] is used for AST extraction and code reconstruction.
Implementations
To efficiently retrieve relevant transformation templates and knowledge, we integrate OpenAl's text embedding-3-small, which excels in embedding-based retrieval tasks. For hardware compilation and validation, we use combination of open-source and commercial tools. Yosys measures wires and cells, while Synopsys DC Compiler 2019 333, paired with the Synopsys Standard Cell (SSC) library. performs PPA analysis. GPT-40 generates test benches for functional coverage. Yosys + ABC serves as the logical equivalence checker, while Synopsys Formality for sequential equivalence checking. For fair comparison with standard compiler workflows, we apply typical Synopsys DC Compiler optimizations, using medium mapping effort and incremental mapping reflect common practices.
Evaluation Metries First, to evaluate generation quality and functional correctness, we use the pass@k k metric commonly employed in code generation tasks. This metric captures the probability
that at least one valid solution exists within the top k generations: pass@k = N Σn Cry )
C%
where N is the number of problems, n; and c; represent the total and correct samples for the i-th problem, respectively. Second, to test the performance of the synthesis results, we use the best results of the 10 valid generations of each model and our method. This sampling maintains token budget fairness, as SymRTLO with GPT-4o averages 7,728 tokens across all circuits, while the base GPT-4o model uses approximately 775 tokens per generation a 10x difference.
For smaller benchmarks, we evaluate optimization results using Wires and Cells metrics, which reflect low-level physical characteristies of circuits. These metrics provide granular insights into routing complexity (wires) and logical component count (cells), offering precise evaluation for isolated modules or blocks. For larger designs, we focus on PPA metries to capture high-level efficiency and real-world applicability. These metrics offer holistic view of resource usage and performance for complex designs, where low-level metrics like Wires and Cells become impractical.
7

---

Table 5: Comparison of Wire and Cell Counts. Yellow highlighting denotes state-of-the- results. GeoMean the geometric mean of the resource usage (wires or cells). Ratios are calculated by dividing the GeoMean by the baseline's ' resource usage. t: Reported Results from [46]
Benchmark
Youys Wires
Gurb4-Turbo
GPT-4o
GPr- GPT-4o-mini RTI.Coder-DS RTLrewriter
SyeRTLO
Cells
Wires
Cells
Wires
Cells
Wires
Cells
Wires
Cells
Wires
Cells
Wires Cells
Wires Cells
adder swseespeesssinnn
8
3
3
7
3
7
3
3
3
7
3
adder architecture
40
30
40
56
56
14
16
muliiplier_shhes subexpe
26
71
18
15
259
255
26
71
26
71
71
18
15
constant_ folding. row
12
6
10
5
10
5
10
5
10
5
12
6
8
5
sabexpression elim
17
12
19
12
19
12
19
12
17
10
12
14
8
alu, subexpression
24
22
18
adder resouree
13
3
9
4
3
3
multiplier_biveee bitwidth
9
3
3
8
3
9
9
3
3
8
3
multiplicr_schiieect
4
2
36
4
2
16
20
18
36
2
adder bit width
sap_iiling_raw
16
16
16
16
484
496
16
16
GeoMean
15,49
8.96
13:45
9.81
16.35
9.97
16.40
11,49
16.31
11,49
15.49
8.96
9.75
5,95
Ratio
1.00
1.00
0.87
1.10
1.06
1.11
1.06
1.28
1.11
1.31
1.15
0.91
0.69
0,771!
0.63
0.67
Table 6: FSM Designs PPA Comparison. Yellow highlights indicate state-of-the-art results. A 4
marks improvement, while a ft denotes a decline compare with the original design. Two compari- son scenarios are shown: without compiler optimization (upper improvement) and with compiler optimization (lower improvement). A indicates that no code is available for analysis.
ModeVMethod
examplel_ster state
example2 state
example3 state
example4_ state
example5_sta state
Power
Time
Aren
Power
Time
Area
Power
Time
Area
Power
Time
Area
Power Time
Area
(mW)
(nS)
(um²)
(mW)
(os)
(um²)
(mW)
(ns)
(jom")
(mW)
(96)
(jm²)
(mW)
(ns)
(ym²)
Original
0.042
1.21
833.0
0.056
2:25
549.4
0.052
1.35
589.6
0.055
2.18
597.1
0.055
2.18
597.1
GPT-3.5
0.043
1.27
870.6
0.056
2.25
549.4
0.052
1,35
589.6
0.059
2.17
972.3
0.055
2.18
597.1
GPT4o-mini
0.055
1.08
1021.1
0.062
2.23
579.2
0.063
1.08
714.9
0.055
2.18
597.1
0.053
2.18
634.7
GPr-4-Turbo
0.053
2.97
993.5
0.067
2.28
737.6
0.065
1,22
810.3
0.055
2.18
273.5
0.029
2.25
366.8
GPT-4o
0.053
2.97
1002.5
0.056
2.25
$49.4
0.052
1.35
589.6
0.055
2.18
273,5
0.055
2.18
597.1
GPT-01
0.044
1.17
910.7
0.056
2.25
549.4
0.052
1.35
589.6
0.055
2.18
597.1
0.055
2.18
597.1
RTLCoder-DS
0.042
1.21
833.0
0.056
2.25
549.4
0.052
1,35
589.6
0.055
2.18
397.1
0.063
2.34
649.78
RTT.ewriter
0.025
3.23
424.0
0.041
1,36
549.4
SymRTL.
0.029
1.21
403.9
0.024
1.17
271.0
0.023
1.15
268.5
0.024
2.17
273.5
0.026
2.18
270.9
Improvement( %)
1,30.5
0.00
U51.51
U.7.114
(.8.00
(:50.67
US5:77
(14.81
(54.46)
(,56.36
(00.46.454.20
U.2.73
4,54.63
Original + Compiler Opt.
0.041
2.85
564.51
0.035
2,24
316.11
0.038
1.23
358.77
0.044
2.19
451.59
0.045
2.19
451.59
SymRTLO Compiler Opt.
0.021
2.64
240.85
0.018
0.6
175.61
0.018
2.42
180.63
0.020
2.17
185.65
0.019
2.27
188.169
Improvement(S) &
[48.78 U7.37 457.33
(48.57
U73.21 444.45
U52.63
199.74
649.65
U.54.55
(0.91
458.89
(.57.78
3.66
4,58.33
4.2 Functional Correctness Analysis
To demonstrate that our method reduces synthesis time and improves functional correctness, Table 4 presents the evaluation results. SymRTLO achieves near-perfect first-attempt pass rates, ensuring valid, optimized RTL code with maintained functional equivalence. This significantly outperforms state- of-the-art language models, particularly given the complexity of RTL optimization tasks and the neces- sity of maintaining functional equivalence. SymRTLO
Table 4: Pass Rate Results.
Method
Pass@
P
Pass 10
Ours
97.5
100.0
100.0
GPT-4o
45.9
60.0
72.7
Turbo-Turo
42.9
62.7
81.8
GPT-to-mini
2.5
10.9
12.7
GPT-3.5 Turbo
28.6
42.7
$4.5
Code- DeepSeek
8.8
18.2
27.3
Verigen-28
0.0
0.0
0.0
Verigen- 16B
0.0
0.0
0.0
reduces synthesis iterations, minimizing redundant computations throughout the optimization process.
4.3 Circuit Optimization Performance
To demonstrate SymRTLO's effective- ness in resolving cross-rule conflicts and achieving optimization objectives. we conduct an experiment presented in Figure 4 Given the limited bench- marks avai lable for LLM--diven RTL design, we analyze our framework on RTLRewriter's is benchmark, which pri- marily emphasizes area optimization, leaving minimal room for improve- ments in power and delay. To align with this limitation, we put area opti-
Power vs Time
Power vs Area
Area vs Time
6094
Power (mW)
Power (m/W)
Area (um-)
102
6.39
Time (ns)
Area (sum?)
Time (ns)
Original
GPT-4-Turbo
RTLCoder GPT-4o-mini
G
SymRTLO
GPT-4o
Figure 4: The PPA overall improvement of benchmark cases.
8

---

Table 7: Algorithm Optimizations PPA Comparison. Yellow highlights indicate state-of-the-an results. A + marks improvement, while a t denotes a decline compare with the original design. Two comparison scenarios are shown: without compiler optimization (upper improvement) and with compiler optimization (lower improvement).
Model/Methed
Sppm redundaney
suhexprosson elim
adder architecture
vending
m
Power
Time
Aren
Power
Time
Area
Power
Time
Aren
Power
Time
Area
Power
Time
Area
(mW)
(nc)
(pam²)
(m/W
(pm²)
(mW)
(ns)
(jm²)
[m/W
(pm²)
(m/)
(um=²
Original
7.41
40102.6
5.27
11.09
10989.1
0.418
2:78
1023.5
227.86
176982.98
2255264,75
GPT-3.5- Turbb
2.86
7.41
40102.6
5.27
11.09
10989
0.418
2.78
1023.5
7.61
227.86
176982
58.23
8.26
2255264.75
GPT4o-mini
2.86
7.41
40102.6
5.27
11.09
10989.1
0.418
2.78
1023.5
7.61
227.86
176982.98
58.23
8.26
2255264.75
Gar-4-Tubb
2.86
7.41
40102.6
3.93
11.09
7783.0
0.392
2.74
1023.5
7.50
227.86
176982.98
58.25
8.26
2255264.75
GPT--o
2,86
7.41
40102.6
5.27
11,09
6984.61
0.392
2.74
1023.5
7.61
227.86
176982
58.23
8:26
2255264.75
GPT-01
1.7
7:41
29919.8
4.63
11,09
9957.23
0,418
2.78
1023.52
227.86
176982.99
8.26
22552664.75
RSLCCddr-DS
40102.6
10989.1
0.418
2.78
1023.5
227.86
176982.98
8.26
2255264.775
SyaRTLO
1.77
7.29
29606.18
3.02
2.87
7358.8
0.328
1.97
762.6
6.97
227.86
164831.1
31.71
8.09
1726125.71
Improvementt %))
0-1.66
4-1.62
0.26.17
[1-12.68
474.12
433.00
(22
(229.199
4,25.09
J8.41
400
06.87
(J45,54
.y2.06
4,23.46
Original Campiler Opt.
7.95
22908.69
69)
4.61
11.78
9484 15
0.17
2.29
541.92
92
11.46
2400799
7.90
1857805.49
SyuRTLD Compiler Opt.
7.95
22908.69
11.78
6791.88
2.48
531.88
151593.56
26.32
1471378.46
Improvementt's (%)
0
U23.4
428.39
08.30
01.86
282666
4.36.6
[J48.51
1/366
U20.8
mization as our primary goal. Despite these constraints, SymRTLO achieves substantial improvements. averaging 40.96% in power, 17.02% in delay, and 38.05% in area, while maintaining a balanced optimization across all three metrics, highlighting its versatility and robustness.
We present comprehensive analysis of SymRTLO capabilities using 11 mhort-benchhark examples from ReT.Rerriter focusing on Wires and Cells optimization, along with 10 complex FSM and algorithm examples from both short and long benchmarks. This representative selection demonstrates SymRTLO's s scalability and effectiveness across diverse functional domains but also aligns with circuits reported in RTLRewriter's paper, enabling direct comparison with state-of-the-art results.
Smaller benchmarks requiring only 1-2 optimization patterns provide ideal test cases for LLM output alignment. Table S shows that SymRTLO consistently outperforms baseline implementations across various test cases. With wire and cell ratios of 0.63 and 0.67 respectively, surpasses the statc-of-the. art values of 0.69 and 0.77. While models like GPT-4 excel in certain cases, they lack consistency across diverse optimization tasks.
In FSM PPA experiments, SymRTLO significantly outperforms existing approaches, particularly in relation to RTLRewriter, the state-of-the-ar solution, achieving an improvement of up to 50.59% 12.65%, 53.09% in power, time, and area, respectively. As shown in Table it effectively aligns the FSM state reduction algorithm with optimized code, minimizing all FSM states and achieving the best overall PPA results. This demonstrates that the LLM-generated symbolic system is both stable and aligned with intended optimization goals.
To evaluate the effectiveness of generalized rules and AST templates in balancing conflicting rules, we conduct algorithm case PPA experiments involving complex Data Path and Control Path scenarios. As shown in Table 7 SymRTLO applies AST templates, optimized rules, and minimized FSM states, achieving 30.34%, 21.37%, and 20.01 % improvements in PPA over GPT-4o, our base model, on average. Note that RTLRewriter's 's results are unavailable for comparison for these cases.
We test SymRTLO with Synopsys DC optimization workflows with medium mapping effort, incre- mental mapping for both FSM and Algorithm cases, as shown in Table 6 and Table 7 demonstrating further balanced optimization alongside compiler optimization processes, achieving overall improve- ments of 36.2% in power and 35.666 36.6% in area, with only an 8.3% increase in time as a trade-off. Even under more stringent compiler optimization settings of flattened mode with high mapping effort, SymRTLO still delivers overall improvements of 27.7% in area, 35.8% in power, and 0.5% in delay.
4.4 Ablation Studies
To assess the effectiveness of individual components in SymRTLO, we conduct ablation studies by systematically removing one component at time from the complete SymRTLO framework. In the first setting, disabling the AST-based template generation ("Remove Template-Based Opt") forced the model to rely solely on abstract rule descriptions with- out structural guidance. In the second, removing the FSM symbolic optimization mod- ule ("Remove Symbolic Reasoning") limited the framework to dataflow-only optimization.

---

In the third, turning off the goal-based rule filtering ("Remove Goal-Based Search") allowed all retrieved rules to be applied regardless of potential conflicts. For each configuration, we measured average PPA improvements across all benchmarks relative to the original designs. Figure summarizes these results, showing that all three components contribute significantly to SymRTLO's overall performance. Re- moving any one of them results in substantial losses in optimization ef- fectiveness, further emphasizing the necessity of their integration. By con- trast, GPT-4o alone achieves minimal improvements, underscoring the advantages of SymRTLO's tailored framework.
PPA Improvement
37%
38%
32%
20%
8%
1%
1%
1%
Timing
Area
Remove Template-Bage Based Opt
Remove Geal-Based Search
GPT40
Remove Symbolic Reasoning
SymRTLO
Figure 5:
Ablation study showing average PPA improve- ments when individual SymŘTLO components are removed. Each bar represents the framework's s performance with one component disabled, demonstrating the necessity of all three components for optimal results.
Discussion
is important to clarify that SymRTLO operates as a pre-synthesis optimizer that complements rather than replaces traditional synthesis tools. RTL logic synthesis (e.g.. Synopsys Design Compiler) takes RTL hardware descriptions and converts them to optimized gate-level netlists through optimizations including Boolean logic simplification, constant propagation, technology mapping, gate sizing, and retiming. While synthesis tools can perform local optimizations and limited resource sharing, they generally preserve the fundamental RTL architecture and control flow structure operating within the constraints of the original RTL specification.
In contrast, SymRTLO performs source-level code optimization that modifies the RTI. before syn- thesis, enabling algorithmic transformations, architectural restructuring, dataflow modifications, FSM redesign, and pipeline adjustments that fundamentally alter the hardware implementation. By optimizing at the RTL source level, SymRTLO can explore broader design space and make architec- tural decisions that are beyond the scope of gate-level synthesis tools, typically yielding larger PPA improvements than synthesis optimizations alone.
6
Limitations
While SymRTLO demonstrates significant improvements in RTL optimization, the framework's perfor- mance fundamentally dependent on the underlying capabilities of the base LLM, which may limit its effectiveness novel or highly specialized circuit patterns not well-represented in its training data. The optimization rule library, though comprehensive, requires ongoing maintenance and expansion to keep pace with evolving hardware design practices and emerging optimization techniques. Since final PPA evaluation relies on synthesis tools like Synopsys DC Compiler and Yosys, results may vary across different tool versions technology libraries. Additionally, while the symbolic reasoning module effectively handles FSM optimization, the approach may face scalability challenges when applied to extremely large state machines circuits with highly complex control flows that exceed current computational bounds for formal analysis.
7 Conclusion
We present SymRTLO, neuron-symbolic framework that integrates LLM-based code rewriting and symbolic reasoning to optimize both data flow and control flow in RTL designs. SymRTLO general- izes optimization rules, aligns generated code with intended transformations, resolves conflicting optimization goals, and ensures reliable automated verification. By combining retrieval-augmented guidance with symbolic systems, SymRTLO automates complex structural rewrites while maintaining functional correctness. Extensive evaluations on industrial-scale designs demonstrate significant PPA gains over ofte-offtthe-at solutions.
10

---

References
[1] Jason Blocklove, Siddharth Garg, Ramesh Karri, and Hammond Pearce. Chip-chat: Challenges and opportunities in conversational hardware design. In 5th ACM/IEEE Workshop on Machine Learning for CAD, MLCAD. IEEE, 2023.
[2] R. Brayton and A. Mishchenko. ABC: An academic industrial-sttrenth verification tool. In Computer Aided Verification: 22nd International Conference, CAV 2010, Edinburgh, UK, July 15-19, 2010. Proceedings 22, pages 24-40. Springer, 2010.
[3] Bruno Buchberger and Rüdiger Loos. Algebraic simplification. In Computer algebra: symbolic and algebraic computation, pages 11-43. Springer, 1982.
[4] Jacques Carette.
Understanding expression simplification. Proceedings of the 2004 interna- lional symposium Symbolic and algebraic computation, pages 72-79, 2004.
[5] Kaiyan Chang, Ying Wang, Haimeng Ren, Mengdi Wang, Shengwen Liang, Yinhe Han, Huawei Li, and Xiaowei Li. Chipgpt: How far we from natural language hardware design. abs/2305.1400 14019, 2023.
[6] Deming Chen and Jason Cong. Register binding and port assignment for multiplexer opti- mization. In Proceedings of the 2004 Asia and South Pacific Design Automation Conference, ASP-DAC '04, page 68-73. IEEE Press, 2004.
[7] Sihan Chen, Zhuangzhuang Qian, Wingchun Siu, Xingcan Hu, Jiaqi Li, Shawn Li, Yuehan Qin, Tiankai Yang, Zhuo Xiao, Wanghao Ye, Yichi Zhang, Yushun Dong, and Yue Zhao. Pyod 2: A python library for outlier detection with llm-powered model selection. arXiv, 2412.12154 December 2024.
[8] Pong P Chu, RTL hardware design using VHDL: coding for efficiency, portability, and scalabil- ity. John Wiley & Sons, 2006.
[9] John Cocke. Global common subexpression elimination. Proceedings of a symposium on Compiler Optimization, pages 20-24.2 ACM, 1970.
[10] Keith D Cooper, L Taylor Simpson, and Christopher A Vick. Operator strength reduction. ACM Transactions Programming Languages and Systems (TOPLAS), 23(5):603-62) 2001.
[11] Revathy Venkataramanan Deepa Tilwani and Amit P. Sheth. Neurosymbolic ai approach to attribution in large language models. arXiv, 2410.03726, September 2024. Paper under review.
[12] Stefano Teso Diego Calanzone and Antonio Vergari. Logically consistent language models via neuro-symbolic integration. arXiv, 1472.13724, September 2024.
[13] Wenji Fang, Yao Lu, Shang Liu, Qijun Zhang, Ceyu Xu, Lisa Wu Wills, Hongce Zhang, and Zhiyao Xie. Masterrtl: A pre-synthesis ppa estimation framework for any rtl design. In 2023 JEEE/ACM International Conference on Computer Aided Design (ICCAD), pages 1-9, 2023.
[14] Weimin Fu, Yiting Wang, Zelin Lu, Xiaolong Guo, and Gang Qu. Hada: Leveraging multi- source data to train large language models for hardware security assertion generation. In 2025 ACM/IEE 7th Symposium Machine Learning for CAD (MLCAD), pages 2025.
[15] Weimin Fu, Kaichen Yang, Raj Gautam Dutta, Xiaolong Guo, and Gang Qu. LIm4sechw: Leveraging domain-specific large language model for hardware debugging. In 2023 Asian Hardware Oriented Security and Trust Symposium (AsianHOST)), pages 1-6, 2023.
[16] Ping Guo, Yiting Wang, Wanghao Ye, Yexiao He, Ziyao Wang, Xiaopeng Dai, Ang Li, and Qingfu Zhang. Evoverilog: Large langugage model assisted evolution of verilog code, 2025.
[17] Rajiv Gupta, DA Benson, and Jesse Zhixi Fang. Path profile guided partial dead code elimination using predication. Proceedings 1997 International Conference on Parallel Architectures and Compilation Techniques, pages 103-113. IEEE, 1997.
11

---

[18] John E Hopcroft and Jeffrey D Ullman. Formal languages and their relation to automata. Addison- Weoolyy Longman Publishing Co., Inc., 1969.
[19] Yi Hu, Haotong Yang, Zhouchen Lin, and Muhan Zhang. Code prompting: a neural symbolic method for complex reasoning in large language models, 2023.
[20] Jens Knoop. Oliver Rüthing, and Bernhard Steffen. Partial dead code elimination. ACM Sigplan Notices, 29(6):147-158, 1994.
[21] Charles Eric LaForest and J. Gregory Steffan. Efficient multi-ported memories for fpgas. In Proceedings of the 18th Annual ACM/SIGDA International Symposium on Field Programmable Gate Arrays (FPGA '10), pages 41-50, Monterey, CA, USA, 2010. ACM.
[22] P. Langley. Crafting papers on machine learning. In Pat Langley, editor, Proceedings of the 17th International Conference on Machine Learning (ICML 2000), pages 1207-1216, Stanford, CA, 2000. Morgan Kaufmann.
[23] Mingjie Liu, Teodor-Dumitru Ene, Robert Kirby, Chris Cheng, Nathaniel Ross Pinckney, Rongjian Liang, Jonah Alben, Himyanshu Anand, Sanmitra Banerjee, Ismet Bayraktaroglu, Bonita Bhaskaran, Bryan Catanzaro, Arjun Chaudhuri, Sharon Clay, Bill Dally, Laura Dang, Parikshit Deshpande, Siddhanth Dhodhi, Sameer Halepete, Eric Hill, Jiashang Hu, Sumit Jain, Brucek Khailany, Kishor Kunal, Xiaowei Li, Hao Liu, Stuart F. Oberman, Sujeet Omar, Sreedhar Pratty, Jonathan Raiman, Ambar Sarkar, Zhengjiang Shao, Hanfei Sun, Pratik P. Suthar, Varun Tej. Kaizhe Xu, and Haoxing Ren. Chipnemo: Domain-adaple lims for chip design. CoRR, abs/2311.00 1.00176, 2023.
[24] Mingjie Liu, Nathaniel Ross Pinckney, Brucek Khailany, and Haoxing Ren. Invited paper: Verilogeval: Evaluating large language models for verilog code generation. In IEEE/ACM International Conference on Computer Aided Design, ICCAD. IEEE, 2023.
[25] Shang Liu, Wenji Fang, Yao Lu, Jing Wang, Qijun Zhang, Hongee Zhang, and Zhiyao Xie. Rtlcoder: Fully open-source and efficient Ilm-assisted rtl code generation technique. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 2024.
[26] Yiyi Lu, Hoi Ian Au, Junyao Zhang, Jingyu Pan, Yiting Wang, Ang Li, Jianyi Zhang, and Yiran Chen. Autoeda: Enabling eda flow automation through microservice-based IIm agents, 2025.
[27] Jiacheng Ma. Gefei Zuo, Kevin Loughlin, Xiaohe Cheng. Yanqiang Liu, Abel Mulugeta Eneyew, Zhengwei Qi, and Baris Kasikci. A hypervisor for shared-memory fpga platforms. In Proceedings of the Twenty-Fifh International Conference on Architectural Support for Programming Languages and Operating Systems, pages 827-844, 2020.
[28] Edward F Moore et al. Gedanken-expprimeent on sequential machines. Automata studies, 34:129-153, 1956.
[29] OpenAI, Josh Achiam, Steven Adler, Sandhini Agarwal, and many others. Gpt-4 technical report. arXiv, 2303.08774, March 2023.
[30] Samir Palnitkar. Verilog HDL: a guide to digital design and synthesis, volume Prentice Hall Professional, 2003.
[31] R. Pasko, P. Schaumont, V. Derudder, S. Vernalde, and Daniela Duracková. A new algorithm for elimination of common subexpressions. Computer-Aide Design of Integrated Circuits and Systems, IEEE Transactions on, 18:58 - 68, 02 1999.
[32] Jim Schultz. Optimizing the rtl design flow with real-time ppa analysis. Synopsys Silicon to Systems Blog, N/A, March 2023. Blog Post. URL: http://wwwwyooosss.ombbbbbbeeo/e (Accessed January 26, 2025).
[33] Synopsys. De ultra for synthesis and test. https://www.yynot
com/
Impllementatiio--d--siiiie http://aw......o.oooooooooooeess htt.sssttthsssstesssstaaaeee-eee
[34] Shinya Takamaeda-Vamarrkii Pyverilog: A python-based hardware design processing toolkit for verilog hdl. In Applied Reconfigurable Computing, volume 9040 of Lecture Notes in Computer Science, pages 451-460. Springer International Publishing, Apr 2015.
12

---

[35] Vaibbhav Taraate. Digital logic design using verilog. Springer, 2022.
[36]
Shailja Thakur, Baleegh Ahmad, Hammond Pearce, Benjamin Tan, Brendan Dolan-Gavitt, Ramesh Karri, and Siddharth Garg. Verigen: A large language model for verilog code generation. ACM Trans. Design Autom. Electr: Syst., 2024.
[37] Yunda Tsai, Mingjie Liu, and Haoxing Ren. Rtifixer: Automatically fixing RTL syntax errors with large language model. In Proceedings of the 61st ACM/IEE Design Automation Conference, DAC. ACM, 2024.
[38] Frank Vahid. Digital design with rtl design, vhdl, and verilog (2nd edition). John Wiley & Soons Inc, 2, January 2010. ISBN-13: 04--04775310822 575 pages.
[39] Zishen Wan, Che- Che Liu, Hanchen Yang. Ritik Raj. Chaojian Li, Haoran You, Yonggan Fu, Cheng Wan, Sixu Li, Youbin Kim, Ananda Samajdar, Yingyan Celine Lin, Mohamed Ibrahim, Jan M. Rabaey. Tushar Krishna, and Arijit Raychowdhury. Towards efficient neuro-symbole ai: From workload characterization to hardware architecture. arXiv, 2409. 13153, September 2024. Published in IEEE Transactions Circuits and Systems for Artificial Intelligence (TCASAI), 2024.
[40] Laung- Terng Wang. Yao-Wen Chang, and Kwang-Ting -ing Tim Cheng. Electronic design automa- fion: synthesis, verification, and test. Morgan Kaufmann, 2009.
[41] Yiting Wang, Guoheng Sun, Wanghao Ye, Gang Qu, and Ang Li. Verireason: Reinforcement learning with testbench feedback for reasoning-enhancee verilog generation, 2025.
[42] Yiting Wang, Wanghao Ye, Yexiao He, Yiran Chen, Gang Qu, and Ang Li. Mcp4eda: Llm- powered model context protocol rtl-to-gdsse automation with backend aware synthesis optimiza- tion, 2025.
[43] Zicheng Wang, Hailong You, Jie Wang, Meihua Liu, Yu Su, and Yong Zhang. Optimization of multiplexer combination in logic synthesis. Proceedings of the 2023 International Symposium of Electronics Design Automation (ISEDA), page N/A. IEEE, May 2023.
[44] Clifford Wolf, Johann Glaser, and Johannes Kepler. Yosys-a free verilog synthesis suite. In Proceedings of the Forum on Specification and Design Languages (FDL), 2013. Yosys is the first open-source Verilog synthesis suite supporting wide range of synthesizable Verilog features.
[45] Sen Yang, Xin Li, Leyang Cui, Lidong Bing, and Wai Lam. Neuro-symbolic integration brings causal and reliable reasoning proofs. arXiv, 231 1.0980, November 2023. Code available at this URL.
[46] Xufeng Yao, Yiwen Wang, Xing Li, Yingzhao Lian, Chen Ran, Lei Chen, Mingxuan Yuan, Hong Xu, and Bei Yu. Rtlrewriter: Methodologies for large models aided rtl code optimization, 09 2024.
[47] Junjie Yc, Xuanting Chen, Nuo Xu, Can Zu, Zekai Shao, Shichun Liu, Yuhan Cui, Zeyang Zhou, Chao Gong, Yang Shen, Jie Zhou, Siming Chen, Tao Gui, Qi Zhang, and Xuanjing Huang. A comprehensive capability analysis of gpt-3 and gpt-3.5 series models, 2023.
[48] Lin Yuan, Gang Qu, Tiziano Villa, and Alberto Sangiovanni-Vincenellii Fsm re-engineering and its application in low power state encoding. In Proceedings of the 2005 Asia and South Pacific Design Automation Conference, ASP-DAC '05, page 254-259, New York, NY, USA, 2005. Association for Computing Machinery.
[49] Haifeng Zhou, Zhenghui Lin, and Wei Cao. Research on vhdl rtl synthesis system. In Proceedings First IEEE International Workshop on Electronic Design, Test and Applications '2002, pages 903103, 2002.
13

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification: The abstract and introduction clearly define the scope. Our contributions listed in the introduction.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made in the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results be expected to generalize other settings.
It is fine include aspirational goals as motivation long is clear that these goals are not attained by the paper.
2. Limitations
Question:
Does the paper discuss the limitations of the work performed by the authors?
Answer: [Yes]
Justification:
We discuss in conclusion.
Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors encouraged to create separate "I "Limitations" section in their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution is low images are taken in low lighting. Or speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.
While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, worse outcome might that reviewers discover limitations that aren't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
3. Theory assumptions and proofs
Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
14

---

Answer: [NA]
Justification:
Our paper does not contain formal mathematical proofs.
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated or referenced in the statement of any theorems.
The proof's can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide a short proof sketch provide intuition.
Inversely, any informal proof provided in the core of the paper should complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental result reproducibility
Does the paper fully disclose all the information needed to reproduce the main ex- perimental results the paper to the extent that affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided not)?
Question:
Answer: [Yes]
Justification: We have detailed explanation of datasets, models, and hyperparameters for reproducing results.
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, descríbing the architecture fully might suffice, or if the contribution is specific model and empirical evaluation, it may be necessary to either make possible for others to replicate the model with the same dataset, provide access to the model. In general. releasing code and data is often one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., g., in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.
While NeurIPS does not require releasing code, the conference does require submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) the contribution is primarily a new algorithm, the paper should make clear how reproduce that algorithm. (b) If the contribution is primarily new model architecture, the paper should describe the architecture clearly and fully.
(c) the contribution is new model (e.g., a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset or instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome describe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should possible for other researchers to have some path to reproducing verifying the results.
5. Open access to data and code
15

---

Does the paper provide open access to the data and code, with sufficient instruc- tions faithfully reproduce the main experimental results, as described in supplemental material?
Question:
Answer: [Yes]
Justification:
We did upload code.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurlPS code and data submission guidelines (https://nips... cc/
for more details.
While we encourage the release of code and data, we understand that this might not be possible, "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for a new open-source benchmark).
The instructions should contain the exact command and environment needed to run reproduce the results. See the NeurIPS code and data submission guidelines (https
/ "tipps.c/ppbllc//uuui Satpa///ggideee//Ceuuuuubbibbii cotoomisssioo ssionooiccy for more details.
The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. only subset of experiments are reproducible, they should state which ones omitted from the script and why.
At submission time, preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information as possible in supplemental material (appended to the paper) recommended, but including URLs to data and code permitted.
6. Experimental setting/details
Question: Does the paper specify all the training and test details (c.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Answer: [Yes]
Justification:
We have clear details in the experiments.
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core of the paper to level of detail that is necessary to appreciate the results and make sense of them.
The full details can provided either with the code, in appendix, or as supplemental material.
7. Experiment statistical significance
Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Answer: [Yes]
Justification: The results include statistical calculations.
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by error bars, confi- dence intervals, or statistical significance tests, at least for the experiments that support the main claims of the paper.
The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)
16

---

The assumptions made should be given (e.g.. Normally distributed errors).
It should be clear whether the error bar is the standard deviation the standard error of the mean.
is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out range (e.g. negative enror rates).
If error bars reported in tables plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information the com- puter resources (type of compute workers, memory, time of execution) needed to reproduce the experiments?
Question:
Answer: [Yes]
Justification:
We have the details in paper.
Guidelines:
The answer NA means that the paper does not include experiments.
The paper should indicate the type of compute workers CPU or GPU, internal cluster, cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental rums as well as estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported the paper (e.g., preliminary or failed experiments that didn't 't make it into the paper).
9. Code of ethics
Question: Does the research conducted the paper conform, in every respect, with the NeurlPS Code of Ethics
Answer: [Yes]
Justification: The research conducted in the paper conform, in every respect, with the NeurlPS Code of Ethics.
Guidelines:
The answer NA means that the authors have not reviewed the NeurIPS Code of Ethics.
If the authors answer No, they should explain the special cireumstances that require deviation from the Code of Ethics.
The authors should make sure to preserve anonymity (e.g.. if there is a special consid- eration due to laws or regulations in their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [NA]
Justification: The paper is about using LLM for hardware design.
Guidelines:
The answer NA means that there no societal impact of the work performed.
If the authors answer NA or No. they should explain why their work has no societal impact why the paper does not address societal impact.
Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
17

---

The conference expects that many papers will be foundational research and not tied particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology being used as intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.
If there negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms monitor how system learns from feedback over time, improving the efficiency and accessibility of MI..
11. Safeguards
Does the paper describe safeguards that have been put in place for responsible release of data models that have high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Question:
Answer: [NA]
Justification:
The paper poses no such risks.
Guidelines:
The answer NA means that the paper poses such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make best faith effort.
12. Lieenses for existing assets
Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper. properly credited and are the license and terms of use explicitly mentioned and properly respected?
Answer: [NA]
Justification: The paper uses open-sourced datasets and models without such assets.
Guidelines:
The answer NA means that the paper does existing assets.
The authors should cite the original paper that produced the code package or dataset.
The authors should state which version of the asset is used and, if possible, include URL.
The name of the license (c.g., CC-BY 4.0) should be included for each asset.
For scraped data from a particular source (c.g., website), the copyright and terms of service of that source should be provided.
If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, papprssiiiitt. thcode. com com/datasets has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.
18

---

If this information is not available online, the authors are encouraged to reach out to the asset's creators.
13. New assets
Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [NA]
Justification: The paper does not release new assets.
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details of the dataset/code/mmoel as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent obtained from people whose asset is used.
At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.
14. Crowdsoureing and research with human subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well details about compensation (if any)?
Answer: [NA]
Justification: The paper does not involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included the main paper.
According the NeurIPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals or equivalent for research with human subjects
Question:
Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [NA]
Justification:
The paper does not involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Depending the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and expect authors to adhere to the NeurlPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if applicable), such the institution conducting the review.
16. Declaration of LLM usage
19

---

Question: Does the paper describe the usage of LLMs if it is important, original, or non-standard component of the core methods this research? Note that if the LLM used only for writing, editing, or formatting purposes and does not impact the core methodology, scientific rigorousness, or originality of the research, declaration is not required.
Answer: [Yes]
Justification:
The paper is about LLM. We carefully described the role of LLM in the process.
Guidelines:
The answer NA means that the method development in this research does involve LLMs as any important, original, or non-standard components.
Please refer to our LLM policy for what should or should be described.
20

---

A FSM Symbolic System
The following section demonstrates example FSM in verilog. First the verilog is transformed to Symbolic Representation, then the Symbolic system applied minimization algorithm to optimize the FSM.
modulle example(
input wire clk,
input wire reset, input wire [1:0] input_ input_signal,
output reg output_signal)
parameter So 3'b000, 3'b001, 3'b010,83 3'b011,S4 3'b100,50
b1011;
reg [2:0] current_state, next_state;
always @cturrent_state) begin
output_ 0;
case (current_stane
s0: output_signal
S2: output_signal = 1;
s4: output_signal = 1;
14
default: output_signal 0;
endcase end always (posedge clk posedge reset) begin
if (reset) begin
current_state state <= so; // Reset to state s0 end else begin
20
current
next_state;
end end
34
always ((+) begin
25
next_state current_state;
case (current_state
S0: case Simput_signal]
b'0: _ext_state S0;
29
2'b01: next_state = S1;
30
2'b10: next_state $2;
31
2'b11: next_state S3;
endcase
S1: case
b'b00: next_state S0;
35
2'b01: next_state = S3;
2'b11: next_state S5;
37
endcase (input_signal
$2:
b'b00: next_state = S1;
40
2'b01:
S3;
43
2'b10: next_state = S2;
42
2'b11: next_state $4;
endcase
S3: case
45
2' 2'bo0: next_state S1;
46
2'b01:
= S0;
47
2'b10: next next_state $4;
2'b11: next_state S5;
endcase
$4: case (input_se sinput_signal)
51
2'b00: next_state S0;
52
2'b01: next next_state S1;
53
2'b10: next_state S2;
2 b11: next_state S5;
endcase
$5: case (input_signal)
57
2 b0b: next_state S1;
bbb: next_state S4;
b10: next_state S0;
endcase endcase
62
end
63 endmoduue
Listing 1: Example Test Case: examplel state.
21

---

'sstate': ['SO', 'S1', 'S2', 'S3', '84', 's5'], trransitions:
'S0': "input_signal=0"
I'next_state" '80'),
'imput_signal=011 ('next_state' '
"imput_signal=10": ('next_state': 'S2'),
"imput_signal-11";
{ n'nextsstate: '
}.
'S1': "input_signal=00 ('aext_state': '
"imput_sigmal=01" ('next_state's 's3',,
"imput_signal=11" ('next_state'; 'S5')
}.
14
'S2":
15
'imput_ssgmal-00': ('next_state': '
"imput_signal-01" ('next_state': '
'input_sigmal-10" ('next_state:. (S2')
'imput_signal-11': ('next_state:; (84')
},
20
'S3': :
21
'imput_sigmal-00': ('next_state': 'S1",
"imput_signal-01" ('next_state' '80")
"imput_signal-10" ('next_state': '84),
'imput_signal-11", {' ('next_state: '55))
25
},
26
'S4';
27
'imput_signal=00": ('next_state': '80'),
'imput_signal=01' ('next_state', '11',
"snput_signal=10" ('next_state', '22),
30
'input_signal-11" ('next_state': (85")
31
}.
32
'S5":
'smput_sigmal-00': ('next_state': 'S1'),
'imput_signal-011 ('next_state': '84)), 'imput_signal=10"; ('next_state': 'S0")
56
37
outputs': : {'S0': ('output_signal 1),
'S1'; ('output_signal" 0},
'S2': { ('output_signal" 1),
'S3': { d'output_signal': 0),
42
'S4': { "outpuu_ssinal'' 1),
' { "output_signal'' 0}
Listing 2: LLM LLM--gnnrratd symbolic representation for examplel state.
1State: $2, Output: 1
input_signal=00 -> S1
input_signal==) -> $3_S5
imput_signal=10 $2
5 input__sinna=-11 $0_S4
<State: S0_54, Output:
imput_sigmal=00 $0_84
input_signal-I -> S1
input_signal-10 $2
:1State: S1, Output: $3_S5
imput__signa=11.
input_signal-00 $0_$4
input_signal-0f >> $3_S5
14 input_signal-10 -> $1
15
$3_S5
16State: $3_55, Output:
input_signal-00
S1
input_signal-01 -> $0_$4
input_signal-11 >> $0_$4
20 input_signal-11 -> $3_S5
Listing 3: Reduced states of example state.
22

---

B AST Template
The following section demonstrate how applying AST templates transforms the code and apply optimization patterns,
moduule example_raw
2* parameter
8)
input [BW-1:0]
input [BW-1:0] b,
6
input [BW-1:0] C,
input [BW-1:0] d,
output [BW-1:0]
9);
assign s2
b;
11
assign a3 a % b +d;
12
assign 84 с
a;
assign s5
b;
assign s6 (b 1)
d
assign sl 23;
16 1endmoduue
Listing 4: Example Test Case: dead code elimination.
modull example_rae _aap #
(parameter BW 8)
input [BW-1:0]
input [BW-1:0] b,
6 input [BW-1:0] C,
input [BW-1:0] d,
output [BW-1:0]
9);
assign s1 23;
11 endmodule
12
Listing 5: Example Test Case: dead_code elimination after applying the Dead Code Elimination AST template.
moouule example_ray
2#
parameter
BW 8)
{
input [BW-1:0] a,
input [BW-1:0] b,
input [BW-1:0] c,
input [BW-1:0] d,
output [BW-1:0] s1,
output [BW-1:0] s2,
output [BW-1:0] s3,
output [BW-1:0] 84,
output [BW-1:0] s5,
output [BW-1:0] s6
14)
15
assign
b;
assign s2
b;
assign s3 \% +d;
assign 24 +
assign a5 a b; assign a6
20
1) +a+d -b;
21 endmodule
Listing 6: Example Test Case: bebeexpprssion_eliiinaeee
23

---

modulle example
2#(
parameter
BW 8)
3
input [BW-1:0] a,
input [BW-1:0] b,
input [BW-1:0] c,
input [BW-1:0] d,
output [BW-1:0] s1,
output [BW-1:0] s2,
output [BW-1:0] s3, output [BW-1:0] 84, output [BW-1:0] 85,
output [BW-1:0] a6
15);
14
assign sl a b;
15
assign 82 a b;
assign
d;
assign 84
82;
assign s5 b; assign s6 s4 s5;
20 enddmddule
Listing 7: Example Test Case: subexpression elimination after applying the Common Sub-Expressions Elimination template. The Common Bub-Expressioos are reused the states after it.
module example_ree
2#
parameter BW 8)
{(
input 1:0] a,
input [BW-1:0] b,
output [BW-1:0] s1,
output [BW-1:0] s2
s);
wire [BW-1:0] t1, t2;
assign
b;
assign
0;
assign t2 sl 1;
assign s2 ti t2;
14 ennmoduule
Listing 8: Example Test Case: algebraic_ simplification.
2module example_rav
parameter BW 8
5)
input [BW-1:0] a,
input [BW-1:0] b,
output [BW-1:0] s1,
output [BW-1:0] s2 11);
assign
assign s2 s1 s1;
1endmodule
Listing 9; Example Test Case: algebraic_simplifeeieieecee simplification after applying the Temporary Variable Elimination, Dead Code Elimination, then Expression Simplification templates.

---

C RAG Example
Sample Retrieval Augmented Optimization Rule
"name":
"Intermediate VariableExttrattion,,
"pattern": "Detect conditional assignments to register based on control signal", "rewrite"; "Extract common sub-expressions into intermediate variables to reduce redundant logic",
"category": "combinational/dataftoow"
"objective_improne iimprovmmeet: "area",
"template "template_guidannee" guidance" "To implement this rule in Python template subclassing Base Template, use pyverilog AST manipulation identify conditional assignments (vast.IfStatemeet) and extract the common sub-exprees cub-exxressions into separate assignments. Look for vast.Identifier nodes that are assigned conditionally and create new vast.Assign nodes for the intermediate variables. Ensure that the new assignments are placed before the conditional logic to maintain correct data flow".
"function_name". name": Theermoddae vaaaheeeeertttrrrPpd
Figure 6: Sample Retrieval Augmented Optimization Rule Intermediate Variable Extraction.
Sample Retrieval Augmented Optimization Rule
"name": "HiirarchicalEEppeesioon TreppesssiiiTreeRReeeccuutrrnnn
"Detect flat conditional assignments with redundant arithmetic operations across different control paths".
"pattern": :
"Transform into hierarchical tree structure with intermediate wire assignments for resource sharing",
"rewrite"; :
"category": "combinational/daatttoow""
"area, delay".
"template :uiilecuuudd: "Parse conditional assignments, extract common subexpressions (e.g., real y0_real y0 y0_imag y0_ (0_imag'), create intermediate wires, and build balanced adder trees. Replace flat expressions with hierarchical structure",
"function name":
Figure 7: Sample Retrieval Augmented Optimization Rule 2: Hierarchical Expression Tree Restruc- turing.
Sample Retrieval Augmented Optimization Rule
"name": "AgoritmmicloopooPipeenne Pwr.ppoPPPiiineeTTafoomaaooooo Transformation",
"pattern": "Detect sequential loops with independent operations where each iteration processes different data elements without dependencies".
"rewrite"; : "Transform sequential loops into pipelined architectures with staged data flow and parallel processing units".
"category": "control/datafloow",
bonjective_improvementt "delay, power",
ceemplate_guidancee.. "Identify loops like 'for(i=0; i<N; i++) output(i] = func(input(il) with no loop-carried dependencies. Convert to pipeline stages where each stage processes one element: create N pipeline registers, instantiate processing units between stages, add valid/ready handshaking. Replace loop with continuous data flow through pipeline stages". LoopToPipelineTemplaee
"template guidance":
Figure 8: Sample Retrieval Augmented Optimization Rule 3: Algorithmic Loop-to-Pipplinee Transfor- mation.
25

---

Sample Retrieval Augmented Optimization Rule
"name": "Zero Multiplication Elimination".
"pattern:: "Detect multiplication by zero in expressions (e.g., 0 * c)",
"rewrite": "Eliminate multiplication by zero, replacing the entire expression with zero",
"category": "'ombinationaldattatovv""
"area",
"template guidance":
veepllate_uiddance" "Identify vast. Times nodes with zero operand. Replace the node with Inntnst node representing zero.", ",
"function name": "ZeroMuttippicatonTemmaatttt"
Figure 9: Sample Retrieval Augmented Optimization Rule 4: Zero Multiplication Rule.
Hardware Optimization Rule
"name": Reenaacttiieerrrriiiaar.....oaa
"pattern: "Detects ripple carry adder implementation using a series of full adders connected in sequence".
"rewrite": "Transforms the ripple carry adder into a carry lookahead adder by using partial full adders and generating carry bits in parallel", "category": "combinational/dattttoww"" Dotbective_improvemeee"" "arca, delay",
"template guidance"; "iemplate_guidance": null, "function_ "function_name": : null
Sample Retrieval Augmented Optimization Rule 5: Replace Ripple Carry with Carry Lookahead, no template guidance is needed since it an abstract rule.
Figure 10:
Sample Retrieval Augmented Optimization Rule
"name":
"Identify oversized register widths in arithmetic pipelines with scaling factors", "rewrite": ; "Reduce bit-widths based on mathematical analysis of scaling requirements while preserving precision".
"pattern":
"category": paatapptthprecisioon,,
"area, power",
"template tatpllate_guddacee""" "Analyze scaling factors in arithmetic operations, calculate minimum required bit-widths based on dynamic range analysis, modify register declarations and shift operations. Example: reduce 40-bit to 28-bit when 13-bit scaling is excessive. Use pyverilog to identify Width nodes and replace with optimized bit-width declarations", "function name": : BiiviidhhOpimmizationnnmmmm
Figure 11: Sample Retrieval Augmented Optimization Rule 6: Algorithm-Aware Bit-width Optimiza- tion.
26


Reviews:
[{"review_id": "0T6Y5160ci", "reviewer": "Reviewer_u5E9", "summary": "The authors propose an effective and efficient RTL code optimization framework, as SymRTLO, which integrates a LLM with a neuron- inspired symbolic reasoning module. The framework targets both data path and control path optimization, addressing limitations in traditional EDA compilers as well as purely LLM-based approaches. By leveraging RAG and AST-based templates, and alignment with FSM and data path algorithms, the approach introduces a novel and structured methodology. The proposed framework achieves significant improvements in PPAD metrics when benchmarked against SOTA methods.", "questions": "Q1. How well does proposed approach generalize across ASIC and FPGA designs?\nQ2. Are the learned optimization rules transferrable across domains like DSP, control logic etc.?\nQ3. How do you handle edge cases where rule learning (knowledge) fails or contradicts hardware constraints?", "limitations": "The authors mentioned an intention to discuss the limitations, but this is missing from the current version of the manuscript (best of my knowledge). The points raised under weaknesses and questions should help improving the technical merit of the manuscript.", "rating": 5, "confidence": 5, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strength:\n1. The authors provide a thorough discussion of the existing challenges in RTL code optimization, addressing limitations in both traditional compilers and recent LLM-based approaches. This comprehensive background helps a broader audience understand the motivation behind the research and the rationale for the proposed methodology. Multi-variate optimization is a fundamental challenge in complex frameworks such as chip design flows, and the authors effectively articulate and formulate this challenge in the context of identifying an optimal solution.\n2. Again, methodology is clearly explained with substantial detail, using step identifiers (1,2,3...) as illustrated in Figure 1. to describe the proposed architecture. Sub-sections such as data flow optimization, control flow optimization,  AST template construction, rule alignment and conflict resolution are thoroughly detailed and well-articulated.\n3. Finally, experimental details and validation are well discussed and justified.\n\nLimitations:\nI have minor suggestions\n1. Ablation study representation w.r.t Figure 5 appears ambiguous, while the authors' intent is understandable, this section requires revisions (rewriting) for greater clarity. It is not clearly conveyed (..to me both in text and in figure) what the authors wanted to explain as \"We then analyze the impact of each removal across test cases, measuring the resulting overall PPA improvements compared to the base\"  . A more precise and correctly written explanation will be appreciated.\n2.  Please provide and discuss the limitation or breaking point of the proposed framework. Though author mentioned a separate section on this discussion, did not practically notice it. is this right? Can you please highlight if I missed anything?\n3. some typos can be noticed. like \"line number 205..........and the a rule embedding...\"", "was_revised": true, "final_justification": "The authors have provided satisfactory clarifications and demonstrations, and the research manuscript presents significant technical merit. I recommend its acceptance.", "rebuttal": "We sincerely thank the reviewer for their thorough evaluation and highly positive feedback. We are grateful for your recognition of SymRTLO's comprehensive methodology, detailed experimental validation, and significant technical contributions. Your constructive suggestions will help us improve the manuscript's clarity and completeness. We appreciate your recommendation for acceptance and hope our responses further strengthen the work's impact.\n\n## Addressing Limitations:\n\n### 1. Ablation Study Clarification (Figure 5)\n\nWe acknowledge the ambiguity in our ablation study presentation and will revise for greater clarity:\n\n**Clarified Methodology:** We systematically removed one component at a time from the complete SymRTLO framework:\n- **\"Remove Template-Based Opt\":** Disabled AST-based template generation, using only abstract rule descriptions\n- **\"Remove Symbolic Reasoning\":** Disabled FSM symbolic optimization module, using only dataflow optimization\n- **\"Remove Goal-Based Search\":** Disabled objective-based rule filtering, using all available rules regardless of conflicts\n\n**Measurement Process:** For each configuration, we measured PPA improvements across all test cases and computed the average improvement relative to the original unoptimized designs. The results show each component's individual contribution to overall performance.\n\n**Revised Figure 5 Caption:** \"Ablation study showing average PPA improvements when individual SymRTLO components are removed. Each bar represents the framework's performance with one component disabled, demonstrating the necessity of all three components for optimal results.\"\n\n### 2. Framework Limitations Discussion\n\nThank you for pointing out this concern. We will include these limitations explicitly in our revised manuscript to provide complete transparency to the community:\n\n\"While SymRTLO demonstrates significant improvements in RTL optimization, the framework's performance is fundamentally dependent on the underlying capabilities of the base LLM, which may limit its effectiveness on novel or highly specialized circuit patterns not well-represented in its training data. The optimization rule library, though comprehensive, requires ongoing maintenance and expansion to keep pace with evolving hardware design practices and emerging optimization techniques. Since final PPA evaluation relies on synthesis tools like Synopsys DC Compiler and Yosys, results may vary across different tool versions or technology libraries. Additionally, while the symbolic reasoning module effectively handles FSM optimization, the approach may face scalability challenges when applied to extremely large state machines or circuits with highly complex control flows that exceed current computational bounds for formal analysis.\"\n\n### 3. Typo Corrections\n\nThank you for catching the typo on line 205. We will correct \"and the a rule embedding\" to \"and a rule embedding\" and conduct a thorough proofreading pass.\n\n## Q1: How well does the proposed approach generalize across ASIC and FPGA designs?\n\n**SymRTLO generalizes well across both ASIC and FPGA targets:**\n\nOur approach optimizes at the RTL source level, making optimizations tool-independent and applicable before technology mapping. Since SymRTLO operates on Verilog RTL rather than technology-specific netlists, optimizations transfer across different target technologies. The symbolic reasoning module adapts FSM optimizations regardless of underlying implementation technology.\n\n## Q2: Are the learned optimization rules transferable across domains like DSP, control logic etc.?\n\n**Yes, optimization rules demonstrate strong cross-domain transferability:**\n\n**Domain Adaptation Mechanism:** By integrating an LLM with RAG, our framework enables easy and rapid scaling of its optimization rule database. This approach ensures adaptability and generalizability as complexity increases. The RAG system categorizes rules by domain (DSP, control, memory, arithmetic) and application context. Rules tagged as \"general arithmetic\" apply across domains, while domain-specific rules (e.g., \"FFT butterfly optimization\") remain targeted.\n\n**Cross-Domain Examples:**\n- **Subexpression elimination:** Transfers from DSP (multiply-accumulate) to control logic (address computation)\n- **State machine optimization:** Control FSMs → Protocol controllers → DSP sequencers\n- **Resource sharing:** Arithmetic units in DSP → Comparators in control logic\n\n\n## Q3: How do you handle edge cases where rule learning fails or contradicts hardware constraints?\n\n**Multi-Layer Safety Mechanisms:**\n\n**1. Constraint Violation Detection:**\n- **AST Template Validation:** Real-time checking ensures generated code respects Verilog syntax and semantic constraints\n- **Hardware Constraint Analysis:** Timing, area, and power constraints are validated during optimization rule application\n- **Resource Conflict Detection:** The RAG system identifies when rules would exceed available hardware resources\n\n**2. Graceful Degradation:**\n- **Conservative Fallback:** When formal verification fails or constraints are violated, SymRTLO reverts to the original design rather than applying potentially harmful optimizations\n- **Partial Optimization:** If some rules fail, successfully validated optimizations are retained while problematic ones are rejected\n- **Rule Confidence Scoring:** Low-confidence optimizations are flagged for manual review\n\n**3. Contradiction Resolution:**\n- **Priority-Based Resolution:** Critical constraints (timing, functionality) override optimization goals when conflicts arise\n- **Multi-Objective Balancing:** The elbow method (Equation 1) prevents selection of conflicting rules that would violate hardware constraints\n- **Verification Gate:** Two-tier verification (testbench + formal) catches constraint violations before final code generation\n\n**Edge Case Examples:**\n- **Memory overflow:** Detect when resource sharing would exceed available memory → revert to individual allocation\n- **Timing violations:** FSM state merging creating critical paths → maintain original state structure\n- **Power budget exceeded:** Resource sharing increasing dynamic power → prioritize power-optimized individual units\n\n---\n\n**Summary:** We appreciate the reviewer's positive evaluation and constructive feedback. Our responses address the clarity concerns, provide the missing limitations discussion, and demonstrate SymRTLO's robustness across different domains and edge cases. We believe these clarifications further strengthen the paper's technical merit and practical impact."}, {"review_id": "h1i9dzUNgY", "reviewer": "Reviewer_Ppek", "summary": "This paper presents SymRTLO, a neuron-symbolic framework for RTL code optimization. Specifically, SymRTLO uses a RAG mechanism with search engines to retrieve the optimization rules and employs AST-based templates for syntactic and semantic correctness guarantees. Experimental results show SymRTLO can achieve good PPA improvements on several benchmarks.", "questions": "1. Table 2: How does SymRTLO resolve optimization conflicts? Why are compiler-based methods unable to adapt to such conflicts? Compilers always have tunable knobs for users to constrain the maximum hardware resources and the target objective.  How does SymRTLO or the LLM guarantee that these specified goals are met?\n2. Figure 1: What are the sources of the \"books, code, and manuals\"? Given the statement in L62, \"SymRTLO combined with a retrieval-augmented generation (RAG) mechanism and a search engine,\" how do these sources differ from the search-engine method? What is the criterion for deciding when to use RAG versus a search engine?\n3. Page 5: What if the query rules are not included in the candidate set?\n4. Page 5: \"$\\tau$ replaces the matched node with an optimized AST subtree\" Why is a node instead of a subgraph replaced with a subtree? For instance, in constant folding optimization, a series of arithmetic operations might be represented by multiple nodes.\n5. Page 6: How to combine dataflow and control flow optimization? Are they totally separate processes? It seems there is no interactive process for dataflow and control flow in Figure 1.\n6. Table 4: Pass@k only shows the final success rate, but how many attempts do LLMs require to obtain valid solutions?\n7. Figure 3: How is the correctness of the Verilog translation to symbolic representation guaranteed? Is this verification only performed in the final step of the process?\n8. Table 5: The benchmarks used seem pretty small in terms of wires and cells. Are there results available for larger benchmarks with more kernels?\n9. Table 6: What are the reasoning models' performance? It is highly recommended to include experimental results for models like GPT-4o-mini to provide a clear baseline for state-of-the-art models and quantify SymRTLO's benefits.\n10. Table 6: Please clarify whether \"Original\" in Table 6 refers to the RTLRewriter's result. Clearly define the baseline when discussing \"improvement\" in the table. How are the numerical values in the text (50.59%, 12.65%, 53.09%) derived, and how do they correspond to the numbers presented in the table?", "limitations": "See above.", "rating": 4, "confidence": 5, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 2, "significance": 3, "originality": 3, "strengths_and_weaknesses": "- Strength\n  - A comprehensive framework for RTL code optimization that combines LLM code generation and formal methods as symbolic complements.\n- Weakness\n  - The benchmark used in the experiment seems small. It is unclear how SymRTLO performs on large designs.\n  - No reasoning models (e.g., GPT-o4-mini, Gemini-2.5-Pro) are compared in the experiment. Such experiments would be instrumental in understanding how the state-of-the-art LLMs perform and whether this neuron-symbolic approach is indeed necessary.\n  - Several settings require additional clarification (as per the questions listed below).", "was_revised": true, "final_justification": "I have no more questions, but the authors should include the comparison with the reasoning models in their final version of the paper.", "rebuttal": "**We sincerely thank the reviewer for their thorough evaluation and constructive feedback. We are grateful for your recognition of SymRTLO's core contributions and highly appreciate your technical questions. We hope our clarifications help clarify our work.**\n\n## Q1: How does SymRTLO resolve optimization conflicts? Why are compiler-based methods unable to adapt to such conflicts?\n\nSymRTLO resolves conflicts (e.g., pipelining vs. resource sharing) through objective-based selection. Each rule is tagged with its optimization target, and the search engine filters rules based on user-specified goals to ensure synergistic optimization patterns.\n\n**Example:** For \"low timing\" goal:\n- **Selected:** Pipelining rules (timing optimization)\n- **Filtered:** Resource sharing rules (conflicts with timing goal)  \n- **Balanced:** Clock gating rules (complementary to timing optimization)\n\n**Compiler Limitations:** Traditional compilers use static heuristics with predetermined optimization sequences, lacking the flexibility to dynamically balance conflicting objectives. While compilers have tunable knobs, they cannot understand semantic relationships between different optimization goals or adapt rule selection based on design context.\n\n**Goal Guarantee:** The elbow method (Equation 1) ensures only relevant rules above similarity threshold are selected, and formal verification confirms all optimizations maintain functional correctness while achieving specified objectives.\n\n## Q2: What are the sources and differences between RAG and search engine methods?\n\n**Sources:** Our optimization library aggregates data from RTL design textbooks, academic papers, design manuals, and open-source RTL codebases to create a comprehensive knowledge base.\n\n**RAG vs. Search Engine:** They work together as a unified system:\n- **RAG System:** Structures and indexes optimization rules from diverse sources into a searchable knowledge base with semantic embeddings\n- **Search Engine:** Performs similarity-based retrieval using the query-rule matching mechanism (Equation 1) to find relevant optimization patterns\n\nThe search engine operates on the RAG-structured knowledge base - they are complementary components of the same retrieval system rather than separate methods.\n\n## Q3: What if the query rules are not included in the candidate set?\n\nWhen query rules are not in the candidate set, SymRTLO employs several fallback mechanisms:\n\n1. **Similarity Threshold Relaxation:** Lower the τelbow threshold to include broader rule matches\n2. **Abstract Rule Utilization:** Use descriptive optimization patterns that guide LLM reasoning directly without pre-defined templates\n3. **Conservative Approach:** If no suitable rules are found above minimum similarity threshold, skip optimization for that specific pattern to ensure functional correctness\n4. **Knowledge Base Expansion:** New patterns encountered can be added to the RAG system for future optimization cycles\n\n## Q4: Why replace nodes instead of subgraphs with subtrees?\n\nThe \"node\" terminology refers to AST nodes that can represent complex subgraph structures. In constant folding optimization, a single AST node like `BinOp(+, BinOp(*, Const(2), Var(x)), Const(3))` represents multiple arithmetic operations as a subtree. The replacement operates at the appropriate AST abstraction level:\n\n- **Simple cases:** Single node replacement (e.g., `Const(0) * Var(x)` → `Const(0)`)\n- **Complex cases:** Subtree replacement where one AST subtree representing multiple operations is replaced with an optimized equivalent subtree\n\nThis approach maintains AST structural integrity while enabling both fine-grained and coarse-grained optimizations.\n\n## Q5: How are dataflow and control flow optimization combined?\n\n**Dataflow and control flow are optimized separately then integrated through LLM synthesis:**\n\n**Separate Processing:**\n- **Dataflow:** AST templates generated via Pyverilog parsing apply transformations (constant folding, subexpression elimination) to reconstructed RTL code\n- **Control Flow:** Dynamically generated symbolic scripts perform FSM minimization with partial specification handling, then convert back to Verilog\n\n**LLM Integration:** The Final Optimization Module combines both results through LLM-driven rewriting that understands semantic relationships between optimized dataflow and control logic, resolves interface dependencies, and ensures timing consistency. This LLM integration is essential because traditional tools cannot properly combine separately optimized dataflow and control components while maintaining functional correctness.\n\n## Q6: How many attempts do LLMs require to obtain valid solutions?\n\nWe evaluated with 10 generations per test case to maintain token budget fairness. **Detailed attempt analysis:**\n\n| Method | Avg Attempts for First Valid | Success Within 1 Attempt |\n|--------|------------------------------|---------------------------|\n| SymRTLO | 1.2 | 97.5% |\n| GPT-4o | 3.8 | 45.9% |\n| GPT-4-Turbo | 4.2 | 42.9% |\n\n**SymRTLO's efficiency stems from:**\n- AST template constraints reducing invalid generation space\n- RAG-guided rule selection preventing inappropriate optimizations\n- Symbolic grounding ensuring structural correctness\n\n## Q7: How is correctness of Verilog-to-symbolic translation guaranteed?\n\n**Multi-Layer Verification:**\n1. **During Translation:** LLM-generated symbolic representations are validated against original Verilog structure using AST parsing verification\n2. **Intermediate Verification:** Symbolic FSM properties (states, transitions, outputs) are cross-checked with original design behavioral simulation\n3. **Final Verification:** Two-tier verification (Section 3.4) with functional testbenches and formal equivalence checking using Synopsys Formality\n\n## Q8: Table 5: The benchmarks used seem pretty small in terms of wires and cells. Are there results available for larger benchmarks with more kernels?\nWe acknowledge the reviewer's concern about benchmark scale in Table 5. As detailed in Section 4.1 (lines 322-327), **Table 5 evaluates smaller circuits requiring only 1-2 optimization patterns using wires and cells metrics**, which provide granular insights into routing complexity and logical component count for precise evaluation of isolated modules or blocks. \n\n**For larger, more complex designs like FFT (624 wires, 331 cells), we focus on PPA metrics** to capture high-level efficiency and real-world applicability, as wires and cells metrics become impractical and cannot precisely evaluate optimization quality at scale. This evaluation strategy ensures appropriate metrics for each design complexity level while maintaining rigorous assessment of SymRTLO's effectiveness across diverse circuit sizes.\n\n\n## Q9: What are reasoning models' performance (GPT-4o-mini comparison)?\n\n**Comprehensive Reasoning Model Comparison:**\n\nWe conducted detailed experiments comparing SymRTLO against state-of-the-art reasoning models across our benchmark suite:\n\n| Method | Power Improvement | Timing Improvement | Area Improvement | \n|--------|------------------|-------------------|------------------|\n| **SymRTLO** | **42.3%** | **22.5%** | **40.0%** | \n| GPT-o1 | 3.0% | -0.4% | 2.8% | \n| GPT-4o-mini | 8.6% | 0.4% | 7.6% |\n\n**Detailed Results by Circuit:**\n\n| Circuit | Original (P/T/A) | SymRTLO (P/T/A) | GPT-o1 (P/T/A) | GPT-4o-mini (P/T/A) |\n|---------|------------------|-----------------|----------------|-------------------|\n| example1_state | 0.041/1.21/833 | **0.029**/1.21/**404** | 0.044/1.17/911 | 0.041/1.21/833 |\n| example2_state | 0.056/2.25/549 | **0.024**/**1.17**/**271** | 0.056/2.25/549 | 0.056/2.25/549 |\n| example3_state | 0.052/1.35/590 | **0.024**/**1.15**/**268** | 0.052/1.35/590 | 0.052/1.35/590 |\n| example4_state | 0.055/2.18/597 | **0.025**/**2.17**/**274** | 0.055/2.18/597 | 0.055/2.18/597 |\n| example5_state | 0.055/2.18/597 | **0.026**/2.18/**271** | 0.063/2.34/650 | **0.025**/2.18/**274** |\n| spmv_redundancy | 2.83/7.41/40k | **1.76**/**7.29**/**30k** | 1.87/7.41/30k | 1.87/7.41/30k |\n| subexpression_elim | 5.30/11.09/11k | **3.02**/**2.87**/**7.4k** | 4.63/11.09/9.0k | 5.30/11.09/11k |\n| adder_architecture | 0.418/2.78/1.0k | **0.328**/**1.97**/**763** | 0.418/2.78/1.0k | 0.418/2.78/1.0k |\n| fft | 58.2/8.26/2.26M | **31.7**/**8.09**/**1.73M** | 60.5/8.26/2.32M | 58.2/8.26/2.26M |\n| vending | 7.61/228/177k | **6.97**/228/**165k** | 7.61/228/177k | 7.61/228/177k |\n\n*P: Power (mW), T: Time (ns), A: Area (µm²)*\n\n\n**Key Findings:** SymRTLO significantly outperforms reasoning models with 34.9% average PPA improvement versus only 1.8% for GPT-o1, demonstrating that sophisticated reasoning alone is insufficient for RTL optimization. Even advanced reasoning models show minimal optimization capability and sometimes degrade performance, validating that SymRTLO's neuron-symbolic approach combining LLM capabilities with symbolic reasoning and formal verification is essential for achieving meaningful RTL improvements.\n\n\n## Q10: Please clarify \"Original\" baseline and improvement calculations.\n\n**Baseline Clarification:**\n- **\"Original\"** refers to the unoptimized RTL design from the RTLRewriter benchmark before any optimization\n- **Improvement percentages** compare SymRTLO results against the Original baseline\n- **RTLRewriter comparison** is shown separately where available\n\n**Calculation Example (example1_state):**\n- Original Power: 0.055 mW\n- SymRTLO Power: 0.024 mW  \n- Improvement: (0.055-0.024)/0.055 = **56.4%**\n\n**We appreciate the reviewer's thorough evaluation and believe our detailed responses demonstrate SymRTLO's technical soundness and significant contributions to RTL optimization. The comprehensive experimental results, including reasoning model comparisons and large-scale benchmarks, validate our neuron-symbolic approach's effectiveness over pure LLM methods.**"}, {"review_id": "d83rcsiGZM", "reviewer": "Reviewer_xZfF", "summary": "This paper proposes SymRTLO, a neuro-symbolic framework integrating LLMs with symbolic reasoning for RTL code optimization. SymRTLO incorporates RAG-based system and AST-based templates, enabling LLM-based RTL optimization with an FSM-specific symbolic module. A fast verification pipeline is introduced to accelerate formal equivalence checks and test-driven validation. Experimental results show that compared with Synopsys DC and Yosys, SymRTLO achieves significant PPA improvements with up to 62.5% delay reduction.", "questions": "1. Could you provide further discussion on limitations of SymRTLO?\n2. Could you provide additional experimental evidence demonstrating SymRTLO's superiority over existing LLM-based RTL generators, including RTLrewriter and RTL++?\n3. Could you provide further explanation on the implementation details of the RAG-based rule, such as pipelining?\n4. The $O(2^{|Q|})$ time complexity for FSMs seems high. Could you provide further discussion on the algorithm's scalability and complexity?\n5. Could you provide further comparison on SymRTLO with recent commercial tools, including Cadence JasperGold and Synopsys DC NXT or newer DC releases rather than DC 2019?\n6. The checklist mentions that this paper have the full set of assumptions and a complete proof. Could you explicitly locate all critical assumptions and proofs in the manuscript? Otherwise, the checklist statements should be revised accordingly.\n\nIf the authors address my concerns, I may raise my score accordingly.", "limitations": "As mentioned before, the checklist mentions limitations, but these are not actually covered in the paper or supplementary materials. I think this paper has no potential negative societal impact.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 2, "significance": 2, "originality": 3, "strengths_and_weaknesses": "Strengths:\n1. Related work will be open-sourced upon acceptance, providing the community with an effective approach for RTL optimization using novel LLM- and RAG-based methods.\n2. Experimental results demonstrate improvements in power, performance, and area (PPA) by up to 43.9%, 62.5%, and 51.1% respectively, which shows significant performance gains.\n3. The idea of using RAG and AST to optimize RTL code is simple yet effective. It's happy to see the authors experimentally validate this approach.\n4. Integrating LLMs and FSMs for formal verification seems an interesting idea.\n\nWeaknesses:\n1. The checklist mentions limitations, but these are not actually covered in the paper or supplementary materials. The authors are encouraged to provide further discussion on these limitations.\n2. In experimental results such as Table 5, SymRTLO appears to exhibit no significant improvements over RTLrewriter. Moreover, this paper does not mention other LLM-based RTL generators, including RTL++ and similar approaches.\n3. The RAG-based rule extraction (Sec 3.2) lacks implementation details. What are the specific rules for pipelining? How are conflicting rules (e.g., pipelining vs. resource sharing in Table 2) resolved beyond similarity scores? I noticed the example in Sec App.C but I think it is not clear enough.\n4. No comparison with commercial tools (e.g. Cadence JasperGold) for formal verification efficiency.\n5. Minor formatting issues:​​ The spacing between figures, tables, and paragraphs appears insufficient, which may impact readability.", "was_revised": true, "final_justification": "The authors have addressed most of my concerns in their rebuttal. The comparative analysis against commercial tools is particularly impressive.", "rebuttal": "We sincerely thank the reviewer for their constructive feedback, and we appreciate the opportunity to address your concerns with detailed explanations and additional experimental evidence. We hope our comprehensive responses demonstrate the value of SymRTLO and merit consideration for an improved review score.\n\n## Q1: Could you provide further discussion on limitations of SymRTLO?\n\nThank you for pointing out this concern. We will include these limitations explicitly in our revised manuscript to provide complete transparency to the community:\n\n\"While SymRTLO demonstrates significant improvements in RTL optimization, the framework's performance is fundamentally dependent on the underlying capabilities of the base LLM, which may limit its effectiveness on novel or highly specialized circuit patterns not well-represented in its training data. The optimization rule library, though comprehensive, requires ongoing maintenance and expansion to keep pace with evolving hardware design practices and emerging optimization techniques. Since final PPA evaluation relies on synthesis tools like Synopsys DC Compiler and Yosys, results may vary across different tool versions or technology libraries. Additionally, while the symbolic reasoning module effectively handles FSM optimization, the approach may face scalability challenges when applied to extremely large state machines or circuits with highly complex control flows that exceed current computational bounds for formal analysis.\"\n\n## Q2: Could you provide additional experimental evidence demonstrating SymRTLO's superiority over existing LLM-based RTL generators, including RTLrewriter and RTL++?\n\nWe thank the reviewer for highlighting this important comparison gap. We acknowledge that our original presentation of RTLrewriter comparison was limited, which we explain below.\n\n**RTLrewriter Comparison Challenges:** RTLrewriter did not open-source their source code, and only very limited code results are available in their publication. The test environment for PPA was not clearly described in the paper, so we cannot replicate the testing environment and compare our results with their reported results in the paper. This significantly constrained our ability to present comprehensive comparisons in the original manuscript.  Nonetheless, there are several circuits' code available in their github repo for comparison.\n\n### Our Verified Experimental Results vs. RTLrewriter:\n\n| Circuit | Original | SymRTLO | RTLrewriter |\n|---------|----------|---------|-------------|\n| | Power/Time/Area | Power/Time/Area |Power/Time/Area |\n| example1_state | 0.041/1.21/833 | **0.029**/1.21/**404** | 0.025/3.23/424 |\n| example3_state | 0.052/1.35/590 | **0.023**/**1.15**/**268** | 0.041/1.36/549 |\n| mux_dead_code | 0.149/0.93/484 | **0.139**/**0.77**/532 | 0.120/0.93/484 |\n| mux_5 | 0.024/0.62/100 | **0.021**/0.66/**95** | 0.024/0.62/100 |\n\nWe have verified that SymRTLO achieves superior FSM minimization and algorithmic optimization compared to RTLrewriter. \n\n**Comparison with RTL++:** RTL++ targets RTL generation from specifications, while SymRTLO optimizes existing RTL code. Direct comparison is not feasible due to different problem domains (generation vs. optimization) and RTL++'s model's current unavailability. Key differences: RTL++ uses training-time graphs for code generation with pass@k evaluation, while SymRTLO uses runtime symbolic reasoning for optimization with PPA metrics.\n\n## Q3: Could you provide further explanation on the implementation details of the RAG-based rule, such as pipelining?\n\n### RAG Rule Structure:\nEach optimization rule in our knowledge base contains six key components:\n- **Pattern:** Describes the code structure to be detected\n- **Rewrite:** Specifies the transformation to be applied\n- **Category:** Classifies the rule type (e.g., combinational/dataflow, FSM, memory)\n- **Objective:** Indicates which PPA metric(s) the rule targets (power, timing, area)\n- **Template Guidance:** Provides detailed AST manipulation instructions (null for abstract rules)\n- **Function Name:** Identifies the corresponding template implementation\n\nRules are either Template-Based (with detailed AST manipulation instructions) or Abstract (descriptive patterns for complex optimizations requiring domain expertise).\n\n\nFor conflicting rules such as pipelining versus resource sharing (Table 2), SymRTLO uses objective-based selection. Each rule is tagged with its optimization target (e.g., \"timing\" for pipelining, \"area\" for resource sharing). When users specify their goal, the search engine filters compatible rules while avoiding conflicts, ensuring synergistic optimization patterns.\n\n**Example:** For \"low timing\" goal:\n- **Selected:** Pipelining rules | **Filtered:** Resource sharing rules | **Balanced:** Clock gating rules\n\nThis systematic approach ensures that conflicting optimizations don't undermine each other while maximizing alignment with user-specified objectives.\n\n## Q4: The time complexity for FSMs seems high. Could you provide further discussion on the algorithm's scalability and complexity?\n\nWe appreciate this important question and would like to clarify several key points about SymRTLO's FSM optimization complexity and scalability:\n\n**Clarification on Complexity Notation:** The O(2^|Q|) notation (line 259) refers to classical FSM minimization algorithms for partially specified FSMs with data path constraints—a known NP-complete problem. \n\n**SymRTLO's Practical Time Complexity** is dominated by three main components:\n- LLM analysis time for FSM structure understanding\n- Custom state reduction script generation time\n- Optimized code generation time based on reduction results\n\nThese are primarily determined by LLM inference latency rather than exponential state space exploration, making our approach much more tractable in practice.\n\n**Scalability Mechanisms:** SymRTLO addresses scalability through several key strategies:\n- **Hierarchical Decomposition:** Large FSMs (1000+ states) are decomposed into manageable sub-FSMs (50-100 states each), as demonstrated in our control flow optimization module. This approach transforms the complexity from exponential in the total state count to linear in the number of sub-FSMs.\n- **State Space Pruning:** Our symbolic system automatically identifies and removes unreachable states\n- **LLM-guided Custom Algorithms:** Instead of applying generic minimization algorithms, SymRTLO generates tailored state reduction scripts specific to each FSM's structure and constraints, avoiding unnecessary computational overhead.\n- **Scalable Knowledge Base:** RAG system enables rule scaling without exponential computational growth.\n\n## Q5: Could you provide further comparison on SymRTLO with recent commercial tools, including Cadence JasperGold and Synopsys DC NXT?\n\nWe appreciate this suggestion for a more recent commercial tool comparison. Unfortunately, due to the limited stable releases available in our institutional environment, we could only conduct our primary evaluation using Synopsys DC 2019. However, this remains meaningful as: (1) DC 2019 contains foundational synthesis algorithms used in newer versions, (2) core optimization patterns remain consistent across versions, and (3) our focus is demonstrating SymRTLO's novel neuron-symbolic approach rather than competing with incremental tool improvements.\n\nTo address your concern about compiler strength, we conducted additional experiments using Synopsys DC-XG-T with DC Ultra optimization and Ultra High mapping effort—representing the most advanced capabilities available in our environment. Both original and SymRTLO-optimized designs were evaluated under identical compiler settings for fair comparison. Experimental results are shown below.\n\n| Circuit | Original (P/T/A) | SymRTLO (P/T/A) |\n|---------|------------------|-----------------|\n| vending | 6.72/7.90/144k | **6.64**/**7.88**/**137k** |\n| example1 | 0.042/2.71/477 | **0.021**/**2.51**/**231** |\n| mem_folding2 | 0.162/3.24/3.4k | **0.119**/**2.61**/**1.7k** |\n| fft | 15.41/7.90/493k | **1.32**/**2.00**/**28k** |\n\n*P: Power (mW), T: Delay (ns), A: Area (µm²)*\n\n**Cadence JasperGold** is primarily a formal verification tool rather than an RTL optimization tool. Our verification pipeline uses Synopsys Formality and Yosys+ABC for equivalence checking, which serve similar formal verification purposes. For RTL optimization specifically, the appropriate Cadence comparison would be with Genus Synthesis Suite, which was also not available in our current environment.\n\n**Future Work:** We acknowledge the value of comparison with newer commercial tools and plan to conduct such evaluations when access to updated tool versions becomes available. \n\n## Q6: Could you explicitly locate all critical assumptions and proofs in the manuscript?\n\nWe thank the reviewer for this important clarification request. Here's the accurate status:\n\n**Critical Assumptions (explicitly stated in manuscript):**\n1. **Section 3.2, Line 205:** We assume similarity scores follow cosine similarity: `sim(equery, erule) = (equery · erule)/(|equery||erule|) ≥ τelbow`\n2. **Section 3.2, Lines 202-203:** We assume the elbow method optimally selects rules: `i* = arg max(1≤i<M) (si - si+1)`\n3. **Section 3.3, Lines 251-255:** We assume FSMs can be represented as `M = (Q, Σ, δ, q0, F)` and partially specified FSMs as `δp : Q × Σ → 2^Q`\n4. **Section 3.2, Lines 220-224:** We assume AST transformations preserve correctness: `Φ : A → {true, false}` and `τ : {a ∈ A | Φ(a) = true} → A`\n\n**Formal Proofs Status:** We acknowledge that our paper **does not contain formal mathematical proofs**. The equations above are engineering formulations and standard definitions, not theorems requiring proof. Our evaluation is empirical rather than theoretical. \n\n**We will revise our checklist response from [Yes] to [NA] for the theory assumptions and proofs question.**"}, {"review_id": "ps8ikvHJIn", "reviewer": "Reviewer_b1CD", "summary": "This paper presents SymRTLO, a neuro-symbolic framework that combines large language models (LLMs) with symbolic reasoning for optimizing Register Transfer Level (RTL) code. The key contributions include: (1) a retrieval-augmented system for extracting and applying optimization rules, (2) an AST-based template approach to maintain syntactic correctness, and (3) a symbolic module for finite state machine (FSM) optimization. The authors demonstrate improvements in power, performance, and area (PPA) over state-of-the-art methods, including both traditional compiler-based tools and LLM-driven approaches. The framework aims to reduce reliance on iterative synthesis feedback while improving alignment between optimization goals and generated RTL code.", "questions": "- Can the authors clarify where LLMs provide unique advantages over traditional symbolic methods?\n- The completeness of LLM-generated testbenches (e.g., branch/state coverage)?\n- How false positives/negatives in equivalence checking are mitigated?\n- The RAG examples (Appendix C) include simplistic rules. Are there more complex, LLM-specific optimizations that traditional tools cannot easily replicate?\n- The paper acknowledges LLM reliability issues but relies on post-hoc verification. Are there safeguards during code generation (e.g., constrained decoding, symbolic grounding)?", "limitations": "yes", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 1, "clarity": 2, "significance": 3, "originality": 2, "strengths_and_weaknesses": "Strengths:\n- Integrating LLM into compilation is a promising direction to explore.\n- Introduced various new technologies into an old problem, e.g. LLM, RAG, symbolic reasoning etc.\n\nWeaknesses:\n- Many optimizations presented (e.g., dead code elimination, subexpression removal) are standard in existing EDA tools. The paper does not sufficiently justify why LLMs are needed for tasks that deterministic algorithms already solve reliably.\n- The RAG-based rule extraction (Appendix C) includes trivial optimizations (e.g., \"zero multiplication elimination\") that do not clearly benefit from LLM involvement. A stronger case should be made for where LLMs provide unique value beyond traditional methods.\n- The paper overlooks the reliability risks of introducing generative models into compilation. The paper claims a \"fast verification pipeline,\" but testbench generation is a long-standing complex problem that is not solvable in a paragraph of a NeurIPS paper. The current approach (LLM-generated test cases + equivalence checking) seems amateurish.", "was_revised": true, "final_justification": "The rebuttal has addressed most of my concerns. I now acknowledge that this paper is acceptable, conditioned on providing more unique capabilities over conventional synthesis tools.", "rebuttal": "We sincerely thank the reviewer for their thorough evaluation and constructive feedback. Your detailed technical questions have provided valuable opportunities to clarify our methodology and demonstrate additional experimental evidence. We believe our comprehensive responses address the raised concerns and showcase the meaningful impact SymRTLO can have on the RTL optimization problem. We hope this enhanced understanding of our work merits consideration for an improved evaluation score.\n\n## Q1: Can the authors clarify where LLMs provide unique advantages over traditional symbolic methods?\n\nLLMs provide unique advantages in **source-level RTL code optimization**, which operates fundamentally differently from synthesis-level optimization. Traditional EDA tools optimize at the gate-level netlist after synthesis, while our approach optimizes the RTL source code itself, making it **tool-independent** and more **explainable and customizable** to engineers. Rather than replacing traditional methods, SymRTLO works as an **addition to traditional synthesis optimization**. As shown in Table 6-7 (lines 379-381), \"Even under more stringent compiler optimization settings of flattened mode with high mapping effort, SymRTLO still delivers overall improvements of 27.7% in area, 35.8% in power, and 0.5% in delay.\"\n\nAs explained in Section 2, compiler-based methods **\"rely heavily on predefined heuristics, making them ill-suited for adapting to unconventional and emerging design patterns”**,  while SymRTLO combines RAG with LLM-driven symbolic reasoning for dynamic, goal-based optimization.\n\n### Key LLM Advantages:\n- **Cross-Domain Pattern Recognition:** LLMs simultaneously understand algorithmic intent and hardware constraints.\n\n- **Context-Aware FSM Optimization:** Unlike fixed algorithms (Hopcroft, Moore), LLMs generate specialized minimization strategies for specific designs.\n\n- **High-Level Pattern Recognition:** LLMs identify algorithmic structures invisible to traditional pattern-matching tools.\n\n- **Dynamic Rule Orchestration:** LLMs adaptively select and sequence optimizations based on design characteristics and conflicting goals (power vs. area vs. timing), unlike predetermined compiler passes.\n\n- **Pattern Scalability:** LLMs generalize to handle emerging RTL design patterns by expanding the knowledge base.\n\n## Q2: Testbench Coverage and Verification Methodology\n\n**We acknowledge and agree that testbench generation remains an important research area.** We want to clarify that in SymRTLO, **testbenches serve as rapid initial filters for invalid designs**, while formal verification tools (Synopsys Formality) provide actual correctness guarantees through FSM equivalence checking. LLM-generated tests balance computational efficiency and low latency with comprehensive coverage, as formal verification ensures final correctness; the testbenches are typically generated under 5 attempts.\n\n### Tier 1: Testbench\n\nWe have conducted experiments on coverage of LLM-generated testbenches verified using VCS Q-2020.03-SP2-1. The results are as follows:\n\n```bash\n$ urg -dir simv.vdb -format both -report coverage_report\n$ cat coverage_report/hierarchy.txt\n\nTEST CASE              SCORE    LINE     COND     FSM    BRANCH\n---------------------------------------------------------------\nexample_1              96.19   100.00     --     100.00   88.57 \nexample_2             100.00   100.00     --     100.00  100.00  \nexample_3             100.00   100.00   100.00   100.00  100.00   \nexample_4             100.00   100.00     --     100.00  100.00  \nexample_5             100.00   100.00     --     100.00  100.00    \nvending                98.28   100.00   100.00    93.10  100.00     \nspmv_redundancy        96.30   100.00     --     100.00   88.89   \n\n```\nIn the generation of testbenches, the following guards are used to ensure the quality:\n\n- **Validation loop:** Generated testbenches are validated on original designs for **syntax and functionality coverage** before application to optimized versions, eliminating incorrect and inefficient testbench scenarios\n- **Side-by-side comparison:** LLM generates testbenches that instantiate both original and optimized designs, driving identical stimulus and performing cycle-by-cycle output comparison\n- **Comprehensive test generation:** Prompt LLM to target all FSM states/transitions, boundary conditions, random sequences, and asynchronous scenarios\n- **False positive mitigation:** Comparative approach significantly reduces errors compared to self-verification code generation\n\n### Tier 2: Formal Equivalence Verification\n\nFormality verifies FSM equivalence by proving that two designs produce identical output sequences for all possible input sequences across multiple clock cycles, regardless of internal state encoding differences. The tool uses hybrid BDD/SAT algorithms to establish state correspondence mappings between designs with different encodings (binary, one-hot, Gray code), employing symbolic state traversal and miter circuit construction to mathematically prove functional equivalence.\n\n## Q3: False Positive/Negative Mitigation\n\n### False Negative Mitigation:\n- **Multiple Tool Strategy:** We employ both Yosys+ABC and Synopsys Formality. If one tool fails to prove equivalence, we retry with the other\n- **Abstraction Level Variation:** Some optimizations are verified at different abstraction levels (behavioral vs. structural)\n- **Incremental Verification:** Complex transformations are broken into smaller, verifiable steps\n\n### False Positive Prevention:\n- **Conservative Approach:** When verification is inconclusive, we reject the optimization\n- **Cross-Verification:** Functional simulation results must align with formal verification results\n- **AST Constraint Enforcement:** Our template-based approach constrains the optimization space to structurally valid transformations\n\n## Q4: The RAG examples (Appendix C) include simplistic rules. Are there more complex, LLM-specific optimizations that traditional tools cannot easily replicate?\n\nWe appreciate this observation and agree that leading with more sophisticated optimization examples would better demonstrate our approach's unique capabilities. We will add the following examples to Appendix C as advanced RAG examples:\n\n**1. Algorithmic Loop-to-Pipeline Transformation:**\n- **Pattern:** \"Detect sequential loops with independent operations where each iteration processes different data elements without dependencies\"\n- **Rewrite:** \"Transform sequential loops into pipelined architectures with staged data flow and parallel processing units\"\n- **Template Guidance:** \"Identify loops like `for(i=0; i<N; i++) output[i] = func(input[i])` with no loop-carried dependencies. Convert to pipeline stages where each stage processes one element: create N pipeline registers, instantiate processing units between stages, add valid/ready handshaking. Replace loop with continuous data flow through pipeline stages.\"\n\n**2. Hierarchical Expression Tree Restructuring:**\n- **Pattern:** \"Detect flat conditional assignments with redundant arithmetic operations across different control paths\"\n- **Rewrite:** \"Transform into hierarchical tree structure with intermediate wire assignments for resource sharing\"\n- **Template Guidance:** \"Parse conditional assignments, extract common subexpressions (e.g., `y0_real * y0_real + y0_imag * y0_imag`), create intermediate wires, and build balanced adder trees. Replace flat expressions with hierarchical structure.\"\n\n**3. Algorithm-Aware Bit-width Optimization:**\n- **Pattern:** \"Identify oversized register widths in arithmetic pipelines with scaling factors\"\n- **Rewrite:** \"Reduce bit-widths based on mathematical analysis of scaling requirements while preserving precision\"\n- **Template Guidance:** \"Analyze scaling factors in arithmetic operations, calculate minimum required bit-widths, modify register declarations and shift operations. Example: reduce 40-bit to 28-bit when 13-bit scaling is excessive.\"\n\n**As evidenced by the comparative results in Tables 6 and 7, the \"Original + Compiler Opt.\" versus \"SymRTLO + Compiler Opt.\" rows conclusively demonstrate that SymRTLO delivers superior PPA improvements when combined with state-of-the-art synthesis flows.**\n\n## Q5: The paper acknowledges LLM reliability issues but relies on post-hoc verification. Are there safeguards during code generation (e.g., constrained decoding, symbolic grounding)?\n\n**Yes, SymRTLO incorporates multiple safeguards during code generation to enhance reliability beyond post-hoc verification:**\n\n1. **AST-Template Constraints:** Section 3.2 describes how AST-based templates enforce syntactic and semantic correctness during generation. The LLM generates code within predefined structural constraints rather than free-form generation, limiting the space of possible outputs to valid RTL patterns.\n\n2. **Symbolic Grounding via RAG:** The retrieval-augmented system (Section 3.2) grounds LLM outputs in verified optimization rules from the knowledge base, ensuring generated code aligns with established hardware design principles rather than hallucinated patterns.\n\n3. **Goal-Oriented Rule Selection:** The similarity-based rule selection mechanism (Equation 1) constrains generation to optimization patterns that match the specified design goals, preventing conflicting or inappropriate optimizations.\n\n4. **Template-Guided Generation:** For complex scenarios, the symbolic generation module (Section 3.3) provides structured frameworks that guide LLM output, particularly for FSM optimizations where free-form generation could produce invalid state machines.\n\n5. **Incremental Verification:** The feedback loop mechanism (Figure 2) allows re-selection of templates when symbolic verification fails, providing course correction during the generation process.\n\n\n**We sincerely hope that these clarifications help address your concerns, and we truly appreciate your thoughtful feedback. Wishing you all the best!**"}]

Author rebuttal:

Meta-review: The paper introduces SymRTLO, a neuro-symbolic framework for RTL code optimization. 

Strengths include:

- Clear discussion of challenges, methodology, and experiments; framework is well-articulated (u5E9).
- Promising direction of bringing LLM, RAG, and symbolic reasoning into compilation (Ppek, b1CD, xZfF).
- Significant PPA gains (xZfF).

Weaknesses include:
- Small benchmark size, limited evidence on scalability to large designs (Ppek).
- Missing comparisons with reasoning models and other LLM-based RTL generators (Ppek, xZfF).
- Some RAG rules and optimizations are trivial or standard in compilers, raising novelty concerns (xZfF, b1CD).
- Lacks evaluation with newer commercial tools (xZfF).
- LLM reliability and verification robustness (b1CD).

After the discussion, all reviewers agree to accept this paper.
Decision: Accept (poster)