EC-21.2 Assertions, Coverage, and Knowing When Verification Is Finished
You can write assertions that state a design's own rules, distinguish code coverage from functional coverage, and defend a decision to stop verifying with evidence rather than with a feeling.
Before:S4-4. Digital System DesignPE2-1. CMOS Analog and Digital IC DesignUnlocks:EC-25. Semiconductor Test, Packaging and Reliability
The hardest question in verification is when to stop, and the honest answer is a number. Assertions turn assumptions into checks that fire wherever they are violated, including in tests written for something else entirely. Coverage turns how much have we tested into a measurable quantity, provided you understand which of the two kinds of coverage you are looking at, because they answer different questions and only one of them is about intent.
Work through these
An assertion as a rule the design must always obey
Writing down an invariant next to the logic it constrains turns an assumption in somebody's head into a check that runs on every test. Most assertions are written after a bug, and the useful habit is writing them before.
NPTEL: VLSI Design Verification and Test (IIT Guwahati) · CourseImmediate and concurrent assertions, and sequences over time
Some rules are about one instant and some are about a relationship across several clock cycles, and the two are written differently. Being able to express a multi-cycle protocol rule is where assertions start earning their cost.
NPTEL: VLSI Design Verification and Test (IIT Guwahati) · CourseCode coverage: lines, conditions, toggles and states
These measures say which parts of the source the tests reached, which is necessary and not sufficient. Full code coverage with a broken specification is a design that is thoroughly tested against the wrong requirement.
Functional coverage: did we test the things we meant to test
Functional coverage is written by hand from the specification and records which interesting situations actually occurred. It is the only measure that connects the test effort back to what the design is supposed to do.
NPTEL: VLSI Design Verification and Test (IIT Guwahati) · CourseFormal methods, and the small problems they settle outright
A formal tool proves a property for every possible input rather than for the ones you tried, which is decisive on small control logic and impractical on large data paths. Knowing which problems fit is most of the skill.
NPTEL: VLSI Design Flow — RTL to GDS (IIIT Delhi) · CourseThe closure argument: what evidence justifies calling it done
Stopping is a decision that has to be defended with coverage numbers, a list of waived items with reasons, and a record of what the last failures were. A team that cannot produce that has stopped rather than finished.
Sign in to keep your progress.
Free resources
We haven't checked most of these for screen reader use yet.
Links last checked 4 Sept 2026.
Stuck here?
Ask a mentor. A real person answers, and they can see exactly which topic you're on. Usually within a couple of working days.
Checking your session…
Topics shown in module order.