- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Validation - Formal verification -

- 2 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Validation

- 3 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Formal verification  Formal verification = formally proving a system correct, using the language of mathematics.  Formal model required. Obtaining this cannot be automated.  If the model is available, we can try to prove properties.  Even a formally verified system can fail (e.g. if assumptions are not met).  Classification by the type of logics.  Formal verification = formally proving a system correct, using the language of mathematics.  Formal model required. Obtaining this cannot be automated.  If the model is available, we can try to prove properties.  Even a formally verified system can fail (e.g. if assumptions are not met).  Classification by the type of logics.

- 4 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Propositional logic (1)  Consisting of Boolean formulas comprising Boolean variables and connectives such as  and .  Gate-level logic networks can be described.  Typical aim: checking if two models are equivalent (called tautology checkers or equivalence checkers).  Since propositional logic is decidable, it is also decidable whether or not the two representations are equivalent.  Tautology checkers can frequently cope with designs which are too large to allow simulation-based exhaustive validation.  Consisting of Boolean formulas comprising Boolean variables and connectives such as  and .  Gate-level logic networks can be described.  Typical aim: checking if two models are equivalent (called tautology checkers or equivalence checkers).  Since propositional logic is decidable, it is also decidable whether or not the two representations are equivalent.  Tautology checkers can frequently cope with designs which are too large to allow simulation-based exhaustive validation.

- 5 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Propositional logic (2)  Reason for power of tautology checkers: Binary Decision Diagrams (BDDs)  Complexity of equivalence checks of Boolean functions represented with BDDs: O(number of BDD-nodes) (equivalence check for sums of products is NP-hard). #(BDD-nodes) not to be ignored!  Many functions can be efficiently represented with BDDs. In general, however, the #(nodes) of BDDs grows exponentially with the number of variables.  Simulators frequently replaced by equivalence checkers if functions can be efficiently represented with BDDs.  Very much limited ability to verify FSMs.  Reason for power of tautology checkers: Binary Decision Diagrams (BDDs)  Complexity of equivalence checks of Boolean functions represented with BDDs: O(number of BDD-nodes) (equivalence check for sums of products is NP-hard). #(BDD-nodes) not to be ignored!  Many functions can be efficiently represented with BDDs. In general, however, the #(nodes) of BDDs grows exponentially with the number of variables.  Simulators frequently replaced by equivalence checkers if functions can be efficiently represented with BDDs.  Very much limited ability to verify FSMs.

- 6 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund First order logic (FOL) FOL includes quantification, using  and . Some automation for verifying FOL models is feasible. However, since FOL is undecidable in general, there may be cases of doubt. FOL includes quantification, using  and . Some automation for verifying FOL models is feasible. However, since FOL is undecidable in general, there may be cases of doubt.

- 7 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Higher order logic (HOL) Higher order allows functions to be manipulated like other objects. For higher order logic, proofs can hardly ever be automated and typically must be done manually with some proof- support. Higher order allows functions to be manipulated like other objects. For higher order logic, proofs can hardly ever be automated and typically must be done manually with some proof- support.

- 8 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Temporal logic (1) Logic extended with a notion of "time" Branching vs. linear time:  Linear time Models physical time At each time instant, only one of the future behaviors is considered.  Branching time (at each time instant, all possible future behaviors are considered). Models different computational sequences of a system. Nondeterministic selection of the path taken. Logic extended with a notion of "time" Branching vs. linear time:  Linear time Models physical time At each time instant, only one of the future behaviors is considered.  Branching time (at each time instant, all possible future behaviors are considered). Models different computational sequences of a system. Nondeterministic selection of the path taken. T. Kropf: Introduction to Formal Hardware Verification, Springer, 1999

