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:
|Deadcode||Deadcode checks identify unreachable lines of RTL code|
|Synthesis pragma checks||Verify RTL meets intent of synthesis pragmas|
|FSM Checks||Verify all FSM states and arcs are reachable, and verify state deadlocks cannot occur|
|Bus Checks||Verify 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 Checks||Verify array index assignments are never out of bounds|
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!