In this article, let us see how functional coverage is different from code coverage and how we use it to sign off the design verification.
Why Functional Coverage?
We need functional coverage data to track whether all the DUT features have been verified and measure the quality of verification. Functional coverage data will reveal the answer to all important questions that we ask to sign-off the verification.
- Have we verified all the DUT features?
- Have we generated all kinds of test scenarios?
- How thoroughly can we verify?
- When can we sign-off the verification?
- How can we redefine the constraints to target the uncovered DUT feature?
- How can we classify testcases and optimize the regression test-suite?
What is Functional Coverage?
Functional coverage is the coverage data generated from the user defined functional coverage model and assertions usually written in SystemVerilog. During simulation, the simulator generates functional coverage based on the stimulus. Looking at the functional coverage data, one can identify the portions of the DUT[Features] verified. Also, it helps us to target the DUT features that are unverified.
We use functional coverage mainly to create an executable verification plan. In the case of random simulation, we define a verification plan in terms of DUT features and map the functional coverage data with each feature. During simulation, we can back-annotate the coverage data to the verification plan and track the simulation progress. This is very different from the traditional test plan we create for the directed testcases. Refer my article: Test Plan Vs Verification Plan
As shown in the above figure, this is how the coverage model is created in terms of coverage bins to verify the design. In this example, we verify a 1X3 Router DUT using functional coverage. In order to confirm that this router works fine, we need to verify whether the Router can route all kinds of packets to all the channels.
In this coverage model, we have created coverage bins for all kinds of packets – Small Packet [SP], Medium Packet [MP], Big Packet [BP] and Corrupt Packet [CP] and for all the channels – Channel 0, 1 & 2 [CH_0, CH_1 & CH_2]. Finally, we cross all the coverage bins and try to fill 4X3 [12 cross-bins – 4 Packets X 3 Channels] during simulation.
100% coverage of all 12 cross-bins indicates that the router works fine, confirming that the Router can route all kinds of packets to all the channels. This is how we use functional coverage to verify the DUT features and sign-off the verification.
Also, the number of bins and cross-bins depends on the complexity of DUT functional features and time available [number of days/weeks/months allocated for simulation]. Usually, experienced verification managers/leads will analyze everything [Time Vs Quality] and define the coverage targets as part of the verification plan for verification engineers like you who would be writing testcases and running regression simulation. Refer my article: Code Coverage
