Paper deep dive
UCAgent: An End-to-End Agent for Block-Level Functional Verification
Junyue Wang, Zhicheng Yao, Yan Pi, Xiaolong Li, Fangyuan Song, Jinru Wang, Yunlong Xie, Sa Wang, Yungang Bao
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 99%
Last extracted: 3/31/2026, 1:32:14 AM
Summary
UCAgent is an end-to-end autonomous agent designed to automate block-level functional verification of hardware designs. It addresses the limitations of LLMs in generating Verilog/SystemVerilog by utilizing a pure-Python verification environment (via Picker and Toffee), a configurable 31-stage fine-grained workflow with automated checkers, and a Verification Consistency Labeling Mechanism (VCLM) to ensure traceability and reliability across the verification lifecycle.
Entities (5)
Relation Signals (4)
UCAgent → builton → LangChain
confidence 100% · Built upon the LangChain framework
UCAgent → implements → VCLM
confidence 100% · we propose a Verification Consistency Labeling Mechanism (VCLM)
UCAgent → utilizes → Picker
confidence 100% · we utilize Picker to convert the DUT into a Python package
UCAgent → utilizes → Toffee
confidence 100% · leverage the Toffee to provide high-level verification abstractions
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Functional verification remains a critical bottleneck in modern IC development cycles, accounting for approximately 70% of total development time in many projects. However, traditional methods, including constrained-random and formal verification, struggle to keep pace with the growing complexity of modern semiconductor designs. While recent advances in Large Language Models (LLMs) have shown promise in code generation and task automation, significant challenges hinder the realization of end-to-end functional verification automation. These challenges include (i) limited accuracy in generating Verilog/SystemVerilog verification code, (ii) the fragility of LLMs when executing complex, multi-step verification workflows, and (iii) the difficulty of maintaining verification consistency across specifications, coverage models, and test cases throughout the workflow. To address these challenges, we propose UCAgent, an end-to-end agent that automates hardware block-level functional verification based on three core mechanisms. First, we establish a pure Python verification environment using Picker and Toffee to avoid relying on LLM-generated SystemVerilog verification code. Second, we introduce a configurable 31-stage fine-grained verification workflow to guide the LLM, where each stage is verified by an automated checker. Furthermore, we propose a Verification Consistency Labeling Mechanism (VCLM) that assigns hierarchical labels to LLM-generated artifacts, improving the reliability and traceability of verification. Experimental results show that UCAgent can complete end-to-end automated verification on multiple modules, including the UART, FPU, and integer divider modules, achieving up to 98.5% code coverage and up to 100% functional coverage. UCAgent also discovers previously unidentified design defects in realistic designs, demonstrating its practical potential.
Tags
Links
- Source: https://arxiv.org/abs/2603.25768v1
- Canonical: https://arxiv.org/abs/2603.25768v1
Trouble viewing inline? Open PDF directly →
Full Text
56,089 characters extracted from source content.
Expand or collapse full text
UCAgent: An End-to-End Agent for Block-Level Functional Verification Junyue Wang 1,2 Zhicheng Yao 1,2 Yan Pi 1,2 Xiaolong Li 1,2 Fangyuan Song 3 Jinru Wang 2 Yunlong Xie 1,2 Sa Wang †,1,2 Yungang Bao 1,2,3 1 State Key Lab of Processors, Institute of Computing Technology, CAS 2 University of Chinese Academy of Sciences 3 Beijing Institute of Open Source Chip wangjunyue24@mails.ucas.ac.cn Abstract Functional verification remains a critical bottleneck in modern IC development cycles, ac- counting for approximately 70% of total development time in many projects. However, traditional methods, including constrained-random and formal verification, struggle to keep pace with the growing complexity of modern semiconductor designs. While recent advances in Large Language Models (LLMs) have shown promise in code generation and task automation, significant challenges hinder the realization of end-to-end functional verification automation. These challenges include (i) limited accuracy in gen- erating Verilog/SystemVerilog verification code, (i) the fragility of LLMs when executing complex, multi-step verification workflows, and (i) the difficulty of maintaining verification consistency across specifications, coverage models, and test cases throughout the workflow. To address these challenges, we propose UCAgent, an end-to-end agent that automates hardware block-level functional verification based on three core mechanisms. First, we establish a pure Python verification environment using Picker and Toffee to avoid relying on LLM-generated SystemVerilog verification code. Second, we introduce a configurable 31-stage fine-grained verification workflow to guide the LLM, where each stage is verified by an automated checker. Furthermore, we propose a Verification Consistency Labeling Mechanism (VCLM) that assigns hierarchical labels to LLM-generated artifacts, improving the reliability and traceability of verification. Experimental results show that UCAgent can complete end-to-end automated verification on multiple modules, including the UART, FPU, and integer divider modules, achieving up to 98.5% code coverage and up to 100% functional coverage. UCAgent also discovers previously unidentified design defects in realistic designs, demonstrating its practical potential. 1 Introduction Functional verification is the critical process of ensuring that a hardware design’s implementation correctly realizes its intended specification, making it the most resource-intensive phase of the IC design[1]. As hardware designs grow exponentially in complexity, however, verification has become a server bottleneck in terms of time, labor, and reliability. Industry studies indicate that verification now consumes over 70% of the total IC project timeline [2]. Consequently, the demand for verification engineers significantly outpaces that for design engineers, while designers themselves must spend nearly half of their work time to assist with verification [3]. Yet, these massive investments fail to guarantee reliable outcomes. In 2024, only 14% of projects achieved first-silicon success, and logic/functional defects remain the leading cause of costly re-spins [4], underscoring the urgent need for a highly automated verification paradigm. arXiv:2603.25768v1 [cs.SE] 26 Mar 2026 UCAgent: An End-to-End Agent for Block-Level Functional Verification The industry has historically relied on constrained random verification [5], formal verification [6], and hard- ware emulation. However, these techniques have merely maintained a fragile balance rather than fundamen- tally closing the gap between design complexity and verification capability [7]. Against this backdrop, both industry and academia have viewed AI-driven automated verification as a promising path to breaking the bottleneck. Major EDA vendors (e.g., Synopsys [8,9], Cadence [10–12], and Siemens [13,14]) have integrated AI into various stages of the verification flow, including assertion generation, coverage closure, and debugging. Concurrently, academia has explored the protential of using LLMs for specific tasks such as assertion generation [15–18], automated testbench generation [19–21], and coverage improvement [19–21]. Yet, these approaches mainly optimizespecific stagesof the verification process mentioned above, rather than automating the end-to-end verification process. Engineers are still required to orchestrate and integrate the distinct stages. Recent work has demonstrated the potential of LLMs for automated functional verification. Based on the verification language, these efforts can be broadly categorized into two paradigms: •SystemVerilog & UVM-based approaches:UVM² [22] uses a hybrid generation strategy combin- ing templates with LLMs to automatically generate UVM testbenches from design specifications and iteratively optimizes testcases using coverage feedback; MAVF [23] proposes a multi-agent collaboration architecture that decouples verification into multiple specialized stages, including specification parsing, verification planning, testbench specification generation, and code generation, with specialized agents executing them in sequence and validating effectiveness on real chip modules. •Python-based approaches:PRO-V [24] adopts a pure-Python generation strategy and achieves end- to-end RTL automated verification by combining it with an LLM-as-a-judge mechanism. While these efforts confirm that LLM-based verification can significantly reduce time and labor costs, they still exhibit limitations in workflow flexibility, execution reliability, and result traceability. To build an autonomous agent system that spans the entire verification flow, three core challenges must be addressed: Challenge 1: Limited accuracy of LLM-generated Verilog/SystemVerilog verification code. LLMs are less proficient at generating hardware description languages (HDLs; e.g., Verilog/SystemVerilog) compared to software languages like Python. This stems primarily from two factors: •Severe disparity in training data.LLMs rely on massive datasets for pattern learning, and data scale directly affects model’s performance. For example, in The Stack v2 [25], the largest open code dataset to date, Python accounts for 178.44 GB of data, while Verilog and SystemVerilog account for only 9.348 GB and 0.84 GB, respectively. This scarcity results in worse and less stable generation quality for HDLs. •Limited generation accuracy.Consequently, LLMs exhibit limited accuracy in Verilog/SystemVerilog and struggle with complex syntactic correctness [26,27]. Although many studies [28–31] have worked to improve generation quality, most focus on generating hardware design code. As a result, even state-of-the- art models struggle to consistently and stably generate syntactically correct and semantically consistent SystemVerilog verification code [32]. Challenge 2: Difficulty completing complex end-to-end verification tasks.The inherent complexity of functional verification requires processing massive volumes of design specifications, design/verification code and simulation reports, a sheer scale of information that easily exceeds the effective context window of current LLMs. In this setting, inherent issues of LLMs such as hallucination [ 33], context rot [34], and weak instruction following [35] are amplified, severely impacting the reliability and effectiveness of the verification outcomes. These limitations are particularly prominent in two aspects: •Information loss and error accumulation in complex task execution.Because functional verifi- cation stages are highly interdependent, any errors introduced in early phases (e.g., omitted constraints due to context loss, or syntactic flaws caused by hallucinations) accumulate rapidly and compromise the correctness of all subsequent stages. For instance, in existing work, MAVF requires multiple rounds of manual review and correction during testbench specification generation just to ensure later code genera- tion accuracy. Therefore, an automated checking and feedback mechanism is strictly needed to constrain and correct outputs at each individual stage. •Inadequacy of simple workflows for diverse verification scenarios.To manage the inherent com- plexity of functional verification, tasks are typically decomposed into sequential stages for LLM execution. However, the complexity of hardware modules varies significantly, rendering overly simple workflows inef- fective across diverse scenarios. For relatively simple designs (e.g., FIFOs or arithmetic units), interaction patterns are straightforward, allowing LLMs to directly generate stimuli and check output. Conversely, 2 UCAgent: An End-to-End Agent for Block-Level Functional Verification complex modules with strict ordering and dependency constraints (e.g., bus crossbars) require the genera- tion of pseudo-modules (mocks [36]) to interact properly with the DUT. Rudimentary workflows struggle with such sophisticated needs, often producing implementations with interface mismatches or behavioral deviations. For instance, existing frameworks like UVM² rely on predefined generation sequences that, while stable for standard interfaces, lack the dynamic adaptability required to orchestrate complex hard- ware interactions. Therefore, an effective and configurable workflow design is essential to ensure the successful completion of verification tasks across diverse scenarios Challenge 3: Maintaining verification consistency across the full flow is difficult.A robust functional verification process relies on strict traceability spanning thefunctional specification, thecoverage model, and thetestcase implementation. Specifically, every test point extracted from the specification must unambiguously map to corresponding covergroups and coverpoints, which are subsequently exercised by simulation stimuli. We formally define this unbroken semantic correspondence across verification goals, implementations, and results asVerification Consistency. It is the foundation for building a verification closed loop and ensuring traceability of results. However, LLMs often struggle to maintain this consistency. To illustrate this challenge, we use Qwen3-Coder-Plus to automate the translation from design specification into a feature list, and subsequently to a coverage model. As shown in Fig.1, two critical consistency failures emerge during this process. First, even when prompts explicitly require preserving the original terminology from the design specification, the LLM arbitrarily alters terms across these stages, causing severe naming inconsistencies. Second, the model hallucinates invalid verification scenarios that violate the actual design intent. Such failures sever the traceability, rendering the verification results unreliable. Existing methods remain insufficient in maintaining verification consistency. Specifically, PRO-V lacks a functional coverage model, failing to establish traceability from specification requirements to coverage metrics. UVM² relies solely on prompt-based constraints, lacking explicit mechanisms to guarantee output compliance. While MAVF builds a cross-reference matrix between test points and testcases, it lacks a comprehensive mechanism to sustain this consistency across the entire end-to-end verification flow. UART Spec ... LSR – Line Status Register The LSR provides status information ... bit0: Data Ready (DR) bit1: Overrun Error (OE) bit2: Parity Error (PE) bit3: Framing Error (FE) ... (no Underrun Error) ❌ Coverage Model CoverGroup rx_error_scenaro CoverPoint overflow; CoverPoint parity; CoverPoint framing; CoverPoint underrun; ...... Hallucination Feature List ...... x. UART Receiver Error Detection x.1. Overrun Error x.2. Parity Error x.3. Framing Error ...... Naming Inconsistency Figure 1:An example that violates verification consistency. The termoverrunis replaced with the seman- tically similaroverflow; additionally, anunderrunscenario is incorrectly added. Such a scenario typically does not appear in UART designs and is more common in modules like SPI and USB host controllers [37]. To address these challenges, we propose UCAgent, an end-to-end agent that automates hardware block-level functional verification based on three core mechanisms. First, we establish a pure-Python environment for the LLM to complete the verification tasks. Specifically, we utilize Picker [38] to convert the DUT into a Python packagePyDUT, and leverage the Toffee [39] to guide the LLM in constructing testbenches and generating testcases entirely in Python. By transforming the verification implementation from HDL development to Python generation, empowering the LLM to handle all verification activities efficiently. Second, we design a 31-stage fine-grained verification workflow to guide the LLM. It decomposes the ver- ification process into manageable steps, spanning from feature extraction to coverage modeling, testcase generation, and bug analysis. To mitigate inherent LLM issues such as context rot and hallucination, each stage incorporates automated checkers to validate results before the next stage. This step-by-step feedback mechanism effectively controls error accumulation, ensuring reliable and quality-controlled execution. 3 UCAgent: An End-to-End Agent for Block-Level Functional Verification Third, we propose aVerification Consistency Labeling Mechanism (VCLM)to ensure unbroken traceability across the entire workflow. By requiring the LLM to assign hierarchical labels to generated artifacts, including specifications, coverage models, and testcases, VCLM formalizes implicit semantic correspondences into explicit, machine-checkable constraints. This formalization maintains strict alignment with the original design intent. We evaluate UCAgent across diverse hardware modules, including UART, integer dividers, and ICache- WayLookup. Experimental results demonstrate that the agent successfully drives the entire verification lifecycle autonomously, achieving up to 98.5% code coverage and 100% functional coverage. Furthermore, UCAgent uncovers previously unidentified design defects in real-world verification scenarios, strongly vali- dating the effectiveness and practical value of our proposed paradigm. 2 Design Overview This section introduces the three core mechanisms integrated into UCAgent to address the above challenges. These mechanisms enable fully automated end-to-end functional verification while ensuring reliability. 2.The Verification Workflow Picker LLM 1.Python Verification Environment Verify Components Coverage Model Test Cases Task Inputs Outputs Toffee PyDUT Spec DUT 1. Analyse Spec 2. Insert Mock 3. Build Coverage Model 4. Build TestCases Check Testcase Check Feature List Check Coverage Artifacts Test Cases FG FC CK Feature List FG FC CK 3.VCLM Coverage Model FG FC CK Checkers PASS FAIL Error FeedBack Check Labels Figure 2:Relationships among UCAgent’s core mechanisms 2.1 Python Verification Environment To bypass the data-scarcity bottleneck of hardware description languages, UCAgent establishes a pure- Python environment for the LLM to complete end-to-end verification tasks. The primary limitation in current LLM-driven verification is the inability to reliably generate SystemVerilog (SV) verification code. While SV is the industry standard, the scarcity of high-quality SV corpora in pre-training datasets prevents LLMs from mastering its complex semantics. In contrast, LLMs demonstrate robust code-generation proficiency in Python [ 40]. Within this environment, we utilize Picker [38] to convert the DUT into a Python package (PyDUT), and leverage the Toffee to provide high-level verification abstractions. Picker is a verification assistance tool that converts RTL designs described in Verilog/SystemVerilog into libraries or packages in high-level pro- gramming languages. Tofee is a Python-based verification framework that provides higher-level features and abstractions on the top of Picker. This infrastructure abstracts hardware interactions, such as clock control, into simpler interfaces and sig- nificantly reduces dependency on simulation scheduling details like delta-cycles [41]. By shielding the LLM 4 UCAgent: An End-to-End Agent for Block-Level Functional Verification from these low-level timing intricacies, the agent can reliably drive the hardware using lightweight in-context learning [42]. The LLM interacts withPyDUTvia Toffee to construct testbenches and generate testcases. This execution is orchestrated by our fine-grained workflow and validated by stage-specific checkers alongside the Verification Consistency Labeling Mechanism (VCLM). Together, these components ensure syntactic correctness and maintain strict alignment with the design specifications, as illustrated in Fig.2. 2.2 The Verification Workflow Requirement Analysis Requirement Analysis and Planning DUT Function Understanding Functional Specification Analysis DUT Function Grouping Function Point Definition Check Point Design Verification Infrastructure Construction DUT Wrapper Implementation DUT Creation Pytest Fixture Creation Bundle Wrapper Design Mock Creation Mock Fixture Creation Mock Functional Test Env Fixture Implementation Evaluate Env Fixture Human Check Env Coverage and Verification Interface Construction Coverage Model Implementation Coverage Group Creation Coverage Point Creation Function Check Creation Basic API Implementation Basic API Test Testcase Development and Execution Verification Execute and Analysis Testcase Creation Testcase Template Creation Line Coverage Improvement Generate Random Testcase Review and Summary Test Environment Implementation Human Check Env Specification Mock Components Test Figure 3:The detailed verification workflow. Dotted stages indicate that they are skipped by default To manage the inherent complexity of hardware verification, UCAgent orchestrates the end-to-end process through a structured workflow. It decomposes the verification lifecycle into fine-grained stages and enforces strict quality control by assigning a dedicated automated checker to each stage. These stages cover the following aspects of the verification process: •Requirement analysis and functional decomposition, where the DUT behavior is interpreted and organized into structured verification targets. •Verification infrastructure construction, where the DUT, fixtures, signal wrappers, and an optional mock-based environment are prepared. •Coverage and verification interface construction, where functional intent is translated into exe- cutable coverage groups, checkpoints, and callable APIs. •Testcase development and execution, where test templates are instantiated, refined into executable tests, and further extended with bug-oriented analysis and optional randomized testing. The detailed stage breakdown is presented in Fig.3. 5 UCAgent: An End-to-End Agent for Block-Level Functional Verification The workflow splits the verification process into relatively independent stages, each with explicit inputs, de- terministic outputs, and checkable deliverables. For example, specification analysis must output a document with a precise label structure; coverage modeling must yield executable covergroup definitions; and testcase generation must produce simulation code that passes specific checks. To validate these deliverables, the checker mechanism encodes expert quality criteria into executable con- straint logic. Upon the completion of a stage, a dedicated checker evaluates the generated artifact against predefined rules. If the output fails to meet expectations, the checker returns concrete error messages to the LLM, guiding the model to iteratively self-correct and improving generation reliability. This 31-stage architecture was derived empirically by refining the workflow based on checker feedback. By analyzing checker-triggered retries and iteratively subdividing error-prone tasks, we ultimately converged on a fine-grained workflow that substantially reduced task complexity at each stage. Finally, to accommodate the diverse complexities of different hardware modules, this workflow is designed to be fully configurable. For instance, for modules with complex dependencies, a dedicated mock-generation stage can be inserted to replace the components on which the DUT depends. This configurable execution model ensures both efficiency and reliability across varied verification scenarios. 2.3 Verification Consistency Labeling Mechanism To address the difficulty of maintaining verification consistency across multiple stages, we propose the Verifi- cation Consistency Labeling Mechanism (VCLM). VCLM establishes a hierarchical labeling system compris- ing three distinct levels:FG,FC, andCK. UCAgent requires the LLM to consistently annotate these labels within the generated artifacts across three pivotal stages: functional specification analysis, coverage model construction, and testcase implementation. By embedding these labels into the outputs, VCLM transforms implicit design dependencies into structured, machine-checkable data. Stage-specific checkers systematically extract these labels to validate cross-stage consistency. If a generated artifact lacks the required labels or contains labels that fail to match those established in preceding stages, the checker rejects the output. It then returns precise error traces to the LLM, triggering an immediate self-correction cycle to restore traceability. Relying solely on natural language prompts, such as instructing the LLM to ”ensure the coverage model is consistent with the specification,” is inherently unreliable for complex hardware designs. In contrast, VCLM provides an explicit, formal carrier for verification intent. This structural constraint enforces strict behavioral boundaries on the LLM, fundamentally improving the reliability and traceability of the automated verification process, as illustrated in Fig. 2. 3 UCAgent Implementation Based on the proposed mechanisms, we implement the UCAgent system. As shown in Fig.4, UCAgent adheres to the principle of separation of concerns and comprises four independent modules. TheAgent Middlewaremanages LLM interactions, context construction, and task reasoning. TheWorkflow Management Moduleorchestrates the execution sequence of the configurable 31-stage workflow. TheStage Validation Moduleintegrates the automated checkers and VCLM to ensure output quality and cross-stage consistency. Finally, theVerification Execution Environmentprovides the Python-based infrastructure for test execution and hardware simulation. In the remainder of this section, we detail these four core modules in turn. 3.1 Agent Middleware TheAgent Middlewarebridges the LLM and the verification environment. Its primary function is to translate LLM reasoning into executable actions via tool calling [43]. Built upon the LangChain framework [44], this module unifies API access across various LLMs and constructs a centralVerifyAgent. Driven by a ReAct reasoning loop [45],VerifyAgenttranslates workflow task requirements into concrete tool-call sequences to perform operations such as specification analysis, code generation, and test execution. In addition to common tools such as file-system operations, the middleware integrates custom tools via the Model Context Protocol (MCP) [46]. These specialized tools fall into two primary categories: 6 UCAgent: An End-to-End Agent for Block-Level Functional Verification a. Agent Middleware LLMsCode Agents User Inputs Design Spec Verify Doc ...RTL c. Stage Validation Module Checkers 里ComponentTestCase ... b. Workflow Manage Module Stage Manager Parse Workflow Config . ├─ stage1 │ ├─ stage1.1 │└─ stage1.2 ├─ stage2 ③ Test Execution (tool calling) Check Fail VerifyAgent Observe Think Act Tool Result Tool Set Stage Manage Test Execution File Operation ... Tool Calling ① Fetch Current Stage d. Verification Execution Environment Result Python-based Infrastructure Test Cases ... DUT Testbench Pytest MCPAPI ④ Test Result VerifyStage VerifyStage VerifyStage Status Checker Check Pass Load Config Control ② Stage Prompt Manage Stage If Pass ⑥ Go to Next Stage ⑤ Complete Result Figure 4:UCAgent implementation overview •Workflow control tools.These tools expose the workflow management capabilities to the LLM, allow- ing it to query the current stage, trigger checks, and transition between stages. •Verification environment tools.These tools encapsulate underlying operations, enabling the LLM to compile designs, run tests, and retrieve simulation results. By adhering to the MCP standard, these tools can also be exposed as service interfaces. This interoperability allows external coding agents (e.g., Claude Code, Codex) to access UCAgent’s infrastructure, facilitating capability reuse and cross-agent collaboration. Operationally, the middleware executes tasks through an iterative loop:context fetching→LLM reasoning →tool execution→environment feedback. In each iteration, the LLM analyzes current stage requirements and historical results to determine the next action. If an error or failure is reported, the middleware captures this feedback and triggers a retry, allowing the LLM to dynamically adjust its strategy rather than strictly following a static script. Furthermore, the middleware supports human-in-the-loop intervention at critical steps, balancing automation efficiency with human controllability. 3.2 Workflow Management Module TheWorkflow Management Moduleorchestrates the execution sequence of the configurable 31-stage workflow. It strictly gates the progression of the LLM: the workflow can only advance to the subsequent stage when the current stage’s outputs pass all constraints enforced by theStage Validation Module. To ensure flexibility, the workflow is defined via a user-configurable YAML format. Each stage is indepen- dently configured with specific attributes, such as task descriptions, explicit output requirements, and bound checkers, natively supporting nested sub-stages for complex verification tasks. A critical design principle of this module is distinguishing stage-level goals from tool-level execution. While the agent-level ReAct loop manages the retries of individual tool calls, the workflow checkers validate whether the generated artifacts strictly satisfy the stage’s objectives before allowing the workflow to advance. As illustrated in Fig.5, the module has two core classes:VerifyStageandStageManager. •VerifyStageencapsulates the definition of a single verification node, integrating fields such as the stage name, task description, target output files, and corresponding checker instances. 7 UCAgent: An End-to-End Agent for Block-Level Functional Verification •StageManageracts as the centralized workflow engine. Upon initialization, it parses the YAML config- uration into a sequence ofVerifyStageobjects. During execution, it tracks the active stage index and processes stage-transition requests triggered by the LLM. To interface seamlessly with theAgent Middleware, the workflow manager exposes its control capabilities as standard tool calls. Tools such asGetCurrentTips(retrieve current task context),Check(trigger stage validation), andComplete(verify completion and advance) allow the LLM to actively perceive and navigate its progress without exposing the underlying scheduling implementation. Furthermore, the module implements the state persistence. At every stage transition, theStageManager serializes the current progress and execution telemetry (e.g., failure counts and execution time) into a state file. This mechanism not only permits interrupted tasks to resume precisely from the last completed stage but also provides the empirical data required for workflow refinement. As previously discussed, stages exhibiting high failure rates in this telemetry indicate that the LLM’s task boundaries are insufficiently constrained, guiding engineers to further subdivide or reorganize the workflow architecture. Workflow stage: - name: extract features tasks: - "1. You should read x" - "2. balabala..." checker: - name: "markdown_file_check" - class: "MarkdownFileFormat" stage: - name: build testbench tasks: - "..." - name: wrap dut - checker: - ... - name: coverage - ... checker: - name: "env_impl_check" ... Agent Middleware Verify Stage Stage Manager Current Stage GetCurrentTips Check Complete ⭕ Pass ✅ To next stage Stage Validation Parse Config Fail ❌ Figure 5:Workflow management module 3.3 Stage Validation Module TheStage Validation Moduleconsists of a collection of extensible checkers. Each checker automatically evalu- ates the LLM’s output for a given verification stage to ensure the deliverables meet predefined requirements. UCAgent provides a base checker class, enabling users to implement custom checkers tailored to specific needs. This supports various validation paradigms, including code-based automatic checks, LLM-based peer reviews, and human-in-the-loop judgments. As shown in Fig.4, the default workflow integrates checkers covering document formatting, testbench compilation, coverage models, and test reports. Furthermore, the module includes manual intervention checkers that pause the workflow, allowing verification engineers to review the results of critical stages before proceeding. 3.3.1 Implementation of VCLM To enforce cross-stage consistency, the Verification Consistency Labeling Mechanism (VCLM) employs a three-level hierarchical label structure: •Function Group (<FG->).It represents top-level categories of verification scenarios in the design specification. For instance, a floating-point ALU might define<FG-ARITHMETIC>for standard operations and<FG-WIDEN-ARITHMETIC>for widening operations. 8 UCAgent: An End-to-End Agent for Block-Level Functional Verification •Function Checkpoint (<FC->).It denotes concrete functional features within a group. Under <FG-ARITHMETIC>, examples include<FC-VFADD>(vector FP addition) and<FC-VFSUB>(vector FP sub- traction). •Check Point (<CK-*>).It defines specific verification conditions that must be covered. Under <FC-VFADD>, one might specify<CK-FP32>(FP32-precision addition),<CK-FP16>(FP16-precision ad- dition), and<CK-BF16>(BF16-precision addition). Because VCLM spans multiple workflow stages, it is implemented across a series of stage-specific checkers. Each checker parses the labels generated in its current stage and cross-references them against the label hierarchy established in preceding stages. 2. Functional Coverage Model 3. TestCase 4. Verification Report 1. Design Spec FloatAdder Specification <FG-ARITHMETIC>: Arithmetic operations of FloatAdder ... <FC-VFADD>: Implement the vector floating-point addition instruction to compute vs2 + vs1. Support FP32, FP16, and BF16 formats ... Checkpoints: - <CK-FP32> Verify addition operations in FP32 format. - <CK-FP16> Verify addition operations in FP16 format. - <CK-BF16> Verify addition operations in BF16 format. ... def covergroup_float_format(dut): """Create checkpoints for the FG- ARITHMETIC function group""" g = CovGroup("FG-ARITHMETIC") ... # FC-BF16-FORMAT g.add_watch_point(dut, "CK-FP32": is_fp32_vadd, "CK-FP16": is_fp16_vadd, ... , name="FC-VFADD") ... return g def test_fp32_vadd(env): """Test the FP32 format vector float addition""" env.dut.fc_cover["FG-ARITHMETIC"].mark_function \ ("FC-VFADD", ["CK-FP32"]) # Test 1.0 + 2.0 = 3.0 assert ... def test_fp16_vadd(env): """Test the FP16 format vector float addition""" env.dut.fc_cover["FG-ARITHMETIC"].mark_function \ ("FC-VFADD", ["CK-FP16"]) # Test 1.0 + 2.0 = 3.0 assert ... CovGroup: FG-ARITHMETIC Point: FC-VFADD CK-FP32 test_fp32_vadd14 .. CK-FP16 test_fp16_vadd 0 ... CK-BF16 Point: FC-x Bug Analysis: <FG-ARITHMETIC> <FC-VFADD> <CK-FP16> <BUG-X> In x, ... Figure 6:Results of verifying a vector floating-point addition module with VCLM As illustrated in Fig.6, a typical VCLM-enabled workflow operates as follows: •Specification Analysis Stage.The LLM assigns unique labels to each identified function point within the specification document. For example, a description of FP32 vector addition must be explicitly annotated with<FG-ARITHMETIC>,<FC-VFADD>, and<CK-FP32>. The checker validates label syntax (naming conventions and hierarchical completeness) and ensures a reasonable quantity (e.g., at least one function group). •Coverage Modeling Stage.When generating functional coverage definitions, the LLM must reuse the exact labels from the specification to name eachCoverGroup,CoverPoint, andBin. The checker parses the covergroup hierarchy, extracts the labels, and performs a bidirectional comparison against the specification’s label list. It flags labels present in the code but undefined in the specification (indicating hallucinations or naming mistakes), as well as labels defined in the specification but missing in the code (indicating implementation omissions). •Test Implementation Stage.During testcase generation, the LLM utilizes Toffee’smark_functionto explicitly declare which check points the current test function verifies. Post-simulation, the checker parses the execution report to validate that: (1) all marked check points exist in the specification document; (2) all check points defined in the specification are exercised by the tests; and (3) any check points associated with failing testcases are correctly logged in the bug analysis document. 9 UCAgent: An End-to-End Agent for Block-Level Functional Verification 3.4 Python-Based Verification Execution Environment TheVerification Execution Environmentprovides the runtime infrastructure for simulating the hardware design entirely within Python. Building upon thePyDUTboundary established in the infrastructure layer, this environment hosts the native Python testbench constructed dynamically by the LLM. To systematically construct and execute this testbench, UCAgent guides the LLM through a highly con- strained generation pipeline. Initially, the LLM leverages thetoffeeframework to encapsulatePyDUTinto high-level procedural func- tions and generates unit tests to validate these wrappers. This step effectively acts as an automated smoke test; if these foundational tests persistently fail despite LLM self-correction, the environment flags the as- sociated DUT functionality as a potential hardware bug. Following this, the LLM generates a functional coverage model using Toffee, mapping it directly to the predefined specification hierarchy. Finally, under the combined constraints of execution checkers and the VCLM, the LLM generates complex verification scenarios to drive the wrapped DUT. Each testcase explicitly links executed stimuli to target coverage points via Toffee, ensuring complete traceability. During the execution phase, the environment utilizes Pytest to run the testcases. It automatically extracts multi-dimensional execution metrics, including test pass rates, code coverage, and functional coverage. These metrics are fed back to the LLM as explicit environmental observations. This data-driven feedback loop enables the LLM to iteratively augment testcases to achieve coverage closure. Finally, the environment aggregates all execution metrics and verification artifacts to generate a comprehensive verification report. 4 Evaluation 4.1 Experimental Setup To evaluate the efficacy of UCAgent, we select five hardware modules, detailed in Table1. Among these, ALU754,IntegerDivider, andICache-Waylookupserve as pre-verified baselines, whereasLaneFAddand PageTableWalkerare previously unverified designs. All subjects are evaluated using UCAgent’s default automated workflow. For each module, the LLM is provisioned with the following inputs: •UCAgent’s built-in prompt templates. •Design documents for each module. •Verilog files for each module. Except for ALU754 and UART-16550, other modules are implemented in Scala, so corresponding Scala files are also provided. Excluding the PageTableWalker, we evaluate with the following models: •claude-sonnet-4-5-20250929 •gpt-5-2025-08-07 •qwen3-coder-plus-2025-09-23 For all models,TopPand temperature use default settings. 1 4.2 Overall Verification Effectiveness UCAgent successfully completes end-to-end automated verification for four modules. As shown in Fig.7, execution times vary significantly across models, ranging from 40 to 180 minutes. Notably, despite their smaller codebases, UART-16550 and ALU754 entail complex temporal and combinatorial interaction logic, thus requiring longer verification times. Conversely, the workflows for IntegerDivider and ICache-WayLookup are highly efficient, converging within 80 minutes for most models. Regarding code coverage, UCAgent performs optimally on IntegerDivider, exceeding 97% across all three models. Coverage for UART-16550 and ALU754 typically stabilizes in the 70%–80% range. For the highly complex ICache-WayLookup, coverage outcomes exhibit greater variance (55%–91%). 1 See:Claude Docs,OpenAI Docs, andQwen API Reference. 10 UCAgent: An End-to-End Agent for Block-Level Functional Verification Table 1:Modules verified with UCAgent ModuleLOCDescription UART 16550268Universal Asynchronous Receiver/Transmitter ALU754572IEEE-754 single-precision floating-point unit implemented with combinational logic IntegerDivider 1024RV32M integer divider based on radix-4 SRT algorithm LaneFAdd1283 RVV-compliant vector floating-point unit supporting FP32, FP16, and BF16 ICache-Waylookup 3483 Caches metadata queried from MetaArray and ITLB by IPrefetchPipe in the ICache for use by MainPipe PageTableWalker 155408 Handles L1/L2 page table access, performs step-by-step page table walks for virtual-to-physical translation, and forwards L3 page table access requests downstream (Last Page Table Walker) UART-16550ALU754IntegerDividerICache-WayLookup (a) Runtime 0 25 50 75 100 125 150 175 Minutes 133 110 45 76 180 60 47 80 130 40 47 80 UART-16550ALU754IntegerDividerICache-WayLookup (b) Code Coverage 0 20 40 60 80 100 Percentage (%) 79.7% 71.9% 98.5% 91.2% 93.3% 71.6% 97.3% 63.7% 70.3% 74.9% 98.5% 55.0% UART-16550ALU754IntegerDividerICache-WayLookup (c) Coverage Bins Count 0 50 100 150 200 250 Count 268 60 82 139 189 39 26 37 90 38 43 46 UART-16550ALU754IntegerDividerICache-WayLookup (d) Functional Coverage (by bin) 0 20 40 60 80 100 Percentage (%) 96.3% 86.7% 100.0%100.0% 98.4% 100.0% 100.0%100.0% 94.4% 92.1% 100.0% 73.9% claude-sonnet-4.5gpt5qwen3-coder-plus Figure 7:UCAgent evaluation results In evaluating functional coverage, UCAgent demonstrates robust overall performance. IntegerDivider con- sistently achieves 100% functional coverage, while ALU754 and UART-16550 generally surpass 86%. In particular, Claude-Sonnet-4.5 generates 268 distinct coverage bins for UART-16550, significantly outper- forming the other models and showcasing its superior capability for fine-grained functional decomposition. Overall, the three models exhibit distinct capability profiles: •Claude-Sonnet-4.5achieves the highest average code coverage (85.9%) and finest functional granularity (137 bins on average). However, it exhibits lower initial efficiency (averaging 91 minutes) and encounters the highest failure frequency during testcase generation. •GPT-5demonstrates the most stable functional coverage (consistently 100%) with minimal variance in stage-wise failures. While its overall performance is balanced, it occasionally fluctuates during coverage modeling and adopts a more conservative functional decomposition granularity (73 bins on average). 11 UCAgent: An End-to-End Agent for Block-Level Functional Verification •Qwen3-Coder-Plusexcels in execution efficiency (averaging 74 minutes) and exhibits remarkable sta- bility during component and coverage-model generation. Nonetheless, this speed trades off against thor- oughness, yielding the lowest average code coverage (74.7%) and functional coverage (90.1%). 4.3 Stage-wise Execution Analysis UART-16550ALU754Integer Divider ICache WayLookup (a) Component Generation Time 0 5 10 15 20 25 30 Minutes 13 9 10 13 17 10 1515 32 7 1 20 UART-16550ALU754Integer Divider ICache WayLookup (b) Functional Coverage Model Generation Time 0 5 10 15 20 25 30 35 Minutes 9 10 5 6 5 6 3 35 14 1 22 UART-16550ALU754Integer Divider ICache WayLookup (c) Test Case Generation Time 0 20 40 60 80 100 120 Minutes 98 75 15 31 120 21 66 9 35 10 73 34 UART-16550ALU754Integer Divider ICache WayLookup (d) Component Generation Failures 0 1 2 3 4 5 6 Count 4 11 2 6 3 4 33 1 0 3 UART-16550ALU754Integer Divider ICache WayLookup (e) Functional Coverage Model Generation Failures 0 2 4 6 8 Count 1 2 0 3 1 4 0 9 0000 UART-16550ALU754Integer Divider ICache WayLookup (f) Test Case Generation Failures 0 10 20 30 40 50 60 70 Count 67 21 5 16 37 7 10 2 17 6 10 7 claude-sonnet-4.5gpt5qwen3-coder-plus Figure 8:Time and failure counts of each stage when UCAgent builds the verification environment Fig.8dissects the verification workflow into three primary phases: component generation, coverage-model generation, and testcase generation. The temporal distribution and failure rates across these stages vividly illuminate the inherent complexities of distinct verification tasks. Component Generationexhibits stable execution times, typically concluding within 10–20 minutes. Fail- ure counts remain consistently low (1–6), indicating that UCAgent’s underlying checker mechanism effectively constrains the LLMs to produce structurally compliant verification components. Coverage-Model Generationgenerally finishes under 10 minutes as the shortest phase. Qwen3-Coder- Plus proves exceptionally efficient here, requiring merely 1–2 minutes for IntegerDivider and ICache- WayLookup. The near-zero failure rates strongly suggest that the VCLM explicitly provides clear, structured semantic constraints, effectively mitigating LLM hallucinations. Testcase Generationincurs the highest failure rates as the most resource-intensive phase. This is expected, as valid testcases must simultaneously satisfy strict syntactic correctness, functional assertions, and targeted coverage annotations. For instance, Claude-Sonnet-4.5 encounters 67 iterative failures on UART-16550 yet ultimately achieves verification closure, powerfully demonstrating the robustness of UCAgent’s checker-driven self-correction loop. By combining the stage-level data in Fig.8, we can further explain the model capability profiles above: 12 UCAgent: An End-to-End Agent for Block-Level Functional Verification •Claude-Sonnet-4.5relies heavily on iterative refinement during test generation (averaging 27.3 failures), explaining its longer runtime. However, this sustained trial-and-error approach directly yields the highest code coverage and most comprehensive test suites. •GPT-5maintains stage-wise equilibrium but displays occasional volatility during coverage modeling (0–9 failures), though its self-correction ensures this does not degrade final functional coverage. •Qwen3-Coder-Plus’s efficiency stems from a coarser functional decomposition strategy. Generating fewer coverage bins inherently reduces the burden on subsequent testcase generation, resulting in fewer failures and faster execution, albeit at the cost of lower final coverage. 4.4 Case Studies To validate UCAgent’s real-world applicability, we conducted experiments on specific modules, highlighting its capability on both established designs (IntegerDivider) and unverified hardware (LaneFAdd, PageTable- Walker). 4.4.1 IntegerDivider Verification (Domain Knowledge Boundaries) Our evaluation reveals significant disparities in the inherent domain knowledge embedded within different LLMs. During testcase generation for the RV32M integer divider, Qwen3-Coder-Plus repeatedly failed to generate the correct expected behavior for the specific boundary case wherethe dividend is the minimum negative value (−2 31 ) and the divisor is−1, despite this overflow behavior being explicitly defined in the RISC-V specification. Conversely, Claude-Sonnet-4.5 and GPT-5 robustly identified and covered this edge case. This highlights that while UCAgent orchestrates the workflow, absolute verification completeness remains bounded by the base model’s domain knowledge, suggesting future needs for targeted knowledge injection. In contrast, Claude-Sonnet-4.5 and GPT-5 are more robust and cover the key boundary case above. These results suggest that knowledge boundaries of LLMs may limit verification completeness, and techniques such as prompt enhancement or domain knowledge injection are needed. 4.4.2 LaneFAdd Verification (Automated Bug Discovery) Driven byclaude-sonnet-4-5-20250929, UCAgent successfully found three previously undiscovered boundary-condition bugs involving special-value handling under FP16 and BF16 precision within the unver- ified LaneFAdd module. Crucially, by leveraging the VCLM, UCAgent automatically traced these failures back to their specific function and check points, seamlessly facilitating rapid localization and resolution by hardware developers. 4.4.3 PageTableWalker Verification (Human-in-the-Loop Applicability) Due to the massive scale of this module (155,408 lines), UCAgent could not complete the verification task using the default workflow. We therefore adopted a human-in-the-loop verification strategy and achieved the expected verification outcome within 8 hours. 5 Discussion 5.1 Effectiveness Experimental results demonstrate that UCAgent can autonomously complete the end-to-end unit-level chip verification workflow. This capability fundamentally stems from the structural synergy among its four core design mechanisms: 1.Python-based verification implementationreduces the difficulty of generating verification code and allows reusing LLM strengths from software engineering; 2.Checker mechanismvalidates LLM behavior through deterministic constraint logic and keeps stage failure counts within an acceptable range; 3.Configurable workflowadapts verification strategies to module characteristics and meets diverse needs across module complexity; 4.VCLMmaintains verification consistency via a labeling system and ensures traceability of results. 13 UCAgent: An End-to-End Agent for Block-Level Functional Verification 5.2 Limitations Despite its demonstrated efficacy, UCAgent exhibits several limitations that inform future research directions: •For massive industrial-scale designs, establishing hierarchical workflow configurations and modular de- composition still necessitates manual engineering effort. •Testcase generation continues to incur the highest failure and retry rates, which can lead to prolonged iteration cycles when confronting highly complex verification scenarios. •The system’s verification completeness remains bounded by the base LLM’s intrinsic domain knowledge. When models misunderstand specific hardware specifications, UCAgent currently lacks systematic mech- anisms (such as dynamic knowledge injection) to compensate for these gaps. •The current 26-stage workflow architecture is statically predefined by human experts. Future iterations could explore fully autonomous, LLM-driven dynamic task decomposition to further elevate the level of automation. References [1]A Molina and Oswaldo Cadenas. “Functional verification: Approaches and challenges”. In:Latin Amer- ican applied research37.1 (2007), p. 65–69. [2]Daniel Payne.The State of IC and ASIC Functional Verification. [Online; accessed 2025-09-29]. 2023.url: https://semiwiki.com/eda/324443- the- state- of- ic- and- asic- functional- verification. [3]Harry Foster et al. “The 2022 Wilson Research Group Functional Verification Study”. In:Siemens.com (2022). [4]Harry Foster et al. “2024 Wilson Research Group IC/ASIC functional verification trend report”. In: Siemens.com(2024). [5]Ashok B. Mehta. “Constrained Random Verification (CRV)”. In:ASIC/SoC Functional Design Ver- ification: A Comprehensive Guide to Technologies and Methodologies. Cham: Springer International Publishing, 2018, p. 65–74.isbn: 978-3-319-59418-7.doi: 10.1007/978-3-319-59418-7_5. [6]Christoph Kern and Mark R Greenstreet. “Formal verification in hardware design: a survey”. In:ACM Transactions on Design Automation of Electronic Systems (TODAES)4.2 (1999), p. 123–193. [7]Harry D. Foster.Breaking the bottleneck: Overcoming the Verification Productivity Gap 2.0. White Paper. Siemens Digital Industries Software, 2025.url:https://resources.sw.siemens.com/en- US/white- paper- breaking- the- bottleneck- overcoming- the- verification- productivity- gap-2-0/. [8]Synopsys.Synopsys.ai: Full-Stack AI-Powered EDA Suite. 2024.url:https://w.synopsys.com/ ai/ai-powered-eda.html(visited on 11/26/2025). [9]Synopsys.VSO.ai: AI-Driven Verification Space Optimization. 2024.url:https://w.synopsys. com/ai/ai-powered-eda/vso-ai.html(visited on 11/26/2025). [10]Cadence Design Systems.JedAI: Big-Data and AI Platform for EDA. 2024.url:https://w. cadence.com/en_US/home/tools/ai/jedai-platform.html(visited on 11/26/2025). [11]Cadence Design Systems.Verisium: AI-Driven Verification Platform. 2024.url:https : / / w . cadence.com/en_US/home/tools/system-design-and-verification/ai-driven-verification. html(visited on 11/26/2025). [12]Cadence Design Systems.Verisium Debug: Machine-Learning Accelerated Debugging. 2024.url:https: / / w . cadence . com / en _ US / home / tools / system - design - and - verification / ai - driven - verification/verisium-debug.html(visited on 11/26/2025). [13]Siemens EDA.EDA AI System: Generative and Agentic AI for Chip Design and Verification. 2024. url :https://eda.sw.siemens.com/en-US/ai/eda-ai-system/(visited on 11/26/2025). [14]Siemens EDA.Solido: Generative and Agentic AI for Custom IC Verification. 2024.url:https: //eda.sw.siemens.com/en-US/ic/solido/(visited on 11/26/2025). [15]Rahul Kande, Hammond Pearce, Benjamin Tan, et al. “LLM-Assisted Generation of Hardware Asser- tions”. In:arXiv preprint arXiv:2306.14027(2024). [16]Chuyue Sun, Christopher Hahn, and Caroline Trippel. “Towards Improving Verification Productivity with Circuit-Aware Translation of Natural Language to SystemVerilog Assertions”. In:International Workshop on Deep Learning-aided Verification (DAV). 2023. 14 UCAgent: An End-to-End Agent for Block-Level Functional Verification [17]Mingjie Liu, Minwoo Kang, Ghaith Bany Hamad, Syed Suhaib, and Haoxing Ren. “Domain-Adapted LLMs for VLSI Design and Verification: A Case Study on Formal Verification”. In:VLSI Test Sympo- sium (VTS). 2024. [18]Vaishnavi Pulavarthi, Deeksha Nandal, Soham Dan, and Debjit Pal. “Are LLMs Ready for Practical Adoption for Assertion Generation?” In:arXiv preprint arXiv:2502.20633(2025). [19]Jitendra Bhandari, Johann Knechtel, Ramesh Narayanaswamy, Siddharth Garg, and Ramesh Karri. “LLM-Aided Testbench Generation and Bug Detection for Finite-State Machines”. In:arXiv preprint arXiv:2406.17132(2024). [20]Hanxian Huang, Zhenghan Lin, Zixuan Wang, et al. “Towards LLM-Powered Verilog RTL Assistant: Self-Verification and Self-Correction”. In:arXiv preprint arXiv:2406.00115(2024). [21]Chao Xiao, Yifei Deng, Zhijie Yang, et al. “LLM-Based Processor Verification: A Case Study for Neuromorphic Processor”. In:Design, Automation and Test in Europe Conference (DATE). 2024. [22]Junhao Ye, Yuchen Hu, Ke Xu, et al. “From Concept to Practice: an Automated LLM-aided UVM Machine for RTL Verification”. In:arXiv preprint arXiv:2504.19959v3(2025). [23]Wenbo Liu, Forbes Hou, Jon Zhang, Hong Liu, and Allen Lei. “A Multi-Agent Generative AI Frame- work for IC Module-Level Verification Automation”. In:arXiv preprint arXiv:2507.21694(2025). [24]Yujie Zhao, Zhijing Wu, Hejia Zhang, et al. “PRO-V: An Efficient Program Generation Multi-Agent System for Automatic RTL Verification”. In:arXiv preprint arXiv:2506.12200(2025). [25]Anton Lozhkov, Raymond Li, Loubna Ben Allal, et al.StarCoder 2 and The Stack v2: The Next Generation. 2024. arXiv:2402.19173 [cs.SE]. [26]YunDa Tsai, Mingjie Liu, and Haoxing Ren. “Rtlfixer: Automatically fixing rtl syntax errors with large language model”. In:Proceedings of the 61st ACM/IEEE Design Automation Conference. 2024, p. 1–6. [27]Jiazheng Zhang, Cheng Liu, and Huawei Li. “Understanding and Mitigating Errors of LLM-Generated RTL Code”. In:arXiv preprint arXiv:2508.05266(2025). [28]Fan Cui, Chenyang Yin, Kexing Zhou, et al. “Origen: Enhancing rtl code generation with code-to-code augmentation and self-reflection”. In:Proceedings of the 43rd IEEE/ACM International Conference on Computer-Aided Design. 2024, p. 1–9. [29]Yang Zhao, Di Huang, Chongxiao Li, et al. “Codev: Empowering llms with hdl generation through multi-level summarization”. In:IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems(2025). [30]Chia-Tung Ho, Haoxing Ren, and Brucek Khailany. “Verilogcoder: Autonomous verilog coding agents with graph-based planning and abstract syntax tree (ast)-based waveform tracing tool”. In:Proceedings of the AAAI Conference on Artificial Intelligence. Vol. 39. 1. 2025, p. 300–307. [31]Yaoyu Zhu, Di Huang, Hanqi Lyu, et al. “CodeV-R1: Reasoning-Enhanced Verilog Generation”. In: arXiv preprint arXiv:2505.24183(2025). [32]Nathaniel Pinckney, Chenhui Deng, Chia-Tung Ho, et al. “Comprehensive Verilog Design Problems: A Next-Generation Benchmark Dataset for Evaluating Large Language Models and Agents on RTL Design and Verification”. In:arXiv preprint arXiv:2506.14074(2025). [33]Wikipedia contributors.Hallucination (artificial intelligence) — Wikipedia, The Free Encyclopedia. [Online; accessed 11-October-2025]. 2025.url:https://en.wikipedia.org/w/index.php?title= Hallucination_(artificial_intelligence)&oldid=1316197198. [34]Kelly Hong, Anton Troynikov, and Jeff Huber.Context Rot: How Increasing Input Tokens Impacts LLM Performance. Tech. rep. Chroma, July 2025.url: https://research.trychroma.com/context-rot. [35]Juyeon Heo, Christina Heinze-Deml, Oussama Elachqar, et al. “Do LLMs” know” internally when they follow instructions?” In:arXiv preprint arXiv:2410.14516(2024). [36]Roy Osherove, Vladimir Khorikov, et al.The Art of Unit Testing: With Examples in JavaScript. Simon and Schuster, 2024. [37]eXtensible Host Controller Interface for Universal Serial Bus (xHCI) Requirements Specification. Re- vision 1.22. Intel Corporation. May 2019.url:https://w.intel.com/content/dam/w/public/ us/en/documents/technical-specifications/extensible-host-controler-interface-usb- xhci.pdf(visited on 01/06/2026). [38]XS-MLVP.Picker: Pick your favorite language to verify your chip.https://github.com/XS-MLVP/ picker. Accessed: 2025-01-11. 2024. [39]XS-MLVP.Toffee: A framework for building hardware verification platform using software method. https://github.com/XS-MLVP/toffee. Accessed: 2025-01-11. 2024. 15 UCAgent: An End-to-End Agent for Block-Level Functional Verification [40]Shengnan Yang et al. “Multi-swe-bench: A multilingual benchmark for issue resolving”. In:arXiv preprint arXiv:2504.02605(2025). [41]gruvw.Signals not updated after rising edgeIssue #3110cocotb/cocotb. Accessed: 2025 Apr 09. 2022.url:https://github.com/cocotb/cocotb/issues/3110. [42]Tom Brown, Benjamin Mann, Nick Ryder, et al. “Language models are few-shot learners”. In:Advances in neural information processing systems33 (2020), p. 1877–1901. [43]Ibrahim Abdelaziz, Kinjal Basu, Mayank Agarwal, et al.Granite-Function Calling Model: Introducing Function Calling Abilities via Multi-task Learning of Granular Tasks. 2024. arXiv:2407.00121 [cs.LG]. url:https://arxiv.org/abs/2407.00121. [44]Harrison Chase and LangChain, Inc.LangChain: A framework for building applications powered by large language models.https : / / github . com / langchain - ai / langchain. Available at: https://w.langchain.com/. Accessed: 2026-01-01. 2022. [45]Shunyu Yao, Jeffrey Zhao, Dian Yu, et al. “React: Synergizing reasoning and acting in language models”. In:The eleventh international conference on learning representations. 2022. [46]Model Context Protocol Authors.Model Context Protocol: Getting Started. Accessed: 2025-11-11. 2024. url:https://modelcontextprotocol.io/docs/getting-started/intro(visited on 12/19/2024). 16