where both A and C are trajectory formulas. The intuition is that the antecedent A provides stimuli to the circuit nodes, and the consequentC specifies the expected values at circuit nodes. Informally, the assertion is valid iff every state sequence that satisfies A must also satisfy C.
A trajectory assertion is true for a given assignment φ of Boolean values to the variables in its guards exactly when every trajectory of the circuit that satisfies the antecedent also satisfies the consequent. For a given circuit model M, we define φ |= A ⇒ C to mean that for all σ ∈ T(M), if (φ, σ) |= A then (φ, σ)|= C. The notation
|=A⇒C means thatφ |=A ⇒C holds for all φ.
3.6
STE verification engine
The key feature of this logic is that for any trajectory formulaf and assignmentφ, there exists a unique weakest sequence that satisfies f. This sequence is called the defining sequence for f and is written [f]φ. It is defined recursively as follows:
Definition 3.9. Defining Sequence [mis0]φt n 4 = 0 if m=n and t=0, otherwise X [mis1]φt n 4 = 1 if m=n and t=0, otherwise X [f andg]φt n =4 ([f]φt n)t([g]φt n) [f whenP]φt n =4 [f]φt n if φ |=P, otherwise X [Nf]φt n 4 = [f]φ(t−1)n if t6=0, otherwiseX
For any φ and σ, we have that (φ, σ) |= f if and only if [f]φ v σ. The proof can
be done by inducting on f and unfolding the definition of the STE semantics (|=) and that of the defining sequence. Note that defining sequence for a trajectory formula can return the lattice value >, if the trajectory formula expresses an inconsistent property — for example consider a property that expresses that a node is wired to the Boolean high Vcc and the Boolean low Gnd.
Generally, inconsistencies can also be a result of a faulty implementation given by a circuit’s model or an inconsistent specification (antecedent or a consequent) given by an STE property. The inconsistencies in the consequent of the specification for a given property is captured at the time of computing the defining sequence, while inconsistency in the antecedent or in the circuit’s model is discovered at the time of computing what is called a defining trajectory of the antecedent of the STE property. These checks for inconsistencies are sufficient to detect bugs in models or specifications because of the way STE model checking is implemented, see Theorem 3.1 below.
Defining trajectory of a formula is its defining sequence with the added constraints on state transitions imposed by the circuit model M.
Definition 3.10. Defining Trajectory [
[f]]φ M0n =4 [f]φ0n
[[f]]φ Mt n =4 [f]φt n t M( [[f]]φM(t−1)) n
3.6. STE verification engine 26 It can be shown that for any φ and σ, we have that (φ, σ) |= f, and σ ∈ T(M), if and only if [[f]]φM vσ. The fundamental theorem of trajectory evaluation [96] follows immediately from the previously-stated properties of [f]φ and [[f]]φ.
Theorem 3.1. STE Implementation
M |= A ⇒ C =4 ∀t n.[C]φt n v [[A]]φMt n
For a detailed proof please refer to [48, 96]. The result of comparing the defining se- quence and defining trajectory values is a Boolean expression, encoded as a BDD for efficiency reasons. The intuition is that the sequence characterising the consequent must be ‘included in’ the weakest sequence satisfying the antecedent, that is also consistent with the circuit.
This theorem gives a model-checking algorithm for trajectory assertions: to see if φ |=A⇒C holds for a given φ, just compute [C]φ and [[A]]φ and compare them point- wise for every circuit node and point in time. This works because both A and C will have only a finite number of nested next-time operators N, and so only finite initial segments of the defining trajectory and defining sequence need to be calculated and compared.
In practice, the defining trajectory ofAand the defining sequence ofC are computed iteratively, and each state is checked against the ordering requirement as it is generated. Each state of the defining trajectory is computed from the previous state by simulation of a netlist description of the circuit, in which circuit nodes take on values in {0,1, X}. The STE implementation algorithm is very efficient because it does not need to represent the whole state transition system explicitly, or encode it symbolically.
Several implementations of STE exist, most notably Intel’s Forte [61, 97], which evolved from Seger’s Voss system [95]. This industrial version of Forte integrates model checking, BDDs, circuit model manipulating functions, and a theorem prover all of which is built around a custom general purpose functional language FL [6, 61]. FL is a strongly typed language with the distinguishing feature that Booleans are represented as BDDs that are built into the language as first-class objects. FL provides an easy interface for invoking STE model checking runs, and serves as an extensible platform for expressing specifications. Note however, that the public release of Forte does not include a theorem prover.
We implemented an STE simulator [47], by deeply embedding [91] the STE theory, within the logic of the theorem prover HOL 4 [3]. HOL 4 has evolved from the theorem prover HOL88 [53], and is based on the classical higher-order logic. HOL is implemented in the functional programming language ML. Terms in HOL, have the abstract ML type term, and theorems (of ML type thm) are constructed by the application of core axioms and inference rules only, i.e. by proof.
The advantage of having a deep embedding based, STE implementation in HOL is that we could reason about the STE logic, extend the STE model checking by adding deductive inference rules, and use theorem proving support in HOL. However, since each execution step in the STE model checking run only happens via a proof-step in HOL, the speed of the simulation is very slow.