Functional Verification

Skill: Functional Verification (UVM)

Invocation

When this skill is loaded and a user presents a verification task, do not execute stages directly. Immediately spawn the digital-chip-design-agents:verification-orchestrator agent and pass the full user request and any available context to it. The orchestrator enforces the stage sequence, loop-back rules, and sign-off criteria defined below.

Use the domain rules in this file only when the orchestrator reads this skill mid-flow for stage-specific guidance, or when the user asks a targeted reference question rather than requesting a full flow execution.

Pre-run Context

Before executing or advising on any stage, read the following files if they exist:

1. memory/verification/knowledge.md — known failure patterns, successful tool flags, PDK/tool quirks. Incorporate its guidance into every stage decision. If absent, proceed without it.
2. memory/verification/run_state.md — current run identity (run_id, design_name, tool, last_stage). Use this to resume correctly after interruption. If absent, a new run is starting; the orchestrator will create this file before the first stage.

This pre-run read applies whether this skill is loaded by a user or called by the orchestrator mid-flow. It ensures the fix database is consulted before any diagnosis step.

Purpose

Guide the complete UVM functional verification flow from testbench architecture through coverage-closed regression sign-off. Produces a verified RTL package with documented coverage and a clean regression.

Supported EDA Tools

Open-Source

• Verilator (verilator) — fast cycle-accurate simulator; UVM support via verilator+UVM
• Icarus Verilog (iverilog) — event-driven simulation for quick testbench checks
• cocotb — Python-based co-simulation framework (pip install cocotb)
• PyUVM — UVM implementation in Python for cocotb environments
• UVVM — VHDL verification methodology library

Proprietary

• Synopsys VCS (vcs, dialect synopsys) — industry-standard SV/UVM simulator
• Cadence Xcelium (xrun, dialect cadence) — multi-language simulator with coverage engine
• Siemens Questa (vsim / vlog / vcom, dialect siemens) — mixed-language simulation with UVM support

Stage: tb_architecture

Domain Rules

1. Follow UVM 1.2 standard (IEEE 1800.2)
2. One UVM agent per DUT interface (driver, monitor, sequencer)
3. Active agents: drive stimulus; passive agents: monitor only
4. Scoreboard: checks DUT output against reference model output
5. Reference model: functional model of DUT — SystemVerilog or C++ via DPI
6. Coverage collector: separate component from scoreboard
7. Virtual sequencer: coordinates multi-agent stimulus scenarios
8. All TB parameters via uvm_config_db — no hardcoded values in components

UVM Hierarchy Template

uvm_test
  └─ uvm_env
       ├─ agent_A (active)   driver + monitor + sequencer
       ├─ agent_B (passive)  monitor only
       ├─ scoreboard
       ├─ coverage_collector
       └─ virtual_sequencer

QoR Metrics to Evaluate

• All DUT interfaces covered by an agent
• Reference model: adequate to check all DUT outputs
• TB compile: 0 errors

Output Required

• TB architecture diagram
• UVM component list and hierarchy
• Interface-to-agent mapping table

Stage: test_planning

Domain Rules

1. Every functional requirement → at least one directed test
2. Every interface → protocol compliance test
3. Error/exception cases: explicit directed tests (not left to random)
4. Corner cases: boundary values, max/min, overflow, underflow
5. Concurrency: multi-threaded stimulus for pipeline stress
6. Back-pressure: tests under flow control conditions
7. Reset: in-operation resets, reset during active transaction
8. Define covergroups before writing tests
9. Plan the corner cases a directed test rarely reaches, one V-plan entry each:
   • simultaneous events — load and increment, read and write when empty, flush and enable, full and empty together
   • the first cycle out of reset
   • sustained back-pressure (ready low for many cycles) and maximum-rate input with no gaps
   • an input deasserting mid-transaction
   • both extremes of the clock ratio for a multi-clock block
10. Test at boundary parameter values, not only the default configuration: WIDTH=1, DEPTH=1 and 2, N=1, and a non-power-of-two value. A value the RTL is meant to reject gets a test that it refuses to elaborate
11. Take the RTL hand-off as an input: each entry in design_state.rtl.unverified[] (claims the RTL flow concluded without a tool run) gets a test or is marked as assigned to formal. cdc and reset entries cannot be closed by functional simulation — record them as needing a CDC/RDC tool run rather than as covered

V-Plan Entry Template (per feature)

feature_id:   F001
description:  AXI write burst handling
tests:        [direct_single_write, burst_len_256, narrow_transfer]
assertions:   [axi_valid_stable, axi_handshake_check]
covergroups:  [burst_len_cg, burst_type_cg]
priority:     P0

