will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST). login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > Industry Insights > webinar report new methodology revs up code coverage analysis
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Webinar Report: New Methodology Revs Up Code Coverage Analysis

Comments(0)Filed under: Industry Insights, verification, Freescale, Metric-driven verification, Functional Verification, Formal Analysis, webinar, formal verification, coverage, coverage metrics, code coverage, case splitting, coverage holes, dead code, case-splitting

Most IC verification teams use code coverage as signoff criteria, but they often have limited information about unreachable code. A new "case-splitting" methodology, described in a recently archived webinar, shows how a technique based on formal analysis provides new insight into coverage holes -- while requiring no understanding of formal analysis.

The webinar is titled "Simplifying Code Coverage Analysis: Automatically Separating the Wheat from the Chaff." It was presented by Joe Hupcey, Cadence product marketing director, and Jose Barandiaran, senior member of consulting staff.

Barandiaran began the webinar by talking about the "dead code challenge." There are two causes of unreachability, he noted. One is that the code is "illegal" in the sense that it was never intended to execute - perhaps the code came with externally acquired IP and the system doesn't use that particular functionality. That's generally okay. The other cause is that the code is supposed to be functional, but it's unreachable. That is not okay.

Are Coverage Holes Reachable?

However, it is often difficult to determine whether coverage holes are unreachable. That's where the case-splitting technique comes in. It leverages formal analysis (using Incisive Formal Verifier or Incisive Enterprise Verifier) "under the hood" to determine if holes are reachable. It's an automated flow in which properties are automatically generated, and no knowledge of formal analysis is required.

The diagram below shows how it works. You pass a simulation coverage database to the formal engine, along with a reused, or newly created, simulation snapshot. You select either module or instance-level analysis, and identify the code coverage targets for the formal engine to analyze. The formal tool generates the properties and runs them. The tool then reports unreachable holes, and back-annotates them into the coverage database so you can go into a reporting tool later and analyze each one, determining whether they represent code that's supposed to be functional and thus needs to be fixed.

Barandiaran noted that there are some performance tradeoffs to consider. Out of the box, this flow will run without any constraints, and it will run uninitialized. That's the fastest approach but it may also miss some unreachable coverage holes. You can dial up the constraints and/or initialization and run more slowly, but hit more unreachable holes.

In one customer example shared during the webinar, an uninitialized run on a design with 40K state bits uncovered 773 coverage holes in 2.8 hours, with 7.6% of the holes unreachable. An initialized run found more unreachable holes (10% of 773), and ran for 35 hours. However, this run time was cut to 5 hours because the flow was distributed over a CPU network.

This example, and others presented during the webinar, shows that this case-splitting methodology is in use today by customers. "This has been exercised in the field. It's not just some lab experiment. It really works quickly and cleanly, and you get the data in a very straightforward manner," Hupcey said.

The webinar also included a demo, in which it took only a few minutes to find 33 coverage holes, of which 9 were unreachable. "If you have the tools already, this is really a no-brainer," Barandiaran said.

The webinar is available to Cadence Community members here (quick and easy free registration if you're not a member). If you already have the Incisive Enterprise Verifier, see chapter 5 of the user guide for an explanation of the case-splitting technique.

For those who want to know more, a paper from CDNLive! India 2011 details Freescale's experience with the case-splitting technique. It is available to Cadence Community members here. Look for session 1.6 under track 1, Silicon Realization: Functional Verification.

Richard Goering



Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.