Home > Community > Blogs > Functional Verification > why can t you write my assertions for me part 2
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).
 

Email

* 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: *

Why Can’t You Write My Assertions for Me? - Part 2

Comments(2)Filed under: Functional Verification, Incisive, ABV, CPF, IEV, formal, IFV, NextOp, assertion synthesis, assertions, CDC, Conformal, formal verification, constraints, Palladium, assertion-based verification

In my last post, I described three different types of automatic assertions: those derived from the design, those derived from the design with some assumptions such as naming conventions, and those derived from the design plus supplemental files expressing some aspect of design intent. I finished by mentioning the approach taken by NextOp, which analyzes simulation traces to "learn" about a design's behavior and generates appropriate assertions (and coverage). I'm intrigued enough by their "assertion synthesis" technology to spend some time discussing it in this follow-up post.

I should note first that the idea of "learning" correct or intended design behavior by analyzing simulation traces is not a new one. In my past experience with assertion-based verification companies and product lines, this notion has been discussed and a few skunk-works projects have been tried. The focus was always on "learning" interface protocols, with the belief that if you watch the behavior on an interface long enough most of the legal protocol will be exercised and, if the design has been verified on a previous project, no illegal behavior will occur.

When I first heard about what NextOp was doing, I figured that their focus would be on input protocols with the goal to generate a set of assertions capturing the protocol rules. As I discussed at a recent DVCon panel, I believe that this capability can be a very important link from simulation to formal analysis. One of the big barriers to formal is the requirement to write input assertions that constrain the analysis to stay in legal state space. After all, hitting a targeted coverage point with an illegal input sequence doesn't qualify as closing a coverage gap. Likewise, triggering an assertion with an illegal input sequence forces the verification team to spend time diagnosing an apparent bug that probably isn't real.

I have little doubt that NextOp can and will add value in the transition from simulation to formal input constraints. However, as I've talked more to the NextOp team and read their material, two important distinctions beyond my assumptions have emerged. First, NextOp seems to be quite successful at generating "white box" assertions internal to the design. This is a very powerful feature for formal analysis, because without assertions to target a formal tool will never find any bugs. Generating both input constraints and internal assertions is a great way to move from simulation into formal.

Second, NextOp generates coverage points as well as assertions. This capability is also powerful since formal analysis can target these coverage points and thereby help close coverage gaps. But the value of the "white box" assertions and covers that NextOp generates doesn't rely on formal being used. Any generated assertions and covers can be run in simulation, in a simulation accelerator, or even within an in-circuit emulator. The white-box assertions are valuable internal checks for design bugs and the covers help to assess how well the design is exercised during the verification process.

I can see why NextOp's customers are excited about their approach. An Altera user report on DeepChip last month last month stated "We added approximately 95% of the 250 generated properties to our simulation." That report impressed me; based on what I've seen in the past I would have expected only half or two-thirds of the synthesized assertions and covers to be worth using. If you want to hear more about their approach, a NextOp user from Broadcom will be presenting at this week's DVClub meeting in Silicon Valley. I strongly encourage you to attend; the DVClub events are always well run and stimulating.

The other presentation at this week's meeting is by Cyclic Design regarding their use of Zocalo's assertion solutions. No matter how successful NextOp may be, there will always be assertions in a designer's head that can't be extracted by an EDA tool, as well as new portions of the design that do not have simulation testbenches available yet. Thus, there will always be a subset of assertions that must be written by the design and verification engineers. Zocalo focuses on making this task easier. I'll discuss their approach in Part 3 of this blog series.

Tom A.

The truth is out there...sometimes it's in a blog.

Comments(2)

By anu Bohra on April 25, 2011
Hi Tom,
I agree with you that in the early days  to get started with writing Assertions was to review the waveforms. That is how the validation team in Cadence where I was part of initially started writing the safety properties when ABV was started.
There is a free whitepaper  too of Bugscope from NextOp with Verdi from Springsoft at www.nextopsoftware.com/.../NextOp_SpringSoft_WP.pdf.
How does IFV or IEV fare on the automatically generated assertions by NextOp, especially in terms of supporting the synthesized assertions  and its  performance with IFV/IEV.

By tomacadence on May 17, 2011
Anu, NextOp is a Connections partner and tests its generated assertions with Incisive Enterprise Simulator, Incisive Formal Verifier and Palladium XP.
Tom A.

Leave a Comment


Name
E-mail (will not be published)
Comment
 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.