Verification Plan

A verification plan is a structured document and methodology that defines what needs to be verified in a design, how it will be verified, and how the team will know when verification is complete. Without a verification plan, simulation efforts are uncoordinated and corner cases are missed, leading to silicon bugs after tape-out. For GATE aspirants and practicing engineers alike, understanding the distinction between directed testing and random testing is fundamental to this planning process.

Core Concept Explanation

A verification plan, also called a test plan, is created before simulation begins. It enumerates the features of the design, the scenarios that exercise each feature, the pass or fail criteria for each scenario, and the coverage metrics that indicate completeness. In practice, the plan is derived from the design specification document and maps each requirement to one or more verification scenarios. The plan ensures that every engineer on the team is working toward a common measurable goal.

Directed Testing Strategy

In directed testing, the verification engineer manually writes specific input sequences that target known important scenarios. For a FIFO, directed tests would include: writing until full, reading until empty, simultaneous read and write, reset behavior, and back-to-back transactions. Each test is a self-contained Verilog initial block that applies inputs and checks outputs. Directed tests are deterministic, always produce the same results, and are fast to debug because the engineer knows exactly what each test is exercising.

The limitation of directed testing becomes apparent as design complexity grows. A 32-bit ALU has over 4 billion possible input combinations. Writing directed tests for all meaningful combinations is impossible. Even writing tests for all instruction types with boundary values requires careful planning and still leaves large portions of the input space uncovered. Directed testing is necessary for critical protocol sequences but insufficient for full functional coverage alone.

Random Testing Strategy

In random testing, the testbench generates input vectors using $random or the SystemVerilog randomize() method and applies them to the design in a loop. The outputs are checked against a reference model. Because the inputs are generated algorithmically, thousands to millions of test vectors can be applied in the same simulation time it would take to write a handful of directed tests. The key advantage is discovering corner cases that the engineer did not anticipate when writing the directed tests.

Random testing requires two supporting elements. First, a scoreboard or reference model that independently computes the expected result for every random input and compares it with the DUT output. Second, a coverage model that tracks which regions of the input space and state space have been exercised. Without coverage tracking, there is no way to know when to stop running random simulation. The simulation continues until coverage reaches the target threshold defined in the verification plan.

Mathematical Expression

Coverage is often quantified as a percentage. Functional coverage is defined as: Coverage (%) = (Covered bins / Total bins) x 100. Coverage bins are defined in the verification plan and correspond to specific input combinations, state transitions, or output conditions. For example, for an 8-bit input, one might define bins for: all zeros, all ones, values 1 to 127 (positive), and values 128 to 255 (MSB set). Total bins = 4. If random simulation hits all 4 bins, coverage = 100 percent. The number of simulation cycles needed to close all bins follows a statistical distribution related to the number of bins and the probability of hitting each bin per cycle.

Practical Understanding

Modern verification environments combine directed and random testing in a layered approach. The base layer is directed tests that cover the most critical protocol sequences and reset behavior. On top of this, random tests run with coverage tracking to fill in the remaining input space. When coverage plateaus (new random runs stop hitting uncovered bins), targeted directed tests are written for the specific uncovered scenarios. This combination is called coverage-driven verification (CDV) and is the industry standard for complex ASIC verification.

Verification closure, the point at which the team declares simulation complete, is defined in the verification plan as meeting all of: 100 percent line and branch coverage of RTL, all functional coverage bins closed, all directed tests passing, and all assertions clean (no failures). In modern designs, formal verification is also added to complement simulation for specific properties. The verification plan is a living document updated as the design evolves and new scenarios are identified during simulation.

Given:
An 8-bit comparator DUT has 3 output conditions: A > B, A < B, A == B.
Verification plan defines coverage bins for all 3 output conditions.
Random testing: apply 1000 random (A, B) pairs.

Why this formula applies:
Coverage % = (covered bins / total bins) x 100
Total bins = 3 (GT, LT, EQ)

Formula:
  Coverage (%) = (Covered_bins / Total_bins) x 100

Substitution:
After 100 random vectors:
  A > B occurred: 48 times (bin GT covered)
  A < B occurred: 47 times (bin LT covered)
  A == B occurred: 5 times (bin EQ covered)
  All 3 bins covered after 100 vectors.
  Coverage = (3/3) x 100 = 100%

Now consider a harder bin:
  Add bin: A = 255, B = 255 (both max)
  Probability of hitting per random vector = 1/256 x 1/256 = 1/65536
  Expected vectors to hit this bin = 65536
  With 1000 vectors, probability of hitting = 1 - (1 - 1/65536)^1000 = ~1.5%
  This bin likely needs directed test to close reliably.

Final Answer:
General bins close quickly with random testing.
Rare corner case bins require directed tests.
Verification plan must identify which bins need directed coverage.

Exam Tip: In a verification plan, directed tests guarantee coverage of specific known scenarios while random tests expand coverage breadth. A plan using only directed tests is insufficient for full coverage. A plan using only random tests may miss critical protocol sequences. Both are always used together in production verification.

Mechanism: Coverage-Driven Verification Flow

• A verification plan maps every design feature to test scenarios, pass criteria, and coverage bins before any simulation begins.
• Directed tests are written for critical, known scenarios: reset sequences, boundary conditions, and specific protocol handshakes that must always be verified.
• Random tests use $random or SystemVerilog randomize() to generate large volumes of input vectors automatically, finding unexpected corner cases.
• Coverage bins define specific conditions that must be exercised. Coverage closure means all bins have been hit at least once during simulation.
• When random simulation plateaus and new runs stop closing bins, targeted directed tests are written specifically for the uncovered rare scenarios.

Quick Revision

• Verification plan: maps design features to test scenarios, pass criteria, and coverage metrics before simulation starts.
• Directed testing: manually written, deterministic, targets specific known scenarios. Limited scale but high confidence for covered cases.
• Random testing: auto-generated inputs with reference model checking. Scales to millions of vectors. Needs coverage tracking for termination.
• Coverage formula: Coverage (%) = (covered bins / total bins) x 100. Coverage closure = 100% bins hit.
• CDV flow: write directed tests -> run random with coverage -> analyze report -> add directed tests for gaps -> repeat until 100% closure.
• Scoreboard: checks DUT output against reference model for every random input. Without scoreboard, wrong outputs go undetected.
• Exam trap: random testing alone cannot guarantee correctness without a reference model for output checking. Random input generation and output checking are two separate and both required components.