The Future of Specman
Fitzpatrick on SystemVerilog

Writing Assertions

Yesterday I wrote up an overview of Tom Fitzpatrick's AVM tutorial last week at DVCon.  Today, I'm going to discuss Harry Foster's presentation on writing assertions.   If you want to know what assertions are and what they are for, check out Harry's book – Assertion Based Design.  If you don't have time to read the book, the concept behind assertions is relatively simple.  Basically, when someone designs a module, they often make a set of assumptions about the inputs and outputs of a module, legal state transitions, etc.  Those assumptions can be captured as a set of assertions. If the assertion is ever violated, the simulation will fail, allowing a user to easily trace a problem back to its source.  Assertions can also be used to provide functional coverage information for a design.

According to Harry, the first thing to do when writing assertions is to take a step back and write them up as natural language requirements. If you spend the time writing out exactly what you're trying to achieve in plain English (or whatever language you use on a daily basis), you will find that you've described exactly the sort of information you need to write your assertions in SVA. The best thing to do is to create a table, similar to this one:

Property Name


Bus Legal Transactions


Initial state after reset is INACTIVE.


Bus Stable Signals


Slave signal remains stable from START to ACTIVE



Now that you have a list of the things you would like to check, start writing your assertions. Not quite sure how to write them in SVA? No problem! Harry suggests that you write your assertions in plain Verilog if you find it easier! Go through each requirement and write the associated assertions. One word of advice - Harry recommends not allowing assertions to print out their own messages. Instead, pass information about assertion failures back out through analysis ports (if you're using AVM).

Once you've got the hang of writing assertions, you may want to consider writing an assertion-based monitor. The monitor doesn't need to know anything about the rest of the testbench. To create your assertion-based monitor:

  • Define a list of interface signals.
  • Describe the behavior of the interface you're trying to monitor.
  • List the "natural language" requirements of the interface.
  • Create the corresponding assertions.
  • Encapsulate properties (assertions and coverage) in a module.

That's it! Sounds easy, doesn't it? So who should be writing these assertions? My view is that because designers are the most intimately familiar with their own modules, they should be the ones creating assertions for the internals of devices. Verification engineers can then write assertions describing the protocols between modules. Of course designers can write these as well, leaving more time for the verification team to create the rest of the test environment.