Day 01 / 25
Day 02 →
HomeVerificationDay 1 — What is Design Verification
Track 1 — Foundations

What is Design Verification?

Design verification is the discipline that ensures an RTL design does exactly what its specification says — before you spend millions of dollars fabricating silicon. This tutorial covers the full DV landscape: what it is, how it differs from RTL design, and what a DV engineer does day-to-day.

⏱ 15 min read 📖 Day 1 of 25 🎯 Fundamentals
Contents
  1. What is Design Verification?
  2. DV vs RTL Design — Key Differences
  3. Types of Verification
  4. Simulation vs Formal Verification
  5. Coverage-Driven Verification Flow
  6. Role of a DV Engineer
  7. Industry Tools
Spec / Architecture RTL Design (Design Eng) Testbench / UVM (DV Eng) Simulation / Formal Coverage Analysis Signoff / Tape-out Bug found → fix RTL
ASIC design flow — DV drives simulation, catches bugs before tape-out

1. What is Design Verification?

Design verification (DV) is the process of checking that an RTL (Register Transfer Level) design correctly implements its specification. The key word is checking — DV engineers do not change the design, they observe it and report discrepancies.

In the ASIC development flow, a specification document (micro-architecture spec, or "uArch") describes exactly what the chip should do. The RTL design engineer writes Verilog/SystemVerilog that implements it. The DV engineer writes a testbench that exercises that RTL and catches any deviation from the spec.

Why is DV critical? A tape-out costs $1–5 million for advanced nodes. A missed bug means a re-spin — same cost again plus 3–6 months of schedule. Finding the same bug in simulation costs hours.

2. DV vs RTL Design — Key Differences

AspectRTL Design EngineerDV Engineer
Code typeSynthesizable Verilog/VHDLNon-synthesizable SystemVerilog
GoalImplement the functionFind bugs in the implementation
MindsetBuilder / constructorAdversarial tester / breaker
Key skillsRTL coding, timing, synthesisUVM, SVA, constrained random, coverage
DeliverablesRTL files, synthesis reportsTestbench, coverage report, sign-off
Ratio1 design engineer2–3 DV engineers (large chips)

3. Types of Verification

Functional Verification

Checks that the design does what the spec says. This is the primary job of DV — using simulation (testbench drives inputs, checks outputs) or formal methods (mathematical proof of properties).

Structural Verification

Checks physical aspects: Design Rule Check (DRC), Layout vs Schematic (LVS), antenna checks — these are post-layout checks done by physical design, not DV.

Equivalence Checking (LEC)

Proves that the gate-level netlist after synthesis/place-and-route is logically equivalent to the RTL. Synopsys Formality and Cadence Conformal are the industry tools.

Static Timing Analysis (STA)

Checks all timing paths meet setup and hold constraints — this is not simulation but a mathematical analysis of the gate-level delay graph.

Formal Verification

Uses model checking engines to mathematically prove properties for all possible inputs — complementary to simulation, especially powerful for protocol checkers and safety properties.

4. Simulation vs Formal Verification

PropertySimulationFormal Verification
CoverageFinite test vectors onlyAll possible inputs / states
ScalabilityScales to full chipLimited to ~1M state variables
Bug findingDepends on test qualityGuaranteed for checked properties
CounterexampleWaveform traceMinimal failing sequence (CEX)
ToolingVCS, Xcelium, QuestaSimJasperGold, VC Formal, Questa Formal
Best forFull-chip, end-to-end flowsProtocol properties, safety checks
Industry practice: Most projects use both. Formal is used to verify protocol compliance (AXI handshake rules, FIFO full/empty) while simulation handles full-system integration scenarios.

5. Coverage-Driven Verification Flow

Random simulation alone is not enough — you need to know what has been tested. Coverage-driven verification (CDV) adds a measurement layer:

  1. Write a Verification Plan (VPlan): List all scenarios that must be tested, derived from the spec. Each scenario maps to a coverage bin.
  2. Generate constrained-random stimulus: UVM sequences randomize inputs within protocol-legal constraints. Each random test exercises different corner cases.
  3. Run regression: Hundreds of random seeds in parallel on a compute cluster.
  4. Measure coverage: Functional coverage (covergroups) + code coverage (line/branch/toggle) are collected and merged.
  5. Analyze holes: Uncovered bins are identified. Write directed tests to hit them, or relax/tighten constraints.
  6. Sign-off: When all functional coverage goals are met (typically 100% for critical, 95%+ overall), verification is complete.
VPlan Coverage Goals CRV Stimulus rand sequences Simulation Regression runs Coverage Measure & Merge Holes → directed tests or new seeds ✓ Signoff 100% goals

6. Role of a DV Engineer

Day-to-Day Tasks

Skills Required

7. Industry Tools

CategorySynopsysCadenceSiemens EDA
SimulationVCSXceliumQuestaSim / ModelSim
FormalVC Formal / JasperGold*JasperGoldQuesta Formal
CoverageVerdi / URGIMC (Incisive Metrics Center)UCDB / Questa Coverage
Waveform debugVerdi / DVESimVisionVisualizer
LECFormalityConformal

*JasperGold is a Cadence product, widely considered the industry-leading formal tool.

Open-source alternative: Icarus Verilog (iverilog) + GTKWave for simulation, Verilator for fast cycle-accurate simulation, SymbiYosys for formal — useful for learning and open-source projects.

Key Takeaways — Day 1

Next → Day 02
Verilog Testbench Basics
DUT instantiation, clock & reset generation, stimulus with initial blocks, $monitor, self-checking with $fatal, and file I/O.