CHIP DESIGN · COURSE

Functional Verification

Turn hardware requirements into falsifiable, traceable, and reproducible evidence. The course begins with requirement obligations, risk, testbench authority, event scheduling, race-free sampling, and four-state policy; then develops boundary-directed and constrained stimulus, replay manifests, passive monitors, independent reference models, identity-aware scoreboards, temporal assertions, vacuity controls, functional coverage, formal proof bounds, equivalence mappings, first-divergence debug, reduction, regression, and mutation testing. The capstone verifies the parameterized request engine from RTL Design across nine parameter combinations and five plausible faults while keeping every physical claim separate.

Before this course: Completed RTL Design with SystemVerilog, including contracts, event scheduling, valid-ready protocols, state ownership, reset, assertions, and simulation/synthesis boundaries. No UVM installation, commercial simulator, formal tool, FPGA board, or prior verification framework is assumed.

COURSE FACTSStage, chapters, units, prerequisite, and outcome
Chapter 1

A requirement becomes an observable obligation

Objective: Why is response identity necessary? Answer by naming the requirement, oracle, observation event, failure mode, and one claim this evidence still cannot support.

A useful requirement names trigger, sampled inputs, permitted latency, expected response, reset and cancellation behavior, and a falsifying observation. Functional verification asks whether an implementation satisfies a written behavioral contract over the situations that matter. A passing test is evidence only for its named design revision, parameters, assumptions, stimulus, oracle, sampling rules, and checked observations. It is never converted silently into proof of timing closure, CDC correctness, physical reliability, security, performance capacity, or fabricated silicon. Each lesson therefore begins by stating an obligation and the observation that could falsify it.

The verification contract is: When in_valid&&in_ready is sampled at edge t, exactly one matching response must be transferred between edges t+2 and t+4 unless reset cancels it. The retained invariant is: accepted count equals completed count plus live obligations after every observation edge outside reset. Before running anything, map requirement identifiers to stimulus partitions, independent expected results, assertions, coverage, and failure artifacts. Record clock and reset semantics, transaction identity, legal and illegal inputs, latency range, backpressure, ordering, cancellation, and parameter boundaries. The known failure “Checking only that some out_valid occurs permits the wrong request identity or a duplicate response to pass.” is kept as a mutation target so that evidence must detect a plausible defect rather than merely observe activity.

accepted count equals completed count plus live obligations after every observation edge outside reset. This invariant is checked only at declared observation boundaries and under declared assumptions; a disabled, unreachable, or unobserved antecedent cannot count as meaningful success.

Create one obligation record at acceptance. At derivation step 1, identify the requirement, sampled values, transaction identity, independent expected value, and the exact comparison or property that closes the obligation.

Age it on each declared observation edge and compare identity/data on response. At derivation step 2, identify the requirement, sampled values, transaction identity, independent expected value, and the exact comparison or property that closes the obligation.

Fail on duplicate, missing, early, late, or mismatched completion; cancel only under the reset rule. At derivation step 3, identify the requirement, sampled values, transaction identity, independent expected value, and the exact comparison or property that closes the obligation.

Trace accepts A at t0 and B at t2, with responses A at t3 and B at t6. Predict the complete event or transaction trace before revealing the result, including reset, idle, acceptance, latency, stall, response, and timeout where relevant.

  1. A window is t2..t4 and its t3 response is legal. At trace step 1, record pre-sample state, sampled inputs, monitor event, oracle update, checked output, assertion status, and whether the observation is architectural or testbench-local.
  2. B window is t4..t6 and its t6 response is legal. At trace step 2, record pre-sample state, sampled inputs, monitor event, oracle update, checked output, assertion status, and whether the observation is architectural or testbench-local.
  3. Identity matching closes each obligation once and conservation returns to zero live obligations. At trace step 3, record pre-sample state, sampled inputs, monitor event, oracle update, checked output, assertion status, and whether the observation is architectural or testbench-local.

Result: Both obligations complete exactly once within their own windows. Accept this result only after the baseline passes, the named fault changes the expected check or property to fail at its first responsible boundary, and the restored baseline passes from a clean rerun.