Pith. sign in

REVIEW 5 major objections 5 minor 28 references

GoGoTB claims a fully automated RTL verification loop: complete test environments for eight chip designs, 100% generation success, and specification-grounded coverage averaging 83.2%, with no human intervention.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 00:33 UTC pith:ECZEP4YU

load-bearing objection GoGoTB is a well-designed agentic verification pipeline, but its headline autonomy claim is undercut by an opaque reference model and withheld artifacts. the 5 major comments →

arxiv 2607.26181 v1 pith:ECZEP4YU submitted 2026-07-28 cs.AI

GoGoTB: Agentic RTL Verification with Specification-Grounded Coverage Closure

Xin Xin , Jincheng Lou , Junhui Li , Jinglin Yan , Panda Xiao , Di Wu , Haixiao Li , Weicong Lu
show 6 more authors
Weijian Fan Xinyu Qu Yuxiang Zhao Min Yu Zhixiong Di Yibo Lin
This is my paper
classification cs.AI
keywords LLM agentsRTL verificationcoverage-driven verificationtestbench generationspecification-grounded coveragefunctional coverageagentic workflowdigital IC design
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

GoGoTB sets out to show that functional verification of small digital chip modules can be fully automated by an LLM-based agent, from reading the specification to producing an auditable coverage-closure report. The paper's central claim is that a single framework can generate a complete, runnable verification environment for every benchmark design—100% success across eight designs and seven LLM backends—and push line, branch, toggle, and specification-derived functional coverage to 98.4%, 97.2%, 97.0%, and 83.2% respectively. This matters because verification effort dominates chip front-end cost, and a missed bug that reaches silicon is enormously expensive to fix. If the claim holds, the bottleneck in automated verification shifts from environment construction and coverage modeling to the final directed-test-generation step, which the paper itself names as the remaining limitation.

Core claim

The discovery is that verification closure becomes tractable when coverage is grounded in the specification before simulation begins, rather than read off RTL signal ranges. GoGoTB decomposes the specification into testpoints across seven behavioral dimensions, converts each testpoint into a coverage bin that names a specification behavior, and then runs an agentic loop that diagnoses residual gaps using a seven-category root-cause taxonomy and applies a targeted remedy until no addressable cause remains. This is what turns residual coverage gaps from unexplained percentages into diagnosable, actionable items. The paper reports that this design, together with deterministic enforcement layers

What carries the argument

