Hi Friends, This time I decided to write about Assertions. I personally feels Assertions are very handy and highly useful asset when we talk about Functional Verification i.e. finding the bugs in the given RTL design & ensuring Verification completeness. Its an amazing Verification Technology which provides so much benefits with so much of less code. If you gone through my previous post on Assertions i.e. “Basics about Assertions..??”, we discussed there about an Assertion example and compared with the corresponding Verilog code.

Here, lets go through additional numerous advantages of using Assertions as part of Verification process:

1. Assertions helps to shorten the time to debug

In a typical design, we’ve State elements as Flops, Combo logic, FIFOs (First-In First-Out), FSM (Finite State Machine), Counters etc. If we assume this design contains RTL bugs which usually a typical design have, we apply Stimulus on the Primary Inputs and observe the Response at the Primary Outputs. Lets assume the Test fails, what normally we do? We start debugging means doing back tracing starting from the Primary Outputs. We need to keep going inside the design till we find the root cause of the failure. Finally we fix the issue but it takes long time to reach to the root cause of the issue. This approach is usually called Black Box Testing but the thing is Observability is also Black Box in this approach.

Now lets say, we insert the Assertions around the different logic elements in the Design and Assertion fails during the simulation. With Assertions, the root cause of the internal bug is observed directly at the source & the simulation time. So with Assertions being inserted, we can say that we’re now doing Black Box Testing with White Box Observability. Here bottom line is Assertions can help to improve Observability inside the Design hence shorten the time to debug.

2. Assertions helps to shorten the time to cover

In our Design, we want to ensure that all the spatial and temporal conditions are covered or exercised by the provided stimulus and things are operating as per the specifications of the Design. Assertion ‘cover’ feature helps to provide report or coverage status about the various design elements e.g. FIFOs, FSMs, Counters. In addition, ‘cover’ can be very helpful for temporal behavior requirements on Primary Inputs, Primary Outputs and Inter-module communication.

Lets take an example how ‘cover’ can be useful:

Lets assume we wrote an Assertion for FIFO full condition but with the current set of Stimulus this Assertion never fires. We may assume everything is OK since there is no Assertion failure in the Simulation logfile. But how about if FIFO full condition is never triggered by the provided stimulus? In such scenarios, analyzing the report generated by Assertion ‘cover’ feature will show us what is not covered vs what is covered by the given stimulus. It will certainly help us to shorten the time to cover all the expected scenarios for the Design.

3. Assertion support for Clock Domain Crossing (CDC) logic

Now a days, we hardly find Designs with single clock, most of the today’s designs are multi-clock domain based. Using multiple clocked Assertions properties can be very helpful for the data integrity checks while crossing different clock domains.

4. Assertions Reusability

Assertions can be re-used across multiple projects if these are developed with the intent keeping in mind. As everyone knows, reusability aspect is a powerful factor to save time & effort for future projects. Assertion can be written in following two such ways to promote Assertions reusability:

The first approach is – to implement parameterized Assertions wherever possible. E.g. Assertion written today for a 16-bit bus can be re-used for 32-bit bus for future designs if parameterization is used.

The second approach is – to implement Assertions modeled outside of the RTL design and maintained it as a separate entity. These Assertions can be easily bound (using ‘bind’ feature) to RTL keeping Design and Assertions code separate. Its easy to maintain and most importantly reusable if coded with proper guidelines.

5. Assertions are always ON

It means Assertions are always active unless we turn them off. The more test cases we add to the Test suite or create new stimulus configurations, the active Assertions always works to monitor the design behavior against the new stimulus.

6. Assertions with Emulation/Acceleration

As Assertion Synthesis is getting into place now a days, it means Assertions can be very useful during the Emulation. Since we know that DUT is placed on the silicon inside the Emulation box, hence the associated Assertion can also be placed inside the Emulation box along with the Design. With this support, in an Emulation run, that runs very fast compared to Simulation, Debugging which usually takes large time can be done much faster.

7. Assertions supports Global Severity Levels

Assertions supports global severity levels e.g. $error, $fatal, $warning..etc. Hence it helps to maintain a uniform error reporting mechanism or structure in Simulation.

8. Assertions supports Global Turn ON/OFF

Assertions supports global turn on/off mechanism e.g. $dumpon/$dumpoff. It helps to maintain the code in a easier way rather than wrapping each Assertion with on/off conditions.

9. Assertions are useful with Static Formal Verification

Now a days Static Formal Verification is getting popular day-by-day. Assertions are the keys elements which defines both the assumptions and the expected behaviors for the Design as part of the Formal Verification Technology.

Static Formal Verification does not require any dynamic vectors to be applied on the Design Primary Input as does in Simulation, yet EDA tool’s internal algorithms generates internal traffic to check the included Assertions & ensure Design correctness. Since Formal Verification works on algebraic equations drawn out of a Cone of Logic, so there might be many inputs of the Logic Cone which might have known values e.g. “1” or “0”. These known values are assigned using the Assertions ‘assume’ feature so that Formal tool executes with lesser permutation and combination of the inputs and produce constructive results with meaningful efforts.

10. One language & Multiple usage

Assertions aka SVA (SystemVerilog Assertions) is such a language which contributes in multiple ways to the the Verification aspects of a Design. Assertions ‘assert’ feature works with Design checks and with Formal Verification (technology without dynamic vectors), Assertions ‘cover’ features support Functional Coverage checks and ‘assume’ feature caters to the Design constraints for the Formal Verification.

It clearly shows that SVA is one language which has many facets and benefits towards Functional Verification supporting both Constrained Random Verification (CRV),  Static Formal Verification (SFV) as well as Emulation/Acceleration.

As always, I reached to the end of this article as well. I would like to conclude here with the “Advantages of the Assertions” in Functional Verification. There are numerous resources available to gain more information about Assertions. My this effort is to share with you my understanding about the various different benefits of using Assertion technology as part of our Verification processes. I hope and believe it will provide you the value of your time being spent on this article. With upcoming article see you again soon!

And yes, I want to pay my gratitude to all the readers who shared their inputs/constructive comments/suggestions with me. I really appreciate and love hearing from you, Always!

Thank you, till next time, byee 🙂