What is Metric Driven Verification (MDV)?

Metric Driven Verification (MDV) is a methodology in which the verification process is guided and measured by quantifiable metrics, rather than simply writing tests and hoping for completeness.

MDV helps you plan, track, and closely monitor verification efforts based on measurable goals like coverage, assertion passing rate, bug rate, etc., and not just simply running a lot of tests.

Why is MDV important?

In modern SoCs and IPs like Cryptography, graphics, etc., designs are very complex, using multiple protocols , configurations, use cases, etc. So, blindly writing tests without a goal and a way to measure progress will not ensure quality verification, which later can turn out to be fatal.

MDV ensures:

• Scientific proof that design is thoroughly verified
• Predictable verification closure timeline
• Early identification of bugs and corner scenarios for verification
• Focused efforts based on missing coverage
• Gives high confidence in the quality of verification

What metrics are we talking about?

NOTE: To know more in detail about different types of coverages, read this post: Different types of coverage in Metric Driven Verification (MDV)

MDV FLOW

1. Create a Verification Plan (vPlan): In tools like Cadence vManager, vPlan consists of 2 main important components: Requirements/Features and Verification metrics

• Define features to be verified. These are mainly the customer requirements or IP requirements, which should be verified to close verification.
• Define metrics for each feature that should be directly mapped with it, which serves as a proof of verification for that particular feature/requirement (e.g., functional coverage points).

2. Develop Tests and Environment: This is the main executing phase where Testbench and its components need to be defined. Sequences and tests will be the ones to verify the requirements/features.

• Write UVM testbench components.
• Develop sequences and checkers targeting features.

3. Run Simulations and Collect Metrics: Tools like Cadence vManager, Questa, and VCS help in running regressions, which then can be analyzed to see the Metrics and simulation results for debugging.

4. Analyze Coverage Reports: The main goals of this are:

• Identify unhit coverage points.
• Find untested scenarios or missed corner cases.

5. Refine and Add Tests:

• After analyzing the metrics, write more directed or random tests to target unhit coverage/scenarios.
• Add more constraints, assertions, or monitors.

6. Repeat Until Closure: Closure means all planned metrics are satisfied (e.g., 100% coverage).

Example

Suppose you have an AXI bus design in your RTL. The requirement is “All burst types must be covered”. Now, to fulfil this requirement, the verification engineer will create a functional coverage and test for it. The test will generate a stimulus to probably cover this, and functional coverage will act as proof whether this scenario is covered or not.

Covergroup will look like this:

covergroup burst_type_cg @(posedge clk);
  coverpoint axi_burst_type {
    bins fixed = {0};
    bins incrementing = {1};
    bins wrapping = {2};
  }
endgroup

During simulation, the tool will report different types of burst types it has seen using this functional coverage model.

Conclusion

Metric Driven Verification transforms verification from an art to a science by using quantifiable metrics to plan, monitor and close verification activities. By defining clear requirements, coverage goals and continuously monitoring the verification progress, verification teams can achieve predictable quality and accelerate time to market.