| |||
|---|---|---|---|
|
|
||
HOW TO CHECK WHETHER THE TESTBENCH HAS SATISFACTORILY EXERCISED THE DESIGN
Code coverage is used to measure the efficiency of verification implementation. It provides a quantitative measurement of the testing space. It describes the degree to which the source code of a DUT has been tested. It is also referred as structural coverage.
Code coverage answers the questions like
Have all the branches in " Case ", "if" have been entered?
Have all the conditions in "if","case" statement is simulated?
Have all the variables have been toggles?
Have all the statements of the RTL code have been exercised?
Have all the states in the FSM has been entered and all the legal transitions exercised?
Have all the paths within a block have been exercised?
By applying code coverage analysis techniques to hardware description languages, verification efficiency was improved by enabling a verification engineer to isolate areas of un-tested HDL code. The verification engineer examine a coverage report, seeks out the low values and understands why that particular code hasn't been tested fully and writes more tests or directs randomness to cover the untested areas where there may be a possibility of bug hiding.
No additional coding is required to get 100 percent code coverage , the tool would automatically show the item as covered if the required test scenario(s)/combination(s) is(are) exercised.
In unit level verification, a module by module is verified in its own test environment to prove that the logic, control, and data paths are functionally correct. The goal of module level verification is to ensure that the component/unit being tested conforms to its specifications and is ready to be integrated with other subcomponents of the product. Code coverage becomes a criterion for finishing unit level testing as it needs to verify every feature of component/unit. In sub-system level /system level, the goal is to ensure that the interfaces among the units are correct and the units work together to execute the functionality correctly. In sub system level /system level testing, code coverage may not be useful as the verification is not targeted at all the features of the unit.
Code coverage is used to measure the efficiency of verification implementation. It provides a quantitative measurement of the testing space. It describes the degree to which the source code of a DUT has been tested. It is also referred as structural coverage.
Code coverage answers the questions like
Have all the branches in " Case ", "if" have been entered?
Have all the conditions in "if","case" statement is simulated?
Have all the variables have been toggles?
Have all the statements of the RTL code have been exercised?
Have all the states in the FSM has been entered and all the legal transitions exercised?
Have all the paths within a block have been exercised?
By applying code coverage analysis techniques to hardware description languages, verification efficiency was improved by enabling a verification engineer to isolate areas of un-tested HDL code. The verification engineer examine a coverage report, seeks out the low values and understands why that particular code hasn't been tested fully and writes more tests or directs randomness to cover the untested areas where there may be a possibility of bug hiding.
No additional coding is required to get 100 percent code coverage , the tool would automatically show the item as covered if the required test scenario(s)/combination(s) is(are) exercised.
In unit level verification, a module by module is verified in its own test environment to prove that the logic, control, and data paths are functionally correct. The goal of module level verification is to ensure that the component/unit being tested conforms to its specifications and is ready to be integrated with other subcomponents of the product. Code coverage becomes a criterion for finishing unit level testing as it needs to verify every feature of component/unit. In sub-system level /system level, the goal is to ensure that the interfaces among the units are correct and the units work together to execute the functionality correctly. In sub system level /system level testing, code coverage may not be useful as the verification is not targeted at all the features of the unit.
Index
Asic Design
Bottle Neck In Asic Flow
Functional Verification Need
Testbench
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!
Asic Design
Bottle Neck In Asic Flow
Functional Verification Need
Testbench
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!