In CRV, the each point in test plan is generated automatically. As there points are generated automatically, we need a mechanism which tells us that all the points in test plan are not exercised. When all the points in testplans are verified and the code coverage is 100% we can stop verification.
What are the untested features?

In Directed verification, there will be a separate testcase file for each feature to be verified. So to know how many features are verified, count the testcases. Verification is done when all tests are coded and passing alone with 100% code coverage. In constraint random verification all the features are generated randomly. Verification engineer need a mechanism to know the information about the verified features of DUT.

SystemVerilog provides a mechanism to know the untested feature using functional coverage. Functional Coverage is "instrumentation" that is manually added to the TestBench. This is a better approach then counting testcases. Functional coverage is better than code coverage where the code coverage reports what was exercised rather that what was tested.

Functional coverage answers questions like
Have all the packets length between 64 to 1518 are used?
Did the DUT got exercised with alternate packets with good and bad crc?
Did the monitor observe that the result comes with 4 clock cycles after read operation?
Did the fifos are filled completely?

Summary of functional coverage advantages:
Functional coverage helps determine how much of your specification was covered.
Functional coverage qualifies the testbenchs.
Considered as stopping criteria for unit level verification.
Gives feedback about the untested features.
Gives the information about the redundant tests which consume valuable cycle.
Guides to reach the goals earlier based on grading.

Introduction To Functional Coverage:

SystemVerilog provides 2 ways to mention coverage. Cover group which is uses information from transactor, monitor and checker. Assertion coverage which is uses temporal language which can be outside or inside RTL code.

There are three types of cover group points:
1. item functional coverage point
2. cross functional coverage point
3. transitional functional coverage point


"Item" is used to capture the information about the sclare value. A range of interested values can also be observed.
For example, consider a packet protocol. The packet has a address field with possible values of A0,A1 and data which can be 4 to 10 bytes. At the end of packet parity is also attached for integrity checking.
The following table identifies these coverage points for the above packet:

Item_DL Data length 4 to 10
Item_ADD Address A0,A1
Item_Par Parity Good and Bad

Coverage engine collects item values are during simulation and reports.
Reports consists how many times
Packets with length 4,5,6,7,8,9,10 are generated.
Packets with good parity, bad parity are generated.
Packets with address A0, A1 are generated.


"cross" is used to examine the cross product of two or more item coverage points.
Example: verify DUT by sending both good parity and bad parity packets with all the address.

Cross_ ADD_Par Item_ADD,Item_Par

Coverage report consists how many times
Packets with Address A0 with good parity are generated
Packets with Address A0 with bad parity are generated
Packets with Address A1 with good parity are generated
Packets with Address A1 with bad parity are generated


Transitional functional point is used to examine the legal transitions of a value.
Verify the DUT with incremental packet length from 4 to 10.
Trans_length ( 4 => 5 => 6 => 7 => 8 =>9 =>10)
Coverage engine reports whether this sequence is exercised or not.

Assertion Coverage:

Assertion coverage looks for the desired behavior in RTL. It uses assertion language which is in temporal nature. It has direct access to design variables and designer can add many points in RTL which he wants the verification engineer to cover.
Example: Verify by sending back-to-back packets.

Functional coverage will be discussed in more detail in later chapters.

Verification using functional coverage and randomization is called coverage driven constraint random verification.

Asic Design
Bottle Neck In Asic Flow
Functional Verification Need
Linear Testbench
Linear Random Testbench
How To Check The Results
Self Checking Testbenchs
How To Get Scenarios Which We Never Thought
How To Check Whether The Testbench Has Satisfactorily Exercised The Design
Types Of Code Coverage
Statement Coverage
Block Coverage
Conditional Coverage
Branch Coverage
Path Coverage
Toggle Coverage
Fsm Coverage
Make Your Goal 100 Percent Code Coverage Nothing Less
Functional Coverage
Coverage Driven Constraint Random Verification Architecture
Phases Of Verification
Ones Counter Example
Verification Plan

Report a Bug or Comment on This section - Your input is what keeps Testbench.in improving with time!




copyright 2007-2017 :: all rights reserved www.testbench.in::Disclaimer