Published by : International Journal of Engineering Research & Technology (IJERT) https://www.ijert.org/ ISSN: 2278-0181 An International Peer-Reviewed Journal Vol. 15 Issue 05 , May - 2026

ConfigDrivenV: A Python-Integrated UVM Testbench for Automated RTL Verification with Self-Checking Scoreboard

Vatsal Verma, Unnati Gangwar, Anuj Shakya, Lalita Chauhan, Janak Kapoor Department of Electronics and Communication Engineering Mahatma Jyotiba Phule Rohilkhand University, Bareilly, Uttar Pradesh, India

    ABSTRACT

Functional verification of digital hardware designs consumes over 70% of total semiconductor design effort, making automation a critical research priority. This paper presents ConfigDrivenV, a Python-UVM co-verification framework integrating Python-based constrained random test generation with a Universal Verification Methodology (UVM) testbench for automated functional verification of processor and communication protocol designs. The proposed framework employs a two-layer architecture: a Python golden reference model generating random instruction sequences and computing mathematically correct expected register states, and a UVM testbench implemented in SystemVerilog that reads these test vectors, drives them into the RTL design under test (DUT), and performs cycle-accurate comparison via a self-checking scoreboard. The framework is validated on two DUTs — a custom 16-bit RISC-style processor and a UART serial communication controller. Experimental results confirm 100% verification accuracy on correct RTL (PASS=100, FAIL=0) and 100% bug detection effectiveness on deliberately corrupted RTL (PASS=0, FAIL=100). A survey of existing UVM- based verification methodologies is presented alongside the proposed system, establishing novelty and contribution to the field of hardware verification automation. The framework operates entirely on freely available tools, making it accessible to academic institutions without commercial EDA licenses. Keywords — UVM, SystemVerilog, Python, Functional Verification, Golden Reference Model, RISC Processor, UART, RTL Verification, Self-Checking Scoreboard, Automated Test Generation.

               I. INTRODUCTION                                      software level.    Combining  Python-based        constrained
The rapid growth of semiconductor complexity has made               random   generation   with     UVM's structured  verification
functional verification one of the most critical phases of the      infrastructure creates a    complete   automated verification
integrated circuit (IC) design flow. According to industry             pipeline without requiring expensive commercial simulation
surveys, verification engineers allocate more than 70% of           licenses or proprietary constraint solvers.
total project time ensuring RTL designs behave correctly            Existing verification        frameworks   either  rely     on
before fabrication [1]. Manual testbench development is             SystemVerilog-internal   randomization         —    requiring
error-prone, coverage-limited,   and  cannot scale     to     the           commercial simulator licenses — or depend on manually
billions of transistors present in modern SoC designs.              written  directed tests  that provide limited design    space
The Universal Verification Methodology (UVM) [2] has                    coverage. ConfigDrivenV addresses this gap through Python
emerged as the industry standard for structured, reusable                as a free, powerful test generation and golden reference
hardware   verification. Built   on  SystemVerilog,           UVM   layer communicating with UVM via standard file I/O.
provides  a  standardized class  library including       drivers,   The contributions of this paper are:
monitors,  scoreboards,   sequences,  and agents         enabling             1) A two-layer Python-UVM co-verification framework
modular,   scalable testbench    construction. Despite       this               named ConfigDrivenV is proposed, implemented, and
structure, UVM alone does not solve the stimulus generation          validated.
problem — engineers must still define what test programs to
apply.                                                               2)      Python   golden reference  integration with      UVM
Python has emerged as a powerful complement to UVM for                     scoreboard via $fscanf file I/O eliminates manual test
test generation due to its expressive standard library, ease of      case authoring.
scripting, and capacity to model hardware behaviour at the



IJERTV15IS050763                                                             Page 1
               (This work is licensed under a Creative Commons Attribution 4.0 International License.)

Published by : International Journal of Engineering Research & Technology (IJERT) https://www.ijert.org/ ISSN: 2278-0181 An International Peer-Reviewed Journal Vol. 15 Issue 05 , May - 2026

               3) Validation is performed on two distinct DUTs: a 16-   demonstrated across arithmetic, logical, and memory access

