1. Purpose and scope
The aim is to find logic errors while they are still cheap to find. An FPGA can be reprogrammed, which tempts teams to skip simulation and debug on the board. That is usually slower: on hardware, visibility is limited to the signals an on-chip logic analyser captures, each rebuild takes a full implementation run, and failures may depend on board conditions. Simulation gives full visibility and fast iteration, and clock domain crossing analysis finds faults that hardware tests may only reveal rarely.
The depth of verification should match the product's risk. A product under a functional safety or airborne hardware standard needs requirement-based verification with traceable evidence; a lower risk product may rely more on hardware testing. The verification plan records that choice so reviewers can judge whether the evidence is enough.
In scope: block and top-level simulation, coverage closure, assertion and formal checks where planned, lint, clock domain crossing and reset domain crossing analysis, bug tracking and the control of fixes after Design code complete. Out of scope: building the verification environment, which runs alongside the logic from the architecture onwards and is complete when this stage starts; timing closure, which runs in parallel and closes in the next stage; and hardware testing on the board.
12 more sections for registered members.