The load-bearing mechanism is the three-way split between deterministic control and LLM reasoning. An execution control layer wraps every tool call, stage boundary, and repair attempt: layer 1 guards, structures, and validates each tool interaction; layer 2 enforces hard/soft quality gates between pipeline stages; layer 3 escalates failed repairs through four scopes. A two-tier knowledge system dispatches methodology skills deterministically by stage and historical reference environments only when structural similarity is high. The coverage closure subsystem anchors every bin to a named specification behavior, classifies residual gaps into seven root causes (stimulus, sequence, cross-coverag

Load-bearing premise

The system assumes that a correct reference model exists for every design and is supplied as an input; if that oracle is wrong, incomplete, or human-written, the reported environment-success and coverage numbers no longer measure autonomous verification quality.

What would settle it

Independently re-run the released framework on the same eight benchmarks with the same supplied reference models; a single design that fails to produce a runnable environment with nonzero coverage, or a benchmark where swapping in a deliberately wrong reference model still yields high coverage, would refute the central claim.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • If the 100% environment-generation success holds across seven arbitrary LLM backends, then reliability comes from the control architecture, not from any single model's capability, so the result should transfer to future LLMs without redesign.
  • If specification-grounded coverage closure is sound, then every residual coverage gap has a root-cause label and a sign-off report, enabling auditability that signal-range coverage cannot offer.
  • The UART ablation—knowledge system off yields 0% functional coverage, on yields 75.3%—implies domain-knowledge injection is necessary, not optional, for protocol-style designs.
  • The reported gap between high code coverage (around 97–98%) and lower functional coverage (83.2%) implies the remaining bottleneck is LLM-generated directed tests for multi-step protocol scenarios, as the paper concludes.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the claim holds, the reference model could itself be generated by the same pipeline from the specification alone, removing the remaining human input; the paper currently assumes a supplied reference model, so a natural extension is to measure how oracle errors affect coverage.
  • Specification-grounded coverage raises the possibility of cross-design reuse: testpoints named by behavior rather than signal ranges could transfer from one implementation of the same protocol to another, making verification of protocol families cheaper.
  • The seven-category root-cause taxonomy could be turned into a predictor of LLM failure modes; counting residual gaps by category across many designs would show which test-generation capabilities need improvement first.
  • Because the benchmark suite is small (8 designs, 291–1,424 lines), the headline numbers should be read as evidence for the architecture's viability on module-scale designs, not yet for full SoC-level verification.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. The paper presents GoGoTB, an agentic framework for RTL verification that combines an agentic execution control layer, an evolvable knowledge system, and specification-grounded coverage closure. The system takes RTL source, a natural-language specification, and a reference model as input and runs an eight-stage pipeline (S1–S8) to generate a verification environment, produce coverage models whose bins are tied to named specification behaviors, and iteratively close coverage gaps via a seven-category root-cause taxonomy. The headline empirical claims are 100% environment generation success across 8 designs and 7 backbone LLMs, with average line/branch/toggle/functional coverage of 98.4%/97.2%/97.0%/83.2%, all without human intervention. The paper also reports two case studies: a UART experiment where disabling the knowledge system drops functional coverage to 0%, and an I2C experiment where root-cause-guided closure improves functional coverage from 56.0% to 84.1%.

Significance. If the results hold, GoGoTB would be a meaningful advance: it would be the first system to close a full verification loop for small RTL modules with LLM agents, producing runnable environments, specification-anchored coverage, and an auditable closure process. The architecture is thoughtfully described, and the separation of deterministic enforcement from LLM reasoning is a plausible and potentially reusable idea. The paper also makes concrete, falsifiable claims and reports per-design numbers. However, the empirical core is currently not independently verifiable: code, benchmarks, specifications, reference models, and generated environments are withheld; no repeated-run variance is reported for stochastic LLM backends; and the functional-coverage metric is computed against bins generated by the same pipeline that is being scored. These issues affect the central claims, not peripheral details.

major comments (5)
  1. [§3.1, §3.2, §4.1] The provenance of the reference model is inconsistent and load-bearing. §3.1 says GoGoTB 'takes RTL source, a natural-language specification, and a reference model as input'; §4.1 says all experiments 'provide a reference model as input'; but §3.2 states 'The reference model is derived from the specification alone and has no visibility into RTL implementation details.' If the reference model is externally supplied and possibly human-authored, then the 'without any human intervention' claim is inaccurate and the scoreboard oracle is outside the pipeline. If it is derived by the system, the paper gives no mechanism, no validation, and no guarantee against RTL leakage. Since every scoreboard check and all coverage numbers depend on this oracle, the authors must state clearly which of these is the case and provide evidence (e.g., generated reference-model code, spec-only derivation logs, or
  2. [§3.4, Table 3] The headline functional-coverage number is self-authored in a way that is not currently auditable. S1–S2 derive testpoints, S3 converts them into coverage bins, S6 generates the tests, and S8 scores those tests against the same bins. The paper even states that 'structurally unreachable bins are removed from the denominator' (§3.4), but provides no rule for determining structural unreachability and no example. This means the 83.2% average functional coverage could be adjusted by bin construction or by denominator excision. The authors must release the exact bin definitions, the removal rule and which bins were removed, and the full coverage database for each design. Without this, the functional-coverage claim is not a meaningful, independently checkable metric.
  3. [§4.1, Fig. 5, Table 3] No repeated-run variance is reported for stochastic LLM-based generation. The paper claims 100% SRG 'across all seven backbone LLMs' and reports average coverage numbers, but it does not state how many independent runs were performed for GoGoTB, whether the same design/backbone combination was run more than once, what the seed policy was, or what the dispersion across runs was. LLM outputs are stochastic, and coverage values like 98.4%, 97.2%, etc. are presented without confidence intervals or min/max ranges. For the central claims to be credible, the authors must report per-run results, or at least the number of runs and the observed variance, for both SRG and coverage.
  4. [§4.1, §4.3] The empirical claims are not independently verifiable because the artifacts are withheld. The paper states that 'The complete GoGoTB framework and its evaluation benchmark of 8 open-source RTL designs will be open-sourced at a later date' (§4.1), but no code, benchmark specifications, generated testbenches, coverage models, or logs are provided. In addition, the 'No prior work ... on the same benchmarks' claim is only partially supported: AES and ALU come from UVM2, but the other six designs are selected by the authors from open-source repositories, so 'same benchmarks' is not established. The authors should release the benchmark suite, the exact natural-language specifications, the reference models, and the generated environments, or the results cannot be checked by the community.
  5. [§3.4] The completeness of the testpoint decomposition is asserted without support. The paper claims that the seven behavioral dimensions D1–D7 'cover all verifiable behavior types in a design specification' (§3.4), but no proof, independent validation, or inter-rater study is provided. This is load-bearing because the testpoint set 'establishes the ceiling on verification completeness' (§3.4). The authors should at least provide a mapping procedure from specification statements to testpoints, a discussion of how ambiguous or underspecified behaviors are handled, and some evidence that independent verification engineers would produce substantively similar testpoint sets.
minor comments (5)
  1. [Table 1] Typo: 'Seqence Gap' should be 'Sequence Gap'.
  2. [Fig. 5] The figure appears to mix a heatmap of build times with a matrix of times; it is hard to read. Consider a separate table with per-design, per-backend build times and a clear notation for the 'All' row.
  3. [§4.4] The phrase '0 .5×BAUD_PERIOD' has an odd spacing; should be '0.5×BAUD_PERIOD'.
  4. [§4.2, Eq. (2)] The SRG metric uses 'cov>0' as a success condition. Since coverage can be nonzero even for a meaningless stimulus, the metric is permissive; a brief note on why nonzero coverage is a sufficient criterion would be helpful.
  5. [References] Reference [23] points to Chinese-language IDE documentation; please provide an English version or a stable DOI/archive link if available.

Circularity Check

3 steps flagged

Functional-coverage score is self-authored: the same pipeline generates the bins, scores against them, and removes missed bins from the denominator; reference-model provenance is also inconsistent.

specific steps
  1. self definitional [Section 3.4 (S2–S3, S8); Section 4.1 (Metrics)]
    "S2 derives testpoints across seven behavioral dimensions. ... S3 converts each one into a coverage model element where every bin carries a named behavioral claim traceable to the specification. ... S8 classifies each uncovered bin and directs it to the targeted remedy. Structurally unreachable bins are removed from the denominator. ... Functional coveragereports the fraction of specification-derived bins hit after stochastic simulation."

    The reported functional-coverage percentage is taken over bins that the GoGoTB pipeline itself generated at S2–S3, and then the closure stage S8 can remove difficult bins by declaring them 'structurally unreachable' and excluding them from the denominator. There is no independent, fixed coverage model against which the system is scored. The same LLM pipeline defines the targets, evaluates itself against those targets, and may shrink the target set when bins are missed. Thus the headline 83.2% measures how well the system hits goals it set for itself, not how much of an externally specified behavior space was verified; the number is an artifact of the system's own goal construction rather than a prediction against independent ground truth.

  2. other [Section 3.1, Section 3.2 (Boundary Enforcement), Section 4.1 (Experimental Setup)]
    "GoGoTB takes RTL source, a natural-language specification, and a reference model as input. ... All experiments run fully automated without human intervention and provide a reference model as input. ... The reference model is derived from the specification alone and has no visibility into RTL implementation details."

    The central claims of 'without any human intervention' and 100% environment-generation success are conditional on a reference model supplied as an input. Section 4.1 states the experiments 'provide a reference model as input,' while Section 3.2 asserts that the reference model 'is derived from the specification alone.' The paper gives no mechanism for automatically deriving the reference model from the specification, so it may be human-authored. If it is human-authored, the scoreboard's pass/fail criterion encodes externally supplied expected behavior, and the environment-success and coverage numbers are measured against a human-built oracle rather than produced by the pipeline itself. The paper never resolves this inconsistency, so the autonomy claim is not self-contained.

  3. self definitional [Section 3.4 (S1–S2)]
    "S1 parses the RTL and specification into a design profile. S2 derives testpoints across seven behavioral dimensions."

    The testpoints that define the functional-coverage bins are derived with visibility into the RTL, not from the specification alone. The paper elsewhere describes the contribution as 'specification-grounded coverage closure' and states that every bin is 'anchored to a named specification behavior.' Because the target set is constructed with knowledge of the implementation under test, achieving high coverage against those targets is partly a measure of the system's ability to set targets conditioned on the RTL, rather than an independent measure of specification compliance. This reinforces the self-authored nature of the coverage metric.

full rationale

The most concrete circularity is in the coverage metric itself. The pipeline generates testpoints and coverage bins (S1–S3), generates stimuli aimed at those bins (S6–S7), and then in S8 removes 'structurally unreachable' bins from the denominator before reporting final functional coverage. This is a self-defined target set: the same agentic system writes the exam, takes the exam, and can mark questions as undeliverable. Consequently, the headline 83.2% functional coverage is not a prediction against a fixed external benchmark; it is a self-referential measurement, fitting the 'self_definitional' pattern. A second, closely related issue is the reference model. The paper lists a reference model as an input and reports experiments that 'provide a reference model as input,' yet also claims it is 'derived from the specification alone.' Without a described mechanism or validation, this is an unresolved inconsistency in the load-bearing oracle: if the reference model is human-authored, the 'no human intervention' claim is unsupported and the scoreboard is externally seeded. This is not a self-citation problem; the paper does not rely on load-bearing self-citations or imported uniqueness theorems. Code coverage (line, branch, toggle) is measured by the simulator against the actual RTL and is therefore external to the pipeline, which is why the score is not higher. Overall, the central functional-coverage and autonomy claims are partially circular, warranting a score of 6 rather than a lower non-circularity score.

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 2 invented entities

The central claims rest on a small set of domain assumptions: that spec-derived testpoints are complete, that seven behavior dimensions exhaust all verifiable behaviors, that unreachable bins can be safely removed, and that a correct reference model is available as input. The hand-chosen loop thresholds (stall patience, retry counts, gate softening) are not fitted to data but do affect the reported convergence and coverage. The framework itself introduces taxonomies and coverage constructs that are internally defined and have no independent evidence outside the paper.

free parameters (3)
  • Stall-detector patience = 2 consecutive rounds
    S8 terminates the closure loop after two consecutive rounds with no improvement. This hand-chosen threshold directly determines the final reported coverage (e.g., I2C stops at 84.1%).
  • Retry threshold = 3 identical command failures
    Layer 1 injects a redirect prompt after the same command fails three times in a row. Hand-set threshold controlling loop convergence.
  • Quality-gate softening schedule
    Layer 2 Soft Gate blocks on failure in early attempts and softens to a warning as attempt count rises; the exact schedule is not specified, so SRG outcomes depend on unstated parameters.
axioms (5)
  • domain assumption Testpoint completeness sets a hard ceiling on verification quality.
    Section 2.1 and S1–S2: any behavior not enumerated as a testpoint cannot be verified downstream; GoGoTB's coverage claims inherit this ceiling.
  • ad hoc to paper The seven behavioral dimensions D1–D7 cover all verifiable behavior types in a design specification.
    Section 3.4 S2 states this without formal justification; if a behavior lies outside the taxonomy, the coverage model is incomplete by construction.
  • domain assumption Structurally unreachable bins can be identified and safely removed from the coverage denominator.
    Section 3.4 S8: no independent criterion or count is given; removing bins directly inflates functional coverage.
  • domain assumption A correct reference model can be derived from the specification alone and has no visibility into RTL implementation details.
    Section 3.2 Boundary Enforcement; all experiments provide a reference model as input (Section 4.1). If the oracle is incomplete, pass/fail decisions are unreliable.
  • standard math Autoregressive LLM sampling follows Eq. (1).
    Section 2.2 Eq. (1): standard probabilistic definition of token generation; not contested and not used to derive the empirical results.
invented entities (2)
  • Seven-category root-cause taxonomy (Stimulus Gap, Sequence Gap, Cross Hole, State Unreached, Timing Dependent, Transition Gap, Seed Insufficient) no independent evidence
    purpose: Classifies every residual coverage gap in S8 and routes it to a targeted remediation remedy.
    No external validation that the taxonomy is complete or that the LLM classifier labels gaps accurately; misclassification would route the wrong remedy.
  • Seven behavioral dimensions D1–D7 no independent evidence
    purpose: Defines the testpoint inventory in S2 and therefore the hard ceiling on verification completeness.
    Asserted to cover all verifiable behavior types, but no independent audit is provided; completeness is assumed and cannot be checked from the paper.

pith-pipeline@v1.3.0-alltime-deepseek · 11185 in / 13717 out tokens · 135888 ms · 2026-08-01T00:33:04.809569+00:00 · methodology

0 comments
read the original abstract

Functional verification dominates integrated circuit (IC) front-end engineering effort, and a single missed bug that escapes to silicon can trigger a costly respin. Recent large language models (LLMs) offer new opportunities to automate this process, yet existing LLM-based approaches generate each component through independent single-turn calls with no shared context, leaving interface mismatches undetected and reported coverage disconnected from specification requirements. To address these challenges, we present GoGoTB, an agentic framework that achieves end-to-end verification closure through three subsystems: an agentic execution control layer, an evolvable knowledge system, and specification-grounded coverage closure. The execution control layer separates deterministic enforcement from LLM reasoning at every tool and stage boundary. The knowledge system dispatches methodology and design-specific expertise on demand. The coverage framework anchors every bin to a named specification behavior so that each residual gap has a diagnosable root cause and a targeted remedy. Tested on 8 register transfer level (RTL) designs without any human intervention, GoGoTB achieves 100\% environment generation success and averages 98.4\% line, 97.2\% branch, 97.0\% toggle, and 83.2\% functional coverage. No prior work successfully generates a complete verification environment or achieves meaningful coverage on the same benchmarks.

Figures

Figures reproduced from arXiv: 2607.26181 by Di Wu, Haixiao Li, Jincheng Lou, Jinglin Yan, Junhui Li, Min Yu, Panda Xiao, Weicong Lu, Weijian Fan, Xin Xin, Xinyu Qu, Yibo Lin, Yuxiang Zhao, Zhixiong Di.

Figure 1
Figure 1. Figure 1: Four-level verification coverage hierarchy. Prior [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: GoGoTB is an eight-stage agentic framework built on three subsystems. It includes agentic execution control, an evolvable knowledge system, and specification-grounded coverage closure. missed, so the loop stalls without convergence. Tying every cov￾erage bin to a named specification behavior solves both problems. Each gap then has a root cause and a targeted remedy, making con￾vergence achievable. As shown… view at source ↗
Figure 4
Figure 4. Figure 4: Two-tier evolvable knowledge system. The Skill [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Environment generation success rate and build time [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: CS1: Three silent failures (left) caused by missing [PITH_FULL_IMAGE:figures/full_fig_p007_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: CS2: I2C coverage progression and root-cause dis [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

28 extracted references · 2 linked inside Pith

  1. [1]

    IEEE Standard for Universal Verification Methodology Language Reference Manual.IEEE Std 1800.2-2017(2017), 1–472

    2017. IEEE Standard for Universal Verification Methodology Language Reference Manual.IEEE Std 1800.2-2017(2017), 1–472. doi:10.1109/IEEESTD.2017.7932212

    arXiv 2017

  2. [2]

    Harry D. Foster. 2015. Trends in functional verification: a 2014 industry study. InProceedings of the 52nd Annual Design Automation Conference(San Francisco, California)(DAC ’15). Association for Computing Machinery, New York, NY, USA, Article 48, 6 pages. doi:10.1145/2744769.2744921

    arXiv 2015

  3. [3]

    2003.Writing Testbenches: Functional Verification of HDL Models

    Janick Bergeron. 2003.Writing Testbenches: Functional Verification of HDL Models. Springer, Boston, MA, USA. doi:10.1007/978-1-4615-0302-6

    doi:10.1007/978-1-4615-0302-6 2003

  4. [4]

    2008.SystemVerilog for Verification: A Guide to Learning the Testbench Language Features

    Chris Spear. 2008.SystemVerilog for Verification: A Guide to Learning the Testbench Language Features. Springer

    2008

  5. [5]

    Ruidi Qiu, Grace Li Zhang, Rolf Drechsler, Ulf Schlichtmann, and Bing Li. 2024. AutoBench: Automatic Testbench Generation and Evaluation Using LLMs for HDL Design. InProceedings of the 2024 ACM/IEEE International Symposium on Machine Learning for CAD(Salt Lake City, UT, USA)(MLCAD ’24). Association for Computing Machinery, New York, NY, USA, Article 18, 1...

    arXiv 2024

  6. [6]

    Ruidi Qiu, Grace Li Zhang, Rolf Drechsler, Ulf Schlichtmann, and Bing Li. 2025. CorrectBench: Automatic Testbench Generation with Functional Self-Correction using LLMs for HDL Design. In2025 Design, Automation & Test in Europe Con- ference (DATE). 1–7. doi:10.23919/DATE64628.2025.10992873

    arXiv 2025

  7. [7]

    Junhao Ye, Yuchen Hu, Ke Xu, Dingrong Pan, Qichun Chen, Jie Zhou, Shuai Zhao, Xinwei Fang, Xi Wang, Nan Guan, and Zhe Jiang. 2025. From Concept to Practice: an Automated LLM-aided UVM Machine for RTL Verification. In 2025 IEEE/ACM International Conference On Computer Aided Design (ICCAD). 1–9. doi:10.1109/ICCAD66269.2025.11240679 arXiv:2504.19959

    arXiv 2025

  8. [8]

    Zhiyuan Yan, Wenji Fang, Mengming Li, Min Li, Shang Liu, Zhiyao Xie, and Hongce Zhang. 2025. AssertLLM: Generating Hardware Verification Asser- tions from Design Specifications via Multi-LLMs. InProceedings of the 30th Asia and South Pacific Design Automation Conference(Tokyo, Japan)(ASP- DAC ’25). Association for Computing Machinery, New York, NY, USA, 6...

    arXiv 2025

  9. [9]

    Fenghua Wu, Evan Pan, Rahul Kande, Michael Quinn, Aakash Tyagi, David Kebo Houngninou, Jeyavijayan Rajendran, and Jiang Hu. 2025. Spec2Assertion: Auto- matic Pre-RTL Assertion Generation using Large Language Models with Progres- sive Regularization. arXiv:2505.07995 [cs.AR] https://arxiv.org/abs/2505.07995

    Pith/arXiv arXiv 2025

  10. [10]

    Marcelo Orenes-Vera, Margaret Martonosi, and David Wentzlaff. 2023. Using LLMs to Facilitate Formal Verification of RTL. arXiv:2309.09437 [cs.AR] https: //arxiv.org/abs/2309.09437

    Pith/arXiv arXiv 2023

  11. [11]

    Hongduo Liu, Yuntao Lu, Mingjun Wang, Xufeng Yao, and Bei Yu. 2026. LLM- Assisted Circuit Verification: A Comprehensive Survey. In2026 31st Asia and South Pacific Design Automation Conference (ASP-DAC). 439–446. doi:10.1109/ ASP-DAC66049.2026.11420692

    arXiv 2026

  12. [12]

    Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. InThe Eleventh International Conference on Learning Representations. https://openreview.net/forum?id=WE_vluYUL-X

    2023

  13. [13]

    Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, Wayne Xin Zhao, Zhewei Wei, and Jirong Wen. 2024. A survey on large language model based autonomous agents.Frontiers of Computer Science18, 6 (2024), 186345. doi:10.1007/s11704- 024-40231-1

    doi:10.1007/s11704- 2024

  14. [14]

    Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. Reflexion: Language agents with verbal reinforcement learn- ing.Advances in Neural Information Processing Systems36 (2023), 8634–8652

    2023

  15. [15]

    2005.Comprehensive functional verification: The complete industry cycle

    Bruce Wile, John Goss, and Wolfgang Roesner. 2005.Comprehensive functional verification: The complete industry cycle. Morgan Kaufmann

    2005

  16. [16]

    2008.Functional verification coverage measurement and analysis

    Andrew Piziali. 2008.Functional verification coverage measurement and analysis. Springer

    2008

  17. [17]

    2023.VCS Functional Verification Solution

    Synopsys, Inc. 2023.VCS Functional Verification Solution. Synop- sys, Inc. https://www.synopsys.com/content/dam/synopsys/gated-assets/ verification/vcs-ds.pdf Official datasheet. Accessed: 2026-04-01

    2023

  18. [18]

    2023.Xcelium Logic Simulator

    Cadence Design Systems, Inc. 2023.Xcelium Logic Simulator. Cadence Design Systems, Inc. https://www.cadence.com/content/dam/cadence-www/global/ zh_CN/documents/tools/system-design-verification/secured/xcelium-logic- simulator-ds.pdf Official datasheet. Accessed: 2026-04-01

    2023

  19. [19]

    2025.Welcome to cocotb’s Documentation!cocotb

    cocotb contributors. 2025.Welcome to cocotb’s Documentation!cocotb. https: //docs.cocotb.org/ Version 2.0.1. Accessed: 2026-03-21

    2025

  20. [20]

    The Verilator Project

    The Verilator Project 2026.Verilator Documentation. The Verilator Project. https://veripool.org/verilator/documentation/ Version 5.024. Accessed: 2026-04- 01

    2026

  21. [21]

    Yuchen Hu, Junhao Ye, Ke Xu, Jialin Sun, Shiyue Zhang, Xinyao Jiao, Dingrong Pan, Jie Zhou, Ning Wang, Weiwei Shan, Xinwei Fang, Xi Wang, Nan Guan, and Zhe Jiang. 2025. UVLLM: An Automated Universal RTL Verification Framework using LLMs. In2025 62nd ACM/IEEE Design Automation Conference (DAC). 1–7. doi:10.1109/DAC63849.2025.11435108 arXiv:2411.16238

    arXiv 2025

  22. [22]

    Zixi Zhang, Balint Szekely, Pedro Gimenes, Greg Chadwick, Hugo McNally, Jianyi Cheng, Robert Mullins, and Yiren Zhao. 2025. LLM4DV: Using Large Language Models for Hardware Test Stimuli Generation. In2025 IEEE 33rd Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM). 133–137. doi:10.1109/FCCM62733.2025.00048 arXiv:2310.04535

    arXiv 2025

  23. [23]

    2025.CodeBuddy Documentation: IDE User Guide Overview

    Tencent Cloud. 2025.CodeBuddy Documentation: IDE User Guide Overview. Tencent Cloud. https://www.codebuddy.ai/docs/zh/ide/User-guide/Overview Official documentation. Accessed: 2026-04-01

    2025

  24. [24]

    Tim Rudy. 2020. uart-verilog. https://github.com/TimRudy/uart-verilog GitHub repository. Accessed: 2026-04-01

    2020

  25. [25]

    Alex Forencich. 2017. verilog-i2c. https://github.com/alexforencich/verilog-i2c GitHub repository. MIT License. Accessed: 2026-04-01

    2017

  26. [26]

    Joachim Strömbergson. 2013. sha256. https://github.com/secworks/sha256 GitHub repository. BSD-2-Clause License. Accessed: 2026-04-01

    2013

  27. [27]

    gongxunwu. 2020. sm4-verilog. https://github.com/gongxunwu/sm4-verilog GitHub repository. Accessed: 2026-04-01

    2020

  28. [28]

    2012.DE0-Nano SDRAM Controller

    Terasic Inc. 2012.DE0-Nano SDRAM Controller. Terasic Inc. https://www.terasic. com.tw/cgi-bin/page/archive.pl?Language=English&No=593 Official reference design archive. Accessed: 2026-04-01

    2012