Benefits of Assertions

Assertions incorporated into a design benefit both the design and verification engineer. Much of a designer's time is actually spent debugging problems found in the design during the verification process. Typical issues that arise during verification (especially for constrained-random testing) include:

While we (as designers) appreciate the work being done by the verification engineers to test our designs, we also secretly dread the sight of them in our doorway, since that generally means something failed that we now need to debug. In this case, we have to either interrupt our current work or put off debugging the testcase until we get to a good stopping point. Both scenarios result in an interruption of the verification engineer's work, but I suspect many verification engineers dread the latter scenario, since it often means they must interrupt work on testbench development progress to ensure the failing case can be reliably recreated.

In many cases, assertions allow us to break this cycle. They essentially act as red flags during simulation pinpointing failures that may either directly cause test failures or not be detected by passing tests.

Assertions on module interfaces can quickly identify invalid behavior that may be caused by a behavioral model or improper use of the design (invalid register settings, invalid operating modes, etc). Such assertion failures indicate that a problem may be with the testbench, allowing the verification engineer not only to pinpoint the cause of the failure, but also to quickly update the testbench and continue with verification, often without even having to consult the design engineer. In cases where the design is at fault, the design and verification engineers can quickly resolve the issue without extensive debug, because they know where and when the failure occurred.

Internal design assertions also help locate the root cause of failures that directly result in testcase failures. For instance, constrained-random testbenches often find corner cases such as FIFO overflow/underflow conditions that are normally not exercised by directed tests. Debugging failures such as these takes time since the designer has to trace back the failure at the end of a test (which may simply be invalid data in system memory) to the root cause of the failure. Including even a few simple assertions on internal FIFOs or interfaces will often locate these failures at the time and point of failure, eliminating the need for a lengthy debug session.

Lastly, assertions improve reuse since they capture design intent that may be lost as design and verification engineers familiar with the design move to new projects. Some of this information may be captured in micro-architecture documents, but who really reads the manuals unless there is a problem? With assertions present, it is far more likely that problems integrating reusable logic will be found.

Ultimately, designers like to create things. As design engineers begin to understand how assertions reduce debug time and effort, they will realize that time spent creating assertions pales in comparison. Some designers may even come to view adding assertions as a creative challenge.