Home > Community > Blogs > Functional Verification > hate writing assertions no problem let automatic formal analysis do the work
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).


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

Hate Writing Assertions? No problem: let Automatic Formal Analysis do the work

Comments(0)Filed under: Functional Verification, Formal Analysis, Incisive, ABV, IEV, formal, IFV

OR: “Leverage automatic checks extracted from designs without writing a single assertion”


What if a push button solution existed that ran a set of assertion checks on a design but did not require a single assertion to be written?  Would you use it?  Of course you would.  However, many people believe that in order to benefit from Incisive Formal Verifier (IFV) or Incisive Enterprise Verifier (IEV) you need to know how to write assertions of some form.  The good news: this is not true -- you can actually start meaningful formal verification without writing a single assertion at all!  The secret is a capability of IFV & IEV aptly called Automatic Formal Analysis – “AFA” for short.

Simply stated, AFA automatically extracts from the design common assertions that can easily be overlooked, or are just plain tedious to write by hand.  Either way, because the checks are automatically created, they are generated consistently across the entire RTL code base, and the correctness of the assertions are guaranteed. The not-so-hidden bonus here is that no time will be required to debug the assertions.  Instead, the engineer is free to focus solely on debugging failures or incorrect RTL behavior.

Anyone on a design or verification team can and should run the AFA capability on all designs in the same way you run code coverage in dynamic simulations; i.e. just turn it on and let the machine do the work.  In short, AFA is a simple and low effort verification activity that can catch bugs from the beginning.

What kinds of extracted checks are we talking about, exactly?  Examples AFA checks include showing any unreachable lines of code, unreachable FSM states, or out of bounds index assignments. AFA also checks to ensure ‘X’ assignments never happen, and that you never have bus contention.  The chart below summarizes all the different types of AFA checks:


DeadcodeDeadcode checks identify unreachable lines of RTL code
Synthesis pragma checksVerify RTL meets intent of synthesis pragmas
FSM ChecksVerify all FSM states and arcs are reachable, and verify state deadlocks cannot occur
Bus ChecksVerify proper bus behavior (never floating, no contention, never have multiple drivers driving different data)
X-assignment checks (Xchecks)Verify X assignments never happen
Range Overflow ChecksVerify array index assignments are never out of bounds


Running AFA
The following screen shots show examples of how AFA works with IFV.  The first screen shot shows deadcode checks running on RTL; the second screen shot shows the failure and the corresponding lines of code that are not reachable. This is all possible with a click of a button.  (Note: while this initial example is about deadcode, note that AFA checks run similarly on RTL for all the checks listed in the chart above.)


Figure 1 – How to identify unreachable line of code (Fail deadcode check)

How to Run Automatic Checks
AFA Checks can be enabled in two ways: using the tools’ GUI, or via a TCL command.

Using the GUI:

1. Select the relevant categories of Automatic Formal Analysis checks by clicking on the relevant tab.
2. Use the right mouse button click and select “Assertion -> Add All”
3. Repeat steps (1) and (2) above for any and all categories of assertions you want to prove.
4. Click the “Prove” button

Using a TCL command:

1. From the “formalverifier” prompt type:

formalverifier> assertion –add –automatic

This will add all AFA checks to be proven
2. Next, from the formalverifier prompt type:


For best results, Team Verify recommends proper design initialization as a prerequisite to running AFA.  We also recommend running with constraints; with the caveat that running without constraints may generate false failures but may be useful in certain categories of AFA assertions such as deadcode.

If you are new to IFV or IEV, you may want to start without any input constraints at all, and just get value from running the deadcode assertions on your design.  Later, after the addition of constraints, you will reduce the amount of false failures you will debug.   All such guidance, and a full description of AFA’s capabilities, are documented in Chapter 10: Automatic Formal Analysis in the Incisive Formal Verifier User Guide.  It is also available from the IFV installation tree at <root>/doc/ifvuser/ifvuser.pdf

Automatic Formal Analysis – “AFA” for short – should be run on every design (like code coverage in dynamic simulation) since it’s built-in and automatic.  Whether you are an expert that just wants to save time by letting the machine deal with the “basics”, or you are new to assertion-based verification and are intimidated by writing a set of assertions or from scratch, AFA provides you a set of automatically extracted assertions that can help you verify your design.

Finally, if you have used AFA please share your experiences with this capability in the comments below.

Happy bug hunting!

Team Verify



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.