| |||
|---|---|---|---|
|
|
||
MAKE YOUR GOAL 100 PERCENT CODE COVERAGE NOTHING LESS
Never set your goal to anything less than 100% code coverage. Anything less than 100% is a slippery slope. If you set your goal to 98% , may be the most important feature like reset of the system may be in the untested part of2%. If the verification engineer sets the code coverage goal to 95% to facilitate the 5% the unused untestable legacy code, there are chances that the unused legacy code gets executed and the 5% holes may be in the important code. 100% code coverage provides advantages not only in reducing the bug count but also in making it easier to make significant changes to existing code base to remove uncover able areas like the unused legacy blocks in RTL code.
Dont Be Fooled By The Code Coverage Report
Highly covered code isn't necessarily free of defects, although it's certainly less likely to contain them. By definition, code coverage is limited to the design code. It doesn't know anything about what design supposed to do. Even If a feature is not implemented in design, code coverage can report 100% coverage. It is also impossible to determine whether we tested all possible values of a feature using code coverage. For example, randomization may not generate packets with all possible lengths, this cannot be reported by code coverage.. Code coverage is unable to tell much about how well you have covered your logic -- only whether you've executed each line/block etc at least once. Code coverage does not provide information about your test bench randomization quality and it does not report what caused the line execution/state transition etc. Analysis of code coverage require knowledge of design to find which features are not verified which is time consuming and out of scope of verification engineer. If the analysis is done at higher level of abstraction, it would be easier for the test writer to identify the missed serious which is not possible by code coverage. So if the code coverage is less than 100%, it means there is more work to do, if it is 100%, it doesn't mean that the verification is complete.
When To Stop Testing?
It's getting harder to figure out when to stop testing as the complexity of the protocol is increasing. In directed test environment, for each point mentioned in test plan, there will be a separate test case file. So if there are 100 points in test plan, then the engineer has to write 100 test case files. After writing and executing the 100 test case files, we can say that "all the points in test plan are verified" and we can stop testing.
Never set your goal to anything less than 100% code coverage. Anything less than 100% is a slippery slope. If you set your goal to 98% , may be the most important feature like reset of the system may be in the untested part of2%. If the verification engineer sets the code coverage goal to 95% to facilitate the 5% the unused untestable legacy code, there are chances that the unused legacy code gets executed and the 5% holes may be in the important code. 100% code coverage provides advantages not only in reducing the bug count but also in making it easier to make significant changes to existing code base to remove uncover able areas like the unused legacy blocks in RTL code.
Dont Be Fooled By The Code Coverage Report
Highly covered code isn't necessarily free of defects, although it's certainly less likely to contain them. By definition, code coverage is limited to the design code. It doesn't know anything about what design supposed to do. Even If a feature is not implemented in design, code coverage can report 100% coverage. It is also impossible to determine whether we tested all possible values of a feature using code coverage. For example, randomization may not generate packets with all possible lengths, this cannot be reported by code coverage.. Code coverage is unable to tell much about how well you have covered your logic -- only whether you've executed each line/block etc at least once. Code coverage does not provide information about your test bench randomization quality and it does not report what caused the line execution/state transition etc. Analysis of code coverage require knowledge of design to find which features are not verified which is time consuming and out of scope of verification engineer. If the analysis is done at higher level of abstraction, it would be easier for the test writer to identify the missed serious which is not possible by code coverage. So if the code coverage is less than 100%, it means there is more work to do, if it is 100%, it doesn't mean that the verification is complete.
When To Stop Testing?
It's getting harder to figure out when to stop testing as the complexity of the protocol is increasing. In directed test environment, for each point mentioned in test plan, there will be a separate test case file. So if there are 100 points in test plan, then the engineer has to write 100 test case files. After writing and executing the 100 test case files, we can say that "all the points in test plan are verified" and we can stop testing.
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!