bit RISC processor and a UART controller. instruction classes. 4) Bug injection experiments on deliberately corrupted A 2024 IEEE paper on UVM verification of RISC-V RTL confirm 100% detection effectiveness. instruction sets [9] presented a complete UVM testbench for processor ISA verification with constrained random 5) A literature survey of UVM-based verification stimulus and functional coverage groups. Results confirmed methodologies establishes the research context and that random instruction generation achieves significantly novelty. higher design space coverage than directed testing — validating the random generation approach adopted in this This paper proceeds as follows: Section II surveys related work. literature, Section III presents the proposed architecture, Section IV details implementation, Section V analyses Malagi et al. [10] demonstrated UVM verification using experimental results, Section VI discusses scalability and TLM reference models for image processing RTL, waveform observations, and Section VII draws conclusions. confirming that software-level reference models integrated with UVM scoreboards achieve reliable automated self- II. LITERATURE SURVEY checking. The University of Florida's comprehensive survey [11] on directed test generation for hardware validation A. UVM Methodology and Frameworks established golden reference models as the most reliable Bharathi et al. [3] established that UVM's layered mechanism for automated comparison in simulation architecture provides a structured alternative to ad-hoc environments — forming the theoretical foundation for testbench approaches, with coverage-driven verification ConfigDrivenV's Python layer. identified as the primary advantage over traditional directed C. UART Verification Using UVM testing. Their review of UVM for IC verification serves as a Priyanka and Gokul [12] designed and verified a UART foundational reference for all methodology choices in this controller using a complete UVM testbench, demonstrating paper. protocol-level verification through scoreboard comparison Fiergolski et al. [4] evaluated UVM-based verification of transmitted and received bytes. Their verification platforms for SoC designs, demonstrating that structured architecture — driver, monitor, scoreboard connected via UVM environments reduce total verification time by TLM analysis ports — is structurally identical to the UART enabling component reuse. Wang et al. [5] specifically testbench implemented in this paper. quantified UVM reusability, showing that a well-architected Bharathi et al. [13] published the most recent advanced testbench can be ported to different DUTs with minimal UART verification framework using UVM and modification — a property explicitly demonstrated in this SystemVerilog (2025), confirming continued research work where the same UVM framework structure verifies activity in this area. Srinath and Hiremath [14] achieved both a processor and a UART controller. 100% functional coverage for UART using SystemVerilog- A 2024 study revisiting UVM [6] introduced advanced based constrained random verification, establishing that 20 strategies for optimizing verification efficiency through boundary-spanning test vectors provide adequate coverage scalable component architectures and automation pipelines, of UART protocol behaviour. directly motivating the automation-first design philosophy Sahay and Gajjar [15] extended UART verification to of ConfigDrivenV. Mukherjee et al. [7] extended UVM with include SPI and I2C protocols in a unified UVM framework, fault injection capabilities, confirming that deliberate RTL demonstrating the scalability of UVM across serial corruption is a recognized methodology for validating communication protocol families. Chavan et al. [16] testbench sensitivity — the same approach used in this published a review of UART UVM testbench development paper's bug injection experiments. from a student project perspective, providing direct B. Processor Verification Using UVM academic precedent for this work's UART verification Chippagi [8] proposed a reusable UVM framework for component. verification of Power ISA processor cores, introducing a D. Automated Test Generation software predictor model computing expected register states The Berkeley EECS technical report [17] on automated RTL and feeding them to a UVM scoreboard. This concept is the testing established that most RTL bugs manifest as incorrect direct academic precedent for ConfigDrivenV's Python datapath computations detectable through register-level golden reference model. Complete coverage was

IJERTV15IS050763 Page 2 (This work is licensed under a Creative Commons Attribution 4.0 International License.)

