Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Employ code-coverage analysis to verify 2D graphic engines in automotive apps

Posted: 03 Aug 2012     Print Version  Bookmark and Share

Keywords:graphics displays  IP blocks  verification 

After a regression has finished, the code coverage from all runs first needs to be merged into one database. This database is then provided to Incisive Enterprise Verifier as an input. It will look for all code coverage holes in this database and then run an automatically generated property to check whether the hole is actually reachable or not. If it determines this hole to be unreachable, it will add this to a list of code coverage hole exceptions and will at the end write these out into an exception file. This can then be applied to the merged code coverage database and a new report with code coverage holes can be written out—but without all unreachable holes.

Figure 3: Formal verification helps determine whether coverage holes are unreachable.

All of this can be done in a post-session script of the Incisive Enterprise Manager tool from Cadence (which is used to run regressions called "sessions") in a fully automated manner. So whenever a regression finishes, the resulting code coverage databases are merged, analysed for holes, and an already-filtered code coverage hole report is written out for the review.

Outcomes
When the above flow is applied, several things will come to the forefront.

For example, if the design has a test mode, it will most likely have something like test multiplexers controlled by an external test enable port. Another common case is where the design has an external interface using a protocol that contains some constraints for the design's inputs. In cases like these, you would expect dead code caused by these external constraints to be marked as unreachable in the code coverage analysis flow.

However, as noted above, the flow is (so far) fully automatic and no design-specific setup is done. So there are no constraints that would model any external influence on the module (of a tied port or a protocol).

Now, it would be easy to add these to the code coverage hole analysis; however, we decided against doing so because we are performing code coverage analysis for the single purpose of finding errors in the verification execution. If the verification engineer had misinterpreted an input signal to the design and falsely tied it, or if he/she misinterpreted a protocol and implemented it incorrectly, we would like these to show up in either the functional coverage (which is collected according to the verification engineer's coverage collection implementation and might also be erroneous) or in the code coverage holes.

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 initialisation
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 initialisation. 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 initialisation—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 initialisation makes it possible for the formal tool to create unreachable states right in the first cycle, and as such it will recognise 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 initialisation 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: 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 initialisation to keep the setup completely design-independent. However, as can be seen in the table, it is worth considering adding initialisation for a lot of code coverage holes.

Conclusion
As previously stated, the automatic code coverage analysis by Incisive Enterprise Verifier is 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 initialisation). So for us, the effort necessary to utilise the automatic analysis is small compared to the gain from saved review time. We recommend that you give it a try.

About the author
Florian Mueller is a design engineer at Fujitsu Semiconductor Europe. He is responsible for top-level design, integration, and signoff on Iris 2D graphic sub-system and is also participating in sub-module design and verification.

To download the PDF version of this article, click here.


 First Page Previous Page 1 • 2



Comment on "Employ code-coverage analysis to ver..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top