HOME       UP       PREV       NEXT (Validation using Simulation)  

ABD - Assertion-Based Design

The Z notation for formal specifications is quite well known and suitable for describing properties of data structures. Other examples from software are object constraint language (OCL), Alloy and so on. Database integrity and consistency rules are also common examples of assertions.

Assertions should be machine readable and machine provable, as far as possible. There's even a school of thought that assertions should be executable, whenever possible, thereby generating example output that conforms to what is specified.

All four forms can potentially be proved by automated provers, such as model checkers. Contemporary, industrial SoC design only uses fully automated provers, whereas research in specification and verification often uses manually-guided provers where the computer may make suggestions about proof steps buts its main role is to check the result has been derived without a false step.

Declarative assertions are written either as assertions about the current state or about state trajectories (i.e. sequences of states). In general, trajectory expressions can be compiled into a checker automata (or RTL sub-circuit) and a state assertion can be applied to the output function (terminal) of the automata (RTL module).

A declarative assertion about the current state is intrinsically universally quantified over time, so really it is about all states. Applying the same reasoning to a trajectory assertion implies that the property holds for all occurrences of the trajectory, whether overlapping or not.

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

ABD shows up corner case problems not encountered in simulation. And in some cases, such as medical life-support systems, a formally-verified result may be required by the customer.

2: (C) 2008-13, DJ Greaves, University of Cambridge, Computer Laboratory.