Published by : International Journal of Engineering Research & Technology (IJERT) https://www.ijert.org/ ISSN: 2278-0181 An International Peer-Reviewed Journal Vol. 15 Issue 05 , May - 2026

comparison, motivating the register-comparison approach of Fig. 1. Two-Layer Architecture ConfigDrivenV's scoreboard. The report further confirmed LAYER that random instruction generation combined with golden Somer brn td. | | reference comparison is the most effective automated

strategy for processor verification. - =

E. Formal Verification vs Simulation AYER Formal verification methods, while mathematically | complete, face scalability limitations for complex processor 8 r= | designs due to state space explosion [18]. Simulation-based verification using UVM, while not exhaustive, achieves practical coverage levels through constrained random Fig. 1. ConfigDrivenV Two-Layer Architecture generation. ConfigDrivenV targets the simulation domain, exploiting Python's flexibility for test generation while B. Python Layer — Test Generator and Golden Reference preserving UVM's structured verification infrastructure. The Python generator produces N random CPU instructions F. Commercial vs Open-Source Tools by selecting from the defined instruction set, assigning Industry-grade verification typically employs Cadence random destination registers (rd ∈ {0,1,2,3}), and generating Xcelium or Synopsys VCS with full constraint solver signed 8-bit immediate values (imm ∈ [-128, +127]). support. Academic environments are often constrained to Instruction encoding follows the 16-bit format: bits [15:12] free tools such as ModelSim Starter Edition, which lacks hold the opcode, bits [9:8] hold rd, and bits [7:0] hold the SystemVerilog constraint randomization features. immediate value. ConfigDrivenV is specifically designed to operate within Concurrently with generation, a software register file these constraints, replacing SystemVerilog randomization models the processor state. Each operation is applied to this with Python-generated test files — making professional- software model, and the resulting register snapshot is written grade UVM verification accessible without commercial to checkpoints.mem as a line entry of the form: PC R0 R1 licenses. R2 R3 in hexadecimal. This file becomes the ground truth against which hardware outputs are compared. G. Research Gap A review of the literature reveals that while UVM is C. UVM Layer — Testbench Architecture universally adopted and Python is widely used for hardware The UVM testbench follows the standard hierarchical co-simulation, no existing work directly integrates Python- structure. The test reads Python-generated files and creates generated golden reference data with UVM via file I/O on sequence items. The sequencer manages item flow to the free simulation tools. ConfigDrivenV fills this gap with a driver. The driver executes one instruction per clock cycle practical, reproducible, and license-free verification and captures register outputs. The scoreboard performs framework applicable across different DUT types. comparison. Table I lists all ten UVM component files with III. PROPOSED SYSTEM ARCHITECTURE their roles. A. Overview File Component Role ConfigDrivenV employs a two-layer pipeline architecture. cpu_if.sv Interface Bundles clk, rst, instr, The Python layer generates test programs and computes cpu_seq_item.sv | Sequence pc, halt, r0-r3 expected register states. The UVM layer consumes these Item Holds instr, exp_r0-r3, artifacts, drives the DUT, and performs automated cpu_driver.sv Driver act_r0-r3 comparison. The layers communicate via three text files Drives instr, reads actual registers written by Python and read by the UVM test sequence. cpu_monitor.sv Monitor Passive DUT output observer cpu_scoreboard.sv | Scoreboard | PASS/FAIL register comparator cpu_agent.sv Agent Bundles driver+monitor+sequenc er cpu_env.sv Environment | Connects via TLM analysis ports

IJERTV15IS050763 Page 3 (This work is licensed under a Creative Commons Attribution 4.0 International License.)

Published by : International Journal of Engineering Research & Technology (IJERT) https://www.ijert.org/ ISSN: 2278-0181 An International Peer-Reviewed Journal Vol. 15 Issue 05 , May - 2026

