Design Article
Using code-coverage analysis to verify 2D graphic engines in automotive apps
Florian Mueller
7/20/2012 6:20 PM EDT
Added value
If the verification engineer adds his/her understanding of design constraints such as tied inputs and protocols to the formal code coverage analysis, he/she might make this code coverage analysis flow obsolete because there is no chance of finding errors like the ones mentioned above. And not adding these constraints has the advantage of making the flow setup completely independent from the design.
Importance of initialization
One further aspect could make the results from the code coverage hole analysis even better while also making the setup design-dependent, and that is initialization. A formal tool always starts at a certain state of the design. Usually this is the state found after the reset has been applied. But the formal tool can also run without design initialization—all state elements in the design will then be undefined and the formal tool can choose to set them however it sees fit.
This is the case in the above described flow, where no design-specific setup is being made. However, starting without initialization makes it possible for the formal tool to create unreachable states right in the first cycle, and as such it will recognize unreachable holes in code coverage as reachable. So some holes that could actually be filtered out will be left behind in the result. For this reason there will be results both with and without initialization provided later on. Overall in our verification, this code coverage hole analysis flow has significantly reduced the amount of review to be undertaken. So far we have used it on a small but growing collection of sub-components and the results can be found in the following table:
Table 1 – Code coverage hole analysis reduces the need for manual review
As demonstrated in the table, a significant amount of the code coverage holes are actually unreachable. In our case, this is mostly due to reuse in different contexts. As we need to review each code coverage hole for signoff, the given percentages above equal the amount of effort saved doing the reviews. Usually by default we are still doing our code coverage hole analysis without initialization to keep the setup completely design-independent. However, as can be seen in the table, it is worth considering adding initialization for a lot of code coverage holes.
Conclusion
As previously stated, the automatic code coverage analysis by Incisive Enterprise Verifier is very simple to set up and execute. In our case, we integrated it into our template verification environment; so every verification engineer will have it available without any additional effort (unless they decide to use initialization). So for us, the effort necessary to utilize the automatic analysis is small compared to the gain from saved review time. We recommend that you give it a try.
Florian Mueller (Florian.Mueller@de.fujitsu.com) is a design engineer at Fujitsu Semiconductor Europe (FSEU). He is responsible for top-level design, integration, and signoff on Iris 2D graphic subsystem and is also participating in sub-module design and verification.
http://emea.fujitsu.com/semiconductor
If the verification engineer adds his/her understanding of design constraints such as tied inputs and protocols to the formal code coverage analysis, he/she might make this code coverage analysis flow obsolete because there is no chance of finding errors like the ones mentioned above. And not adding these constraints has the advantage of making the flow setup completely independent from the design.
Importance of initialization
One further aspect could make the results from the code coverage hole analysis even better while also making the setup design-dependent, and that is initialization. A formal tool always starts at a certain state of the design. Usually this is the state found after the reset has been applied. But the formal tool can also run without design initialization—all state elements in the design will then be undefined and the formal tool can choose to set them however it sees fit.
This is the case in the above described flow, where no design-specific setup is being made. However, starting without initialization makes it possible for the formal tool to create unreachable states right in the first cycle, and as such it will recognize unreachable holes in code coverage as reachable. So some holes that could actually be filtered out will be left behind in the result. For this reason there will be results both with and without initialization provided later on. Overall in our verification, this code coverage hole analysis flow has significantly reduced the amount of review to be undertaken. So far we have used it on a small but growing collection of sub-components and the results can be found in the following table:
|
|
Subcomponent 1 |
Subcomponent 2 |
Subcomponent 3 |
Subcomponent 4 |
|
Code coverage holes |
484 |
101 |
50 |
18 |
|
Unreachable holes (without initialization) |
194/40% |
19/19% |
8/16% |
8/44% |
|
Unreachable holes (with initialization) |
376/78% |
24/24% |
9/18% |
8/44% |
Table 1 – Code coverage hole analysis reduces the need for manual review
As demonstrated in the table, a significant amount of the code coverage holes are actually unreachable. In our case, this is mostly due to reuse in different contexts. As we need to review each code coverage hole for signoff, the given percentages above equal the amount of effort saved doing the reviews. Usually by default we are still doing our code coverage hole analysis without initialization to keep the setup completely design-independent. However, as can be seen in the table, it is worth considering adding initialization for a lot of code coverage holes.
Conclusion
As previously stated, the automatic code coverage analysis by Incisive Enterprise Verifier is very simple to set up and execute. In our case, we integrated it into our template verification environment; so every verification engineer will have it available without any additional effort (unless they decide to use initialization). So for us, the effort necessary to utilize the automatic analysis is small compared to the gain from saved review time. We recommend that you give it a try.
Florian Mueller (Florian.Mueller@de.fujitsu.com) is a design engineer at Fujitsu Semiconductor Europe (FSEU). He is responsible for top-level design, integration, and signoff on Iris 2D graphic subsystem and is also participating in sub-module design and verification.
http://emea.fujitsu.com/semiconductor
|
|
|
|
|
Navigate to related information
MontyFuller
2/14/2013 9:52 PM EST
In an exhibition that I recently attended, where Fujitsu is one of the exhibitors, they covered this analysis extensively in one of the breakout sessions they had for those interested. It was quite informative, but at the same time, too information heavy that many of the audience left more baffled rather than clarified. I would suggest that Fujitsu take extra care to have high level of information provided during exhibitions, and hopefully bring the discussion at a different time and venue for those who would like to take it further. The article seems to have covered most of it, and I am glad to have stumbled upon this after their presentation. http://www.discountdisplays.co.uk
Sign in to Reply