Udemy
    •  
    •  
    •  
    •  
    •  
    •  
    •  
    •  
Turn what you know into an opportunity and reach millions around the world.
Learn More
Your cart is empty.
Keep shopping
Verification Series Part 5: UVM RAL Essentials
Rating: 4.6 out of 5(464 ratings)
4,132 students

Verification Series Part 5: UVM RAL Essentials

Step by Step Guide from Scratch
Created byKumar Khandagle
Last updated 1/2025
English

What you'll learn

  • Using UVM RAL for verification of DUT Registers and Memories
  • Understanding different Register as well memories methods
  • Implementing Frontdoor and Backdoor access methods
  • Implementing Implicit and Explicit Predictor
  • Coverage Computation for Register and Memories

Course content

9 sections141 lectures7h 10m total length
  • Course Overview2:47

    Explore the learning path for UVM RAL, from implementing registers and register blocks to adapters and predictors, then coverage concepts and memory verification within a single project.

  • Agenda1:11

    Explore the advantages and minimum requirements of the UVM RAL, learn the verification environment components, and implement a register and memory model for accurate read and write transactions to hardware.

  • Advantage of UVM RAL P16:32

    Explains how UVM RAL provides abstraction for verifying registers and memory, avoiding address and policy tracking. Demonstrates using a register model with naming to perform read and write transactions.

  • Advantage of UVM RAL P22:18

    UVM RAL offers flexibility with front-door and backdoor access. An independent signal connected to reg1 via dot operator enables backdoor updates without a valid transaction, switchable to UVM_FRONTDOOR or UVM_BACKDOOR.

  • Advantage of UVM RAL P31:09

    Explore how uvm ral p3 offers a range of methods to compare a hardware register against expected data, including mirror and update techniques that read, compare, and auto-update registers.

  • Advantage of UVM RAL P41:48

    Demonstrate UVM RAL coverage for all registers, showing two methods of coverage and per-register tables that auto-track samples via cover points during front-door transactions.

  • When to use RAL in Verification environment4:38

    Explore when to use the UVM register abstraction layer by ensuring the DUT has at least one register with fields and an address-mapped interface, enabling register model verification.

  • Code0:24
  • Components of Register model P16:53

    Replicate DUT registers and memory in the UVM verification environment with identical size and fields. Use an address map to assign addresses and form a register block for read/write verification.

  • Components of Register model P24:45

    Replicate registers and memory in the verification environment to access actual registers, using register sequences, an adapter to burst transactions, and a monitor-driven predictor with a scoreboard.

  • Components of Register model P31:38

    Connect and implement a complete register model using UVM base classes for registers, memories, register blocks, adapters, predictors, and sequences.

  • Notes
  • Typical Learning Path2:33

    Identify the typical subblocks needed to understand a register model, starting with register fields, then registers, memories, address mapping in a register block, and register sequences for the sequencer.

  • Understanding different types of registers3:28

    Implement registers in a verification testbench, from single-field to multi-field layouts, including two-field (slave control and slave data) and four-field setups (enable, mode, address, data) across 32 bits.

  • Implementation of Register in Verification Environmnet P16:24

    Implement a 32-bit slave reg zero in a uvm register model, extending uvm reg, adding a 0 to 31 field, and configuring factory, rand, and no coverage in verification environment.

  • Implementation of Register in Verification Environmnet P26:29

    Configure functions define each reg field by nine arguments: parent register, field size, lsb, access policy, volatility, reset value, reset, rand, and individual accessibility, to reflect the dut field behavior.

  • Alternate way of adding configure function1:18

    Explore two approaches to adding a configure function in UVM RAL, focusing on name-based parameter setting versus positional argument order, with an example configuring a 32-bit register.

  • Summary : Configure function1:58

    Configure function defines a reg field with parent, size, LSB, access type, volatile, reset value, reset capability, randomization, and independent access guided by the access policy, enabling proper verification.

  • Implementation of Register in Verification Environmnet P35:37

    Implement a UVM register by extending UVM Reg, registering it to a factory, and building and configuring reg fields (size 32, LSB 0, read-write, reset) to match the DUT.

  • Code0:18
  • Slides
  • Adding Register with two fields5:44

    Implement a two-field 32-bit register with slave control and slave data, configure 16-bit fields at lsb 0 and 16, enable random data, and validate size mismatches to reveal syntax errors.

  • Code0:17
  • Adding Register with reserved bits3:42

    Configure a 32-bit register with four fields and reserved bits. Use uvm reg, set enable at 0, mode at 1, address at 4, data at 12, and map by position.

  • Code0:24
  • Different Access Policy P12:59

    Explore how to model a register in a verification environment, focusing on access policies defined by the configure function that update desired and mirror values during reads and writes.

  • Different Access Policy P25:48

    Explore 25 access policy configurations in a verification environment, including read-only, wr-only, read-write, and clear on write or read, with observed effects on desired and mirror values.

  • Different Access Policy P34:20

    demonstrate how various access policies, including wr wrc, wrs, ws, wsrc, wcrs, and w1c, dictate write and read behavior on hardware registers, updating or clearing variables.

  • Different Access Policy P45:40

    Explore w1src, w1c, w0src, w0c, and wc modes and understand how read and write operations set or clear bits in registers, including rw and r policies for ram and rom.

  • Notes
  • Adding Memory P11:59

    Define register fields and map them to the parent register in a verification environment, specifying lsb and size, and illustrate memory definitions with three memories (16x8, 128x16, 2048x32).

  • Adding Memory P24:21

    Extend the UVM reg and mem classes to implement memory with a standard constructor, instance name, location count, element size, access type, and coverage flag, using dut_m1, dut_m2, and dut_m3.

  • Code0:12
  • Slides
  • A11
  • A12

Requirements

  • Basic understanding of Verilog, SystemVerilog, and UVM

Description

Writing Verilog test benches is always fun after completing RTL design. You can assure clients that the design will be bug-free in tested scenarios. As system complexity grows day by day, System Verilog becomes a choice for verification due to its powerful capabilities and reusability, which help verification engineers quickly locate hidden bugs. System Verilog lags behind the structured approach, whereas UVM works hard to form a general skeleton. The addition of the configuration database shifts the way we used to work with the verification language in the past. Within a few years, verification engineers recognized the capabilities of UVM and adopted it as a de facto standard for RTL design verification. The UVM will have a long run in the verification domain; hence, learning about the UVM will help VLSI aspirants pursue a career in this domain.

The UVM Register layer provides a set of libraries for adopting UVM for verification of DUTs consisting of registers as well as memories. UVM RAL provides a set of abstract methods to access the register as well as memories with either a front-door or back-door access mechanism that are easy to use as well as configurable. We will also be covering the coverage computation we get with UVM RAL.

 

Who this course is for:

  • Engineers involved/interested in the verification of RTL's