cpu_test.sv Test Reads Python files, equivalence between Python model and RTL for all operand drives sequences combinations including boundary values. cpu_tb_pkg.sv Package Compilation order management C. File I/O Bridge — Python to UVM tb_top_cpu.sv Top DUT instantiation + The three output files follow strict hexadecimal text formats Module UVM start Table I. UVM Component Files readable by SystemVerilog $fscanf. The instr.hex file contains one instruction per line as a 4-digit hex value. The D. DUT 1 — 16-bit RISC Processor checkpoints.mem file contains one line per instruction with The processor DUT (simple_cpu.v) features a 4×16-bit five space-separated hex fields representing PC, R0, R1, R2, register file, an 8-bit program counter, and a single-cycle and R3 after that instruction completes. The golden.mem execution FSM. Table II defines the instruction set. file contains the four final register values. Opcode | Mnemonic | Operation A representative excerpt from a generated checkpoints.mem 0x0 NOP PC ← PC+1 file demonstrates the format: 0x1 ADD rd ← rd + imm 0000 0000 0000 ffa2 0000 ; after instr 0 0x2 SUB rd ← rd − imm 0001 000f 0000 ffa2 0000 ; after instr 1 0x3 MOV rd ← imm 0002 000f 0000 ffa2 0005 ; after instr 2 0x4 XOR rd ← rd ⊕ imm 0xF HALT halt ← 1 Table II. Processor Instruction Set The UVM test sequence reads these files using the following SystemVerilog pattern, executed once per instruction in a E. DUT 2 — UART Controller while loop until EOF: The UART DUT (uart_tx.v, uart_rx.v) implements 8N1 fi = $fopen(instr_file, "r"); serial framing: 1 start bit (LOW), 8 data bits LSB-first, even fc = $fopen(chkpt_file, "r"); parity bit, 1 stop bit (HIGH), with baud rate controlled by $fscanf(fi, "%h", instr); the baud_div clock divider parameter. The testbench uses $fscanf(fc, "%h %h %h %h %h", pc, r0, r1, loopback topology connecting TX output directly to RX r2, r3); input. D. UVM Component Interaction and Timing IV. IMPLEMENTATION Fig. 2 illustrates the temporal interaction between UVM A. Development Environment components for a single instruction transaction. All simulations use ModelSim Intel FPGA Starter Edition 10.5b with UVM 1.2. The critical compilation flag +define+UVM_NO_DPI bypasses the DPI library Te. requirement absent in the Starter Edition. Python 3.x standard library handles test generation with zero external - | i H H dependencies, ensuring immediate reproducibility on any @ H platform. f= ; H

                                                                              Hl

B. Python Generator Implementation om The generator is invoked with a single terminal command. i i i NUM_INSTR controls test depth — this single variable — scales verification from 30 to 1000 instructions without modifying any other code. A randomly chosen integer seed Fig. 2. Single-Instruction Transaction Timing is printed to console, enabling reproduction of any specific E. Self-Checking Scoreboard failing test case by resetting the seed. The scoreboard receives complete transaction objects from Register state tracking is achieved through a four-element the driver containing Python-predicted values (exp_r0 Python list, where each arithmetic operation applies bitwise through exp_r3) and actual DUT values (act_r0 through AND with 0xFFFF to enforce 16-bit width constraints, act_r3). Comparison uses the SystemVerilog === operator, faithfully replicating the modular overflow behaviour of the which handles 4-value logic (0, 1, X, Z) correctly — synthesized hardware datapath. This ensures mathematical avoiding false passes when uninitialized X values propagate

IJERTV15IS050763 Page 4 (This work is licensed under a Creative Commons Attribution 4.0 International License.)

Published by :                                                                     International Journal of Engineering Research & Technology (IJERT)

https://www.ijert.org/ ISSN: 2278-0181 An International Peer-Reviewed Journal Vol. 15 Issue 05 , May - 2026