QoR Metrics to Evaluate

• Requirement coverage: 100% of spec features mapped
• P0 tests: must pass before random testing begins
• Estimated test count: reasonable vs schedule

Output Required

• V-plan document
• Covergroup definitions
• Assertion list with expected behaviour

Stage: uvm_tb_build

Domain Rules — Sequences

1. Base sequence: minimum valid transaction
2. Extended sequences: specific scenarios from V-plan
3. Sequence library: register all sequences for random selection
4. Never hardcode values — use randomised fields with constraints

Domain Rules — Testbench Coding

Testbench code is exempt from the RTL synthesis rules — initial, #delay and blocking assignments are correct here — but it is still SystemVerilog that has to elaborate the same way in every simulator.

1. `default_nettype none at the top of every testbench, interface and bind file, restored with `default_nettype wire at the end so library code compiled after it is unaffected; a typo in a DUT connection must be an error, not an implicit one-bit net
2. Instantiate the DUT with named port connections and named parameter overrides (#(.WIDTH(8))), never positional — a positional connection mis-wires silently when a port list is reordered
3. Type every parameter and constant (int unsigned, logic [W-1:0]). An untyped parameter and a size-cast bare literal (WIDTH'(1)) are signed; in a scoreboard comparison that yields a false pass or a false mismatch on values with the top bit set
4. Compare expected and actual at the same width and signedness, and compare with !== so an X or Z on the DUT output is a mismatch, not a silent pass
5. Comment the why: each assumption about the DUT, each waiver, each deliberately illegal stimulus

Domain Rules — Drivers

1. Drive signals cycle-accurate to protocol specification
2. Handle back-pressure per the ready/valid contract. As a source: assert valid without waiting for ready, then hold valid and the payload stable until the beat is accepted. As a sink: ready may depend on valid. A driver that waits for ready before asserting valid deadlocks against a DUT that waits for valid, and hides DUT bugs that only appear under back-pressure
3. Protocol assertion in driver to catch illegal stimulus early

Domain Rules — Scoreboard

1. Predict expected output from reference model before DUT output arrives
2. Report mismatches with full context (stimulus, expected, actual)
3. Track: total checks, pass, fail, untriggered

Domain Rules — SVA Assertions

1. Protocol assertions: in interface bind, not DUT
2. Functional assertions: in checker or bind module
3. All assertions: clearly named with descriptive failure message
4. Every ready/valid interface carries the contract as assertions: transfer only on valid && ready; valid not retracted before the beat is accepted; payload stable while valid && !ready; valid and ready deasserted (not X) in reset

QoR Metrics to Evaluate

• TB compile: 0 errors, 0 warnings
• Sanity test: passes with known-good RTL
• All components active in simulation log

Output Required

• UVM component source files
• SVA assertion files (bind-based)
• Compile script

Stage: directed_tests

Domain Rules

1. Implement one directed test per V-plan entry — tests must be deterministic

2. Each test: verify the exact functional requirement it targets (no catch-all tests)

3. Error/exception paths: explicit stimulus to trigger each one

4. Corner cases: boundary values, max/min, overflow, underflow — one test each

5. Reset during active transaction: at least one test per interface

6. P0 tests must all pass before constrained-random phase begins

7. DUT bug found during directed test: write a fix_request entry to design_state.fix_requests[] per the schema in the verification-orchestrator Design State section; terminate with decision=escalate. The pipeline-orchestrator (chip-design-meta) handles RTL re-invocation — do not loop locally or wait for user confirmation.

8. Before filing, classify the failure as DUT bug or testbench bug, and name the mechanism, not just the location — the reported symptom is not necessarily the bug. Set suspected_rtl.basis to traced only when you followed the mismatch back to that signal in the waveform; otherwise hypothesis. Start from the symptom:

   Symptom	Look first at
   Intermittent, rate scales with clock ratio	Clock-domain crossing
   Fails at bring-up, fine once running	Reset release and reset values
   Hangs until reset	FSM state with no exit, protocol wait-for cycle
   Wrong only for large values	Width truncation, arithmetic overflow
   Wrong only for negative values	Signed/unsigned mix
   Fails only under sustained load	Arbitration fairness, retracted valid, unstable payload
   Passes in RTL sim, fails in gate sim	Blocking assignment in clocked block, incomplete sensitivity list, X-optimism
   Degrades slowly over a long run	Leaked credit or token

9. Never make a failing test pass by weakening the check: do not loosen the scoreboard comparison, disable or waive an assertion, or constrain stimulus away from the failing case unless that stimulus was illegal per the spec. A fix to the testbench must leave every other test's checking at least as strict as before