DEV Community: mritunjay bihari singh

Before your DV team writes a single testbench line, make sure you have these 7 things. (Most teams skip at least 3.)

mritunjay bihari singh — Mon, 27 Jul 2026 22:38:28 +0000

The Pre-Testbench Verification Checklist:

✅ 1. Spec version locked — Which version of the spec is RTL implementing? If it's not locked, you're verifying a moving target.

✅ 2. Interface list finalized — All clocks, resets, interfaces, and their reset polarity documented. Surprises here cost days.

✅ 3. Functional coverage model drafted — Write your covergroups before writing your driver. Coverage-first design.

✅ 4. Corner cases listed explicitly — Max burst, min burst, back-to-back, simultaneous read/write, error conditions. If it's not listed, it won't be tested.

✅ 5. DUT reset sequence verified standalone — 40% of RTL bugs I've seen live in the reset sequence. Verify it first, verify it separately.

✅ 6. Scoreboard expected behavior documented — What is the DUT supposed to do for every transaction type? Write it down before you see DUT output.

✅ 7. Regression pass criteria agreed — What does "verification done" look like? Code coverage %, functional coverage %, number of passing tests? Agree upfront.

Teams that nail this checklist finish 3–5 weeks faster.

Hashtags: #HardwareVerification #UVM #SystemVerilog #ASIC #VerificationEngineering #RTL #EDA #ChipDesign

I once found a silicon bug in a protocol spec — not in the RTL.

mritunjay bihari singh — Mon, 27 Jul 2026 22:36:48 +0000

True story from an AXI interconnect project.

We had a well-verified slave. 500k+ simulation cycles. Code coverage > 98%. The DV team signed off. Tapeout was 2 weeks away.

Then a senior architect asked a simple question: "What happens if AWLEN wraps around 256 when AWBURST is INCR?"

The spec said it was "undefined behavior." Our testbench skipped undefined sequences. The RTL had a latent state machine hang hiding in that corner.

We caught it. Others don't.

What I learned: Verification is not about proving the RTL matches the spec. It's about proving the spec is correct before the RTL implements it. These are two completely different problems.

The bugs that cause respins aren't usually in the code. They're in the assumptions nobody thought to question.

If you're a verification engineer reading this — your most valuable skill isn't knowing UVM. It's knowing which questions to ask that your spec author forgot to answer.

Hashtags: #HardwareVerification #ASIC #AXI #ChipDesign #Tapeout #SystemVerilog #SiliconEngineering

Most UVM testbenches fail coverage closure for one reason nobody talks about — and it's not your constraints.

mritunjay bihari singh — Mon, 27 Jul 2026 22:31:27 +0000

After reviewing 20+ verification projects, I see the same pattern:

5 well-written sequences
All of them exercising the "happy path"
Corner cases added as an afterthought at week 8
By then, coverage holes require surgical constrained-random surgery that takes 2x as long as getting it right in week 1.

The fix is boring but it works:

Before you write a single line of driver code, define your sequence taxonomy:

baseline_seq — protocol-compliant, valid stimulus
stress_seq — back-to-back transactions, max burst length
error_inject_seq — bad addr, illegal burst, protocol violations
mixed_seq — interleaved read/write with randomized gaps
Map each to a functional coverage bin. If your sequence can't hit a bin, the sequence is incomplete — not your coverage model.

This one habit saves 3–4 weeks of closure pain at tape-out.

Hashtags: #SystemVerilog #UVM #HardwareVerification #ASIC #ChipDesign #EDA

5 UVM Patterns Every Verification Engineer Should Know

mritunjay bihari singh — Fri, 24 Jul 2026 06:55:46 +0000

Production-Tested Patterns That Scale from IP Blocks to SoCs
Introduction
Over the past 8 years verifying everything from cache coherency controllers to high-speed interconnects, I've noticed that most verification headaches come from not knowing these five UVM patterns. They're not flashy. They won't make your testbench run faster. But they'll make the difference between a clean coverage closure in 6 weeks versus a nightmare that drags 16 weeks past tape-out.

This isn't a tutorial. This assumes you know UVM basics. This is about how professionals actually structure testbenches when the stakes are real.

Pattern 1: The Layered Agent Architecture
(Why Your Monitor Shouldn't Drive, and Your Driver Shouldn't Monitor)
The Problem
Ninety-nine percent of first-time UVM code I review has this sin:

// ❌ WRONG: Driver trying to do everything
class axi_driver extends uvm_driver #(axi_transaction);
virtual axi_if vif;

task run_phase(uvm_phase phase);
    forever begin
        seq_item_port.get_next_item(item);

        // Driving
        vif.awaddr <= item.addr;
        vif.awlen <= item.len;

        // ⚠️ Also monitoring back???
        // Checking slave response
        if (vif.bvalid) begin
            // This is a MONITOR's job, not driver's!
            `uvm_info("DRV", $sformatf("Write complete: %0h", item.addr), UVM_MEDIUM)
        end

        seq_item_port.item_done(item);
    end
endtask

endclass
Why this is toxic:

Tight coupling – Driver can't be tested independently from monitor
Race conditions – Driver writes data, then immediately monitors its own write (timing issues)
Scoreboard confusion – Monitor is supposed to collect gold truth; now it's mixed with driver implementation
Reusability nightmare – Can't plug this driver into different testbenches
The Pattern: Layered, Separate Concerns
// ✅ CORRECT: Driver only drives
class axi_driver extends uvm_driver #(axi_transaction);
virtual axi_if vif;

task run_phase(uvm_phase phase);
    forever begin
        seq_item_port.get_next_item(item);
        drive_write_transaction(item);
        seq_item_port.item_done(item);
    end
endtask

// ONLY driving logic here
task drive_write_transaction(axi_transaction item);
    @(posedge vif.clk);
    vif.awvalid <= 1'b1;
    vif.awaddr  <= item.addr;
    vif.awlen   <= item.len;
    vif.awsize  <= item.size;

    // Wait for slave to accept
    wait(vif.awready);
    @(posedge vif.clk);
    vif.awvalid <= 1'b0;
endtask

endclass

// ✅ CORRECT: Monitor only monitors (passive)
class axi_monitor extends uvm_monitor;
virtual axi_if vif;
uvm_analysis_port #(axi_transaction) ap;

task run_phase(uvm_phase phase);
    forever begin
        @(posedge vif.awvalid && posedge vif.awready);

        // Purely passive observation
        axi_transaction item = axi_transaction::type_id::create("item");
        item.addr = vif.awaddr;
        item.len  = vif.awlen;
        item.size = vif.awsize;

        // Send to analysis port (for scoreboard)
        ap.write(item);
    end
endtask

endclass
Why This Works at Scale
When I was verifying the interconnect on a 32-core SoC:

Isolation meant I could test the driver with a simple slave (5 hours to debug driver issues)
Reuse meant I used the same driver on 4 different interconnect variants
Scoreboard clarity – I knew EXACTLY which transactions came from the monitor (observation) vs. the driver (stimulus)
Real win: Found a subtle slave-to-driver handshake bug only because the monitor was purely passive. If they were tangled, I'd never have caught it.