Verification plan

Notes

Linking the plan to the coverage database turns a static document into an automatically updated progress dashboard.

Overview

A verification plan is the living document that turns a chip's specification into a list of features to verify, and records for each one how it will be verified, by whom, and how success will be measured. Progress against the plan, usually tracked through linked coverage results, is the main measure of how close a design is to being verified.

How it works

Planning starts from the specification and from architects and designers explaining how the design is meant to work. The team breaks the design into features and sub-features, including error cases, configurations and interactions between blocks. For each item the plan names a method, such as constrained-random simulation, directed tests, formal verification, emulation or post-silicon checks, an owner, and the evidence that will count: functional coverage points, assertions, or specific tests passing.

Modern planning tools let teams write the plan in a structured form and link each item to coverage data from regressions, so the plan becomes a live dashboard. Holes show features with no coverage, or coverage that cannot be reached, and reviews decide whether to add tests, change the plan or accept a waiver.

The plan is updated as the specification changes and as bugs reveal gaps. Its sign-off, with all items closed or waived, is usually a condition for tapeout.

Examples

• A plan for a DMA controller listing transfer types, error responses and power states, each linked to coverage items.
• A coverage dashboard showing that low-power entry and exit scenarios are still untested two weeks before freeze.
• Assigning cache coherence corner cases to formal verification because simulation cannot reach them reliably.
• Adding new plan items after a bug found on an FPGA prototype reveals a missed interaction.

Why it matters

Verification consumes a large part of chip development effort, and without a plan teams cannot say what has been checked or decide when to stop. Verification leads and managers own it, design verification engineers execute it, designers and architects review it, and project managers use its metrics to judge schedule risk. Escaped bugs often trace back to features that were never in the plan.

In the chip lifecycle the plan is written as architecture and specifications settle, drives verification through design, and is closed at verification signoff before tapeout.

It matters most to: Design Verification Engineer, SoC Verification Lead, Verification Architect, Verification Manager

Common confusions

Not the same as testplan

The verification plan says what must be verified and how success is measured. A testplan lists the specific tests and scenarios that carry it out. Verification plan vs testplan

Not the same as the specification

The specification says what the design should do. The verification plan says how the team will prove it does.

Sources

1. Verification Plan (Knowledge Center) (opens in a new tab), Semiconductor Engineering, 2026-10-22
2. Planning Out Verification (Ed Sperling, 28 September 2018) (opens in a new tab), Semiconductor Engineering, 2026-10-22
3. Rapid Evolution For Verification Plans (Brian Bailey, 28 October 2019) (opens in a new tab), Semiconductor Engineering, 2026-10-22
4. What is Functional Verification? (opens in a new tab), Synopsys, 2026-10-22

Related terms

• Testplan
• Coverage closure
• Verification signoff
• Functional coverage

Where it appears on the Hub

Used on 65 pages of the Hub. In each group, the pages that mention it most come first.