Assertions

Assertion-based design (ABD) is an approach that encourages writing assertions as early as possible, preferably before coding/implementation starts.

1. Writing assertions at design capture time before detailed coding starts.
2. Writing further assertions as coding/development progresses.
3. Using the same assertions at product test time.
4. Embedding the assertions as run-time monitors in the product for reporting or automatic shutdown/failsafe.

   assert(x<4);            // Example imperative saftey assertion
   x := x + 1000; 
   assert(x<1004);         // Some programmers think this is the only form of assertion.

Programmers are used to dynamically validating imperative assertions embeded in procedural programming:

• Imperative (aka immediate) safety checks (like assert.h in C++ and expect in SystemVerilog)

• Also dynamic coverage checks (log that flow of control has passed a point or a property held).

On the other hand declarative programming (aka logic programming) involves writing assertions that hold for all time.

For instance, on an indicator panel never is light A on at the same time as light B.

Declarative assertions are (conjunctions of):

• Declarative safety properties, that always hold, such as `Never are both the inner and outer door of the airlock open at once unless we are on the ground'. Safety properties normally use the keywords never or always.

• Liveness and deadlock properties, such as `If the emergency button is pressed, eventually at least one of the doors will be unlocked.' Liveness properties normally use keywords such as eventually or it will always be possible to.

All four forms can be proved by formal techniques such as pen and paper, theorem provers and model checkers.

Dynamic validation is simulation (or execution) while checking properties. This can sometimes find safety violations and, with careful constructionm detect deadlock, but it cannot prove the liveness or that safety won't be violated.

Assertions can be imported from previous designs or other parts of the same design for global consistency.

Formal proof shows up corner case problems not encountered in simulation.

A formally-verified result may be required by the customer.