through the                      design. All four registers    are   evaluated   (+1 offset)
simultaneously, and mismatch in any register constitutes a                                             Table IV. UART Verification Results
FAIL with the specific expected and actual values logged.                        The 20 vectors covered all critical UART data patterns: all-
F. Bug Injection Methodology                                                     zeros (0x00), all-ones (0xFF), alternating patterns (0xA5,
Two buggy RTL versions were created to validate testbench                        0x5A, 0x55, 0xAA), single-bit set patterns (0x01, 0x80),
sensitivity. In simple_cpu_buggy.v, the ADD opcode case                          nibble patterns (0x0F, 0xF0), and sequential byte values
was modified from r[rd] <= r[rd] + simm to r[rd] <= r[rd] -                      (0x12 through 0x7E). All passed on correct RTL. The off-
simm — a functionally plausible error (wrong operator) that                      by-one bug produced FAIL on all 20 — each received byte
would be difficult to detect through code review alone. In                       was     exactly one  greater          than transmitted, detected and
uart_rx_buggy.v, the STOP state output assignment was                            logged by the scoreboard.
changed from data_out <= shift_reg to data_out <= shift_reg                      C. Comparison with Related Works
+ 1, introducing an off-by-one error in every received byte.
The identical testbench runs unchanged against both correct                      Table V positions ConfigDrivenV against directly related
and corrupted RTL.                                                               published works.
                                                                                 Ref     DUT          Test       Golde    Tool            Bug
                                        V. RESULTS AND DISCUSSION                                     Generat    n        Require         Detecti
                                                                                                      ion        Model    d               on
A. CPU Verification Results                                                      [9]     RISC-V       SV         SW       Commer          Partial
Table III presents    CPU     verification              results     across 100   2024                 Constrai   Model    cial
randomly generated instructions.                                                 [12]    UART         nt
                                                                                                      Manual     None     Commer          Manual
Experiment        Instructions                    PASS      FAIL      Pass       202                  Directed            cial
                                                                      Rate       1
Correct RTL       100                             100       0         100%       [8]     Power        Manual     SW       Commer          Yes
Buggy RTL         100                             0         100       0%         202     ISA                     Predic   cial
(ADD→SUB)                                                                        4                               tor
                              Table III. CPU Verification Results                [14]    UART         SV         None     Commer          Partial
                                                                                 202                  Constrai            cial
The correct RTL passed 100% of instructions spanning all 5                       2Thi    CPU+UA       nt
opcodes, all 4 destination registers, and the full signed                        s       RT           Python     Pytho    Free            100%
immediate range (-128 to +127). The scoreboard output for                        Wo                   (Free)     n        Tools
a representative PASS transaction is shown below:                                rk
    UVM_INFO [SB] PASS | instr=26                                                                     Table V. Comparison with Related Works
    r0=0002 r1=009b r2=0018 r3=006e
                                                                                     VI. SCALABILITY ANALYSIS AND WAVEFORM
The buggy RTL triggered FAIL for every instruction where                                                           OBSERVATIONS
ADD was selected — which occurred across most of the                             A. Scalability with Test Depth
100   random     instructions                given   the   uniform   opcode      A key property of ConfigDrivenV is test depth scalability.
distribution. Each FAIL logged the expected versus actual                        Changing a single variable (NUM_INSTR) in the Python
discrepancy precisely, enabling immediate bug localisation:                      generator scales the number of verified instructions without
    UVM_ERROR [SB] FAIL | instr=1                                                modifying any UVM code. Table VI quantifies verification
    exp r2=ffa2 | got r2=005e                                                    outcomes and estimated simulation time across different test
                                                                                 depths.
B. UART Verification Results                                                     NUM_INSTR            PASS           FAIL                Est. Sim
Table IV summarises UART verification results across 20                                               (correct)      (buggy)             Time
boundary-spanning test vectors.                                                                                                          (wall-
                                                                                                                                         clock)
Experiment     Vectors                       PASS       FAIL         Pass        30                   30             30                  ~1 s
                                                                     Rate        50                   50             50                  ~2 s
Correct RTL     20                           20         0            100%        100                  100            100                 ~3 s
Buggy RTL       20                           0          20           0%          200                  200            200                 ~5 s
                                                                                 500                  500            500                 ~12 s


