Home > Community > Blogs > Functional Verification > why can t you write my assertions for me part 3
 
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 3

Comments(0)Filed under: Functional Verification, Incisive, ABV, CPF, IEV, formal, IFV, assertion synthesis, Zocalo, assertions, CDC, Conformal, formal verification, constraints, Palladium, assertion-based verificationMy last two posts have dealt with various forms of automatic assertion creation and assertion synthesis. There is little doubt that these approaches have significant value, complementing and even replacing some of the assertions written by design and verification engineers. However, I started out this series by stating "assertions are supposed to capture the assumptions in the designers' heads and no EDA tool (at least so far) can read their minds." Barring electrodes in the brain that can output SVA, at least some assertions will continue to be manually written.

There are two fundamental challenges in writing assertions -- thinking about what needs to be captured and understanding the format to capture it. Automatic assertions help with the first challenge but for the most part the second challenge has not been addressed. It really should be; modern assertion languages such as SVA (SystemVerilog Assertions) and PSL (Property Specification Language) are quite complex. They allow engineers to express deeply nested and overlapping signal sequences with varying repetition patterns. Writing such an assertion -- or understanding one that someone else has written -- can be a daunting task.

Using an assertion-checker library (such as OVL, Accellera's Open Verification Library) rather than directly writing assertions can reduce the effort, but this comes at considerable loss of flexibility. Assertion libraries themselves can be complex, with dozens of arguments and options for each checker in the library. Often the engineers end up putting some much "helper" logic around each checker instantiation that they end up moving to SVA in order to take advantage of its rich (albeit complex) capabilities.

Perhaps what's needed is an assertion IDE (integrated development environment) that helps engineers construct and visualize assertions using some sort of graphical format. @HDL (now Axiom Design Automation) introduced a suite of tools in this domain way back in 2003. A quick check of Axiom's site shows that they still offer an "SVA Debug Engine" with unrolling of assertion expressions and on-the-fly assertion modification and instantaneous assertion evaluation to enable "what-if" analysis.

Zocalo, an Austin-based EDA company, has gone beyond assertion debugging to focus on assertion construction as well. I view its solution as essentially an assertion IDE. Zocalo has developed a slick method to view all the components of an SVA expression, complete with drag-and-drop elements that can be used to construct a very complex assertion without having to be an expert on the syntax and semantics of the language. Courtesy of Zocalo, here is a screenshot showing an assertion constructed visually, followed by the SVA code generated from the visual representation.

 

 

 

 

 

Many engineers don't take advantage of the full power of SVA because they can't visualize exactly what they want to express and, even if they can, don't understand the details of the language well enough to capture their intent. Zocalo has significant potential for removing these roadblocks. For those who prefer assertion libraries, Zocalo also automates the instantiation of checkers from OVL. In addition, the visual view can be generated from existing assertions, a big help for engineers who "inherit" SVA code that they don't understand. I'm really glad to see the Zocalo offerings in the market; for more information see Richard Goering's interview or visit their site.

Summarizing this series, there is a lot of help available for project leaders who see the value of assertion-based verification (ABV) and want to adopt it, but are having a hard time convincing their engineers to write assertions. Automatic assertions, assertion synthesis, and assertion IDEs all provide partial solutions to this dilemma. Taken together, they should make ABV ready for everyone. If you're not joining the bandwagon, please comment and let me know why.

Tom A.

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

 

Comments(0)

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.