- 9 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Temporal logic (2) Discrete vs. continuous time  Discrete time Used by most temporal logics, mostly using natural numbers to model time.  Continuous time Using real numbers Discrete vs. continuous time  Discrete time Used by most temporal logics, mostly using natural numbers to model time.  Continuous time Using real numbers ℕ ℝ T. Kropf: Introduction to Formal Hardware Verification, Springer, 1999

 P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Temporal structures Definition: A temporal structure M:= (S,R,L) consists of 1.A finite set of states S 2.A transition relation R  S  S with  s  S  s'  S:(s,s')  R 3.A labeling function L: S  (V), with being the set of propositional variables (atomic formulas) This structure is often called Kripke structure. Definition: A temporal structure M:= (S,R,L) consists of 1.A finite set of states S 2.A transition relation R  S  S with  s  S  s'  S:(s,s')  R 3.A labeling function L: S  (V), with being the set of propositional variables (atomic formulas) This structure is often called Kripke structure. T. Kropf: Introduction to Formal Hardware Verification, Springer, 1999

 P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Link between temporal structures and computation trees Starting state s°  S defined ab cbc s°s° s²s²s1s1 ab bc c c cab Temporal structure Computation trees T. Kropf: Introduction to Formal Hardware Verification, Springer, 1999

 P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Computation tree logic (CTL) Let V be a set of atomic propositions CTL formulas are defined recursively: 1.Every atomic proposition is a formula 2.If f 1 and f 2 are CTL formulas, then so are  f 1, f 1  f 2, AX f 1, EX f 1, A[f 1 U f 2 ] and E[f 1 U f 2 ] AX f 1 means: holds in state s° iff f 1 holds in all successor states of s° EX f 1 means: There exists a successor such that f 1 holds A[f 1 U f 2 ] means: always until. E[f 1 U f 2 ] means: There exists a path such that f 1 holds until is f 2 satisfied. Let V be a set of atomic propositions CTL formulas are defined recursively: 1.Every atomic proposition is a formula 2.If f 1 and f 2 are CTL formulas, then so are  f 1, f 1  f 2, AX f 1, EX f 1, A[f 1 U f 2 ] and E[f 1 U f 2 ] AX f 1 means: holds in state s° iff f 1 holds in all successor states of s° EX f 1 means: There exists a successor such that f 1 holds A[f 1 U f 2 ] means: always until. E[f 1 U f 2 ] means: There exists a path such that f 1 holds until is f 2 satisfied. Christoph Kern and Mark R. Greenstreet: Formal Verification In Hardware Design: A Survey, ACM Transactions on Design Automation of Electronic Systems, Vol. 4, No. 2, April 1999, Pages 123–193.

 P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Model checking Aims at the verification of finite state systems. Analyzes the state space of the system. Verification using this approach requires three stages:  generation of a model of the system to be verified,  definition of the properties expected, and  model checking (the actual verification step). Aims at the verification of finite state systems. Analyzes the state space of the system. Verification using this approach requires three stages:  generation of a model of the system to be verified,  definition of the properties expected, and  model checking (the actual verification step).

 P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund 2 types of input Verification tools can prove or disprove the properties. In the latter case, they can provide a counter-example. Example: Clarke’s EMC-system Verification tools can prove or disprove the properties. In the latter case, they can provide a counter-example. Example: Clarke’s EMC-system

 P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Computational properties  Model checking is easier to automate than FOL.  In 1987, model checking was implemented using BDDs.  It was possible to locate several errors in the specification of the future bus protocol.  Extensions are needed in order to also cover real-time behavior and numbers.  Model checking is easier to automate than FOL.  In 1987, model checking was implemented using BDDs.  It was possible to locate several errors in the specification of the future bus protocol.  Extensions are needed in order to also cover real-time behavior and numbers.

 P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Examples of successful verification (1) Microprocessors 1.Generic interpreter theory 2.Pipelined processors 3.FM AAMP5 5.PowerPC transistor level verification [Kühlmann, 1995] Floating point units 1.Intel extended precision FPU 2.ADK IEEE floating point multiplier Microprocessors 1.Generic interpreter theory 2.Pipelined processors 3.FM AAMP5 5.PowerPC transistor level verification [Kühlmann, 1995] Floating point units 1.Intel extended precision FPU 2.ADK IEEE floating point multiplier Christoph Kern and Mark R. Greenstreet: Formal Verification In Hardware Design: A Survey, ACM Transactions on Design Automation of Electronic Systems, Vol. 4, No. 2, April 1999, Pages 123–193.

 P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Examples of successful verification (2) Asynchronous and distributed systems 1.Summit bus converter 2.Cache coherence protocols Memory subsystems ATM switch fabrics Asynchronous and distributed systems 1.Summit bus converter 2.Cache coherence protocols Memory subsystems ATM switch fabrics Christoph Kern and Mark R. Greenstreet: Formal Verification In Hardware Design: A Survey, ACM Transactions on Design Automation of Electronic Systems, Vol. 4, No. 2, April 1999, Pages 123–193.

 P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund The end Lectures: Peter MarwedelSlides: Peter MarwedelLabs: Birgit Sirocic, Robert PykaTextbook: Peter MarwedelCopyright: University of Dortmund, MMV