IJERTV15IS050763                                                                                                                          Page 5
                    (This work is licensed under a Creative Commons Attribution 4.0 International License.)

Published by : International Journal of Engineering Research & Technology (IJERT) https://www.ijert.org/ ISSN: 2278-0181 An International Peer-Reviewed Journal Vol. 15 Issue 05 , May - 2026

                                Table VI. Scalability with NUM_INSTR                 This distribution provides confidence that the verification
                                                                                     covers the full instruction behaviour space rather than a

Simulation time scales linearly with instruction count narrow subset. because each instruction consumes exactly two clock cycles in the testbench (one for fetch, one for execute-and-sample). VII. CONCLUSION This predictable scaling enables planning of verification runs based on available simulation time. This paper presented ConfigDrivenV, a Python-UVM co- verification framework for automated functional verification B. Waveform Analysis — Correct RTL of RTL designs. By positioning Python as the test ModelSim waveform inspection of the correct CPU generation and golden reference layer communicating with simulation confirms expected signal behaviour. During the UVM through standard file I/O, the framework achieves reset phase (rst=HIGH for 5 clock cycles), all register professional-grade verification capability on freely available outputs remain at 0x0000 and the program counter holds at simulation tools — eliminating the commercial license 0x00. Upon deassertion of reset, the instruction signal barrier that typically prevents academic adoption of transitions to the first hex value from instr.hex on the industry-standard UVM methodology. subsequent clock edge. Experimental validation on two distinct DUTs — a 16-bit For an ADD instruction (e.g., 0x12A2 — ADD r2, -94), the RISC processor and a UART controller — confirmed 100% waveform shows the instruction driven on the posedge, verification accuracy on correct RTL and 100% bug followed by the register r2 updating to 0xFF A2 on the next detection effectiveness on deliberately corrupted RTL. The posedge as the single-cycle datapath completes. The comparative analysis against published works demonstrated scoreboard comparison occurs after a brief simulation that ConfigDrivenV uniquely achieves automatic test settling delay following the posedge, ensuring stable signal generation, software golden reference integration, and full sampling before the comparison is performed. bug detection using only free tools. For the UART simulation, the tx signal waveform shows The framework's configurable test depth, self-checking clearly distinguishable UART frames: a LOW start bit, 8 scoreboard architecture, and reusable UVM component data bits in LSB-first order, a parity bit, and a HIGH stop structure make ConfigDrivenV immediately applicable to bit, each lasting exactly baud_div=10 clock cycles. The diverse digital design verification scenarios. It is particularly data_valid signal pulses HIGH for one clock cycle when the suited to academic and resource-constrained verification receiver successfully reconstructs the byte, at which point environments where commercial EDA tools are unavailable. the scoreboard captures and compares the received value. Future directions include: (1) extending the instruction set to C. Waveform Analysis — Buggy RTL include branch instructions and conditional execution, enabling verification of control flow correctness; (2) adding The buggy CPU waveform reveals the subtlety of the SystemVerilog covergroup-based functional coverage introduced defect. When the ADD instruction executes, the metrics to quantify design space coverage; (3) implementing register output value is numerically lower than expected a JSON-based DUT configuration file enabling rather than higher — consistent with subtraction replacing ConfigDrivenV to target any processor architecture through addition. For an ADD r2, -94 instruction where the register configuration alone, without modifying UVM testbench previously held 0x0000, the correct output is 0xFFA2 (0 + (- source code; and (4) integration with open-source formal 94) = -94) while the buggy output is 0x005E (0 - (-94) = verification tools to extend from simulation-based to hybrid +94). The magnitude is identical but the sign is inverted — formal-simulation verification. exactly the type of subtle error that manual code review would likely miss but automated comparison catches ACKNOWLEDGMENT immediately. The authors thank the Department of Electronics and D. Test Coverage Observations Communication Engineering, Mahatma Jyotiba Phule Across 100 randomly generated instructions with uniform Rohilkhand University, for providing laboratory opcode distribution, the observed opcode frequency closely infrastructure and ModelSim simulation tools. matches theoretical expectation of 20% per opcode. All four REFERENCES destination registers (r0-r3) appear with roughly equal frequency across the 100 instructions. The immediate value [1] Accellera Systems Initiative, "Functional Verification Study," Industry range [-128, +127] is sampled broadly, with positive values, Report, 2022. negative values, zero, and boundary values all represented.

IJERTV15IS050763 Page 6 (This work is licensed under a Creative Commons Attribution 4.0 International License.)

Published by : International Journal of Engineering Research & Technology (IJERT) https://www.ijert.org/ ISSN: 2278-0181 An International Peer-Reviewed Journal Vol. 15 Issue 05 , May - 2026

[2] Accellera  Systems  Initiative, "Universal Verification    Methodology
    (UVM) 1.2 User Guide," Accellera Standard, 2015.
    [3] M. Bharathi, M. Dharani, D. Sharvani, V. Praveena, and K. Kakarla,
    "An   Introduction  to Universal Verification  Methodology     for the
    digital design of Integrated circuits: A Review," IEEE Xplore, 2021.
      [4] A. Fiergolski et al., "A UVM-based smart functional verification
    platform: Concepts,     pros,    cons,         and     opportunities,"
    IEEE/ResearchGate, 2015.
  [5] D. Wang et al., "Research of reusability based on UVM verification,"
    IEEE Xplore, 2016.
     [6] K. Salah, “Revisiting UVM,” in Proc. 2024 IEEE East-West Design &
    Test Symposium (EWDTS), 2024.
  [7] D. Lohmann, F. Maziero, E. J. dos Santos, and D. Lettnin, “Extending
    universal verification methodology with fault injection capabilities,”
    in Proc. 2018 IEEE 9th Latin American Symposium on Circuits &
    Systems (LASCAS), 2018.
           [8] H. Chippagi, "A UVM based Reusable Framework for End-To-End
    Verification of Power ISA Cores," IJISAE, Vol. 12, 2024.
      [9] P. Kannan, T. Srivarsa, S. Ashwin Kumar, and S. Chandra Prakash,
    “UVM Verification      of RISC-V Instruction   Set,” in   Proc.   IEEE
    ICAECA, 2024.
       [10] S. Malagi et al., "Early Development of UVM based Verification
    Environment using TLM Reference Model," IEEE DDECS, 2015.
    [11] A. Jayasena and P. Mishra, “Directed Test Generation for Hardware
    Validation: A Survey,” ACM Computing Surveys, vol. 56, no. 5, pp.
    1–36, Dec. 2023.
          [12] B. Priyanka and M. Gokul, "Design of UART Using Verilog And
    Verifying Using UVM," IEEE ICDCS, 2021.
      [13] M. Bharathi et al., "Advanced UART Verification Framework Using
    UVM and SystemVerilog," IEEE ICAIIHI, 2025.
       [14] M. Srinath and S. Hiremath, "Verification of UART using System
    Verilog," IJERT, Vol. 11, Issue 07, 2022.
        [15] N. Sahay and S. Gajjar, "Design and UVM based Verification of
    UART, SPI, and I2C Protocols," IEEE ICOSEC, 2024.
      [16] K.K. Chavan, S.S. Kirdak, A.S. Bhagwat, S.R. Sabale, A. Gangad,
    "Review   Paper:    UART  Protocol Using        Verilog   with     UVM
    Testbench," IJSREM, 2023.
      [17] UC Berkeley, "Automated Testing, Verification and Repair of RTL
    Hardware Designs," EECS Tech Report UCB/EECS-2024-157, 2024.
  [18] C. Spear and G. Tumbush, "SystemVerilog for Verification," 3rd Ed.,
    Springer, 2012.
[19] IEEE Standards Association, "IEEE Std 1800-2012: SystemVerilog
    Unified Hardware Design, Specification, and Verification Language,"
    2012.










IJERTV15IS050763                                              Page 7
                        (This work is licensed under a Creative Commons Attribution 4.0 International License.)