Formal Verification in Industrial Setting

Reasoning about Embedded System Correctness Embedded Systems

Everywhere Hall of Shame Polar Lander Rover (2004) Therac-25 logic-error file-system error Radiation error

Entertainment

Alice Airbus

Control systems, hardware and software, with many sensors, signal & data processing algorithms, communications over networks

Rigorous Verification and Validation indispensable Generic structure of an Embedded System today

Memory Controllers Interface

Software (Application Programs)

Processor Coprocessors

ASIC

Converters

Analog Digital Analog Embedded Systems Design Flow

Hardware Components Hardware

Concept HW/SW Specification Partitioning

Estimation - Exploration

Software Components Software Dimensions of the challenge

Discrete Architecture Continuous validation Boolean Logic Unit Hybrid Timing System Temporal Logic Microcode validation validation Non-Linear Type Formal FSM Cluster specs Equations Satisfiability Core Reliability validation Hybrid Automata System Synthesizability Problems Protocol Power validation Coverage validation Formal Verification

• Task: Verify if a system design meet its specification • Standard Testing methods losing steam (system dynamics, stochastic, non-linear, mixed, thousands of states….) • Formal Verification showing much promise in recent times The promise of Formal Verification

 An algorithm which takes as input ■ (a) a model of a system A and ■ (b) a property P

and terminates with output ■ (c) a proof that all the behaviors of A satisfy P OR ■ (d) a particular behavior of A that violates P

A A satisfies P Verification Algorithm P Trace of A violating P

 Examples: 1. A: model of autonomous vehicle P: always stays on the road 2. A: model of a traffic control system P: vehicles do not collide

 Is completely automatic Design and Verification

Design

Specification Implementation

Equivalent?

Verification

7 Agenda for this talk

A guided tour of digital design verification ■ Different approaches to verification

A brief overview of software verification

A brief overview of security verification Digital Design: Abstraction Levels

Formalisms introduced at the Entry-Level Exponential growth in circuit size Register Transfer Level (Moore’s Law) always @( posedge clk ) Restricted semantics of begin Programming Languages, if (!rst) begin a1 <= a2; Communicating Concurrent a2 <= ~a1; end; State Machines (CSM) end Gate Level Boolean Logic Finite State Machines

Transistor Level Schematic

9 Design and Verification

specifications does it meet the specs? property micro-architecture checking does it implement the µ-arch? design RTL verification are they equivalent?

gate netlist equivalence are they equivalent? checking layout

10 Design Cycle: Implementation

Specs Document English documents Implementation validation (Spec RTL implementation Design integration vs RTL) Verilog, VHDL Synthesis Equivalence Gate Level Netlist checking Technology mapping Transistor Level Layout (Schematic)

Mask

11 The Verification Challenge

Objective: eliminate design defects before a product is shipped

? ~ Specification = Implementation

The Verification task is becoming more complex:

 Micro-architecture complexities grow  Market requirements get tougher  Technologies change Simulation-based Verification

Design

Test Plan Test Bench

Stimulus Generation Simulation

Coverage Metrics Debug Bug Tracking

13 Exhaustive Simulation is Infeasible

Consider a sequential circuit having N FFs and M inputs

 Exhaustive verification by simulation ■ Reach each state from the initial state ■ At each state verify the behavior for each input vector

 Upper-bound: ■ Number of states: S = O(2N) ■ Number of input vectors at a state: R = O(2M) ■ To reach a state we may have to pass through O(S) states, where each transition requires an input vector ■ Total number of input vectors = O(S X R) = O(2M+N)

14 What’s the Alternative?

 The design must be simulated using a well selected subset of input patterns  Well selected? ■ Test plans and test scenarios ■ Coverage  What do we observe? ■ Detecting errors by comparing a design’s primary outputs with the desired responses may not be the most efficient ● Internal error may take many cycles to propagate to a primary output to be detected ● It may not always propagate to the primary output ■ We must carefully choose the signals to be observed

15 Simulation-based Verification: State of technology

 Tool Support: ■ VCS, Modelsim, NC ■ University tools: Veriwell, Icarus

 State of technology ■ Constrained random test generation frameworks ■ Layered test architectures ■ Test-bench design languages ● Specman e, SystemVerilog, SystemC . Object oriented test support . Can model concurrency ■ Good coverage monitoring ● Can be used to generate test harness for uncovered areas The advent of Formal…..

 And then came formal ■ Explicit ■ SAT-based ■ BDD-based ■ … There is a mathematical way of checking everything The overall picture

system model Yes! M Formal Engine (Does M satisfy ψ ?)

No! + property “counterexample” ψ Where do we get the system model?

hardware abstraction & other (semi-)automated e.g., Verilog or VHDL, transformations source code System model software

e.g., C, C++ , or Java, source code Extended design models Where do we get the properties?

requirements documentation

+ formal properties (insight) (typically based on temporal logic or automata)

canned standard properties & templates (e.g., “deadlock-freedom”) Formal Verification

System  A mathematical model M Desired behavior  A formal specification ψ

The system has M satisfies ψ the required behavior

Model checking Formal Property Verification (FPV)

always !g1 || !g2

always r2 && !r1  next g2 Formal Properties

Temporal Logics (Timed / Untimed, Linear Time / Branching Time): LTL, CTL Early Languages: Forspec (Intel), Sugar (IBM), Open Vera Assertions (Synopsys) Current IEEE Standards: SystemVerilog Assertions (SVA), Property Specification Language (PSL)

22 Model checking

Input: a system M and a specification ψ. Output: does M satisfy ψ?

Fully automatic.

Counter example

Does not scale Advantage of Model Checking

Simulation Checks Only the Values We Select Even Small Systems Have Trillions (of Trillions) of Possible Tests! Advantage of Model Checking

Model Checker Tries Every Possible Input and State! Model Checking: State of technology

 HDL Formal tools: ■ IFV, Magellan, Jasper, OneSpin ■ University tools: SMV, VIS, SPIN

 State of technology ■ Explicit state model checking ● Impractical for large circuits ■ Symbolic model checking ● Uses implicit representation of states and transitions ● BDD, SAT, ATPG ● Scales well to moderate circuits Emerging validation flow

Architectural Specification Executable Specification [Assertions] [SAL, Lustre, SystemC, etc] Consistency Simulation, checks Customization, Perf. Eval. Design intent verification Implementation verification

Module implementation Design integration [Module level assertions] [System-level assertions] Formal-V Simulation Simulation, Dynamic/Semi-Formal Property Verification Dynamic Property Verification

 Verify the properties during simulation  Compromise: Exhaustive simulation is impractical – bugs can escape if the simulation does not cover the buggy run

Test Bench Assertion Monitor

Module under Test Semi-Formal Verification

 Method to leverage formal algorithms in resource-bounded way • Used to find bugs too complex / deep for pure formal search

 Often iterates between random simulation, formal algorithms

 Tool Support: Magellan from Synopsys  Success stories reported from processor verification teams at IBM: The IBM Sixth Sense tool Formal Verification: A Deeper look inside

30 Advent of Formal Methods in EDA

Goal: Exhaustive verification of the design intent within feasible time limits Philosophy: Extraction of formal models of the design intent and the implementation and comparing them using mathematical / logical methods

Formal Properties Design Intent • Temporal Logics (1996: Turing Award: Amir Pnueli) • Adopted by Accelera / IEEE Model • Integrated into SystemVerilog Checking always @( posedge clk ) • Tools: begin Academia: NuSMV, VIS if (!rst) begin a1 <= a2; Register Transfer Industry: Magellan (Synopsys) a2 <= ~a1; end; Level IFV (Cadence) end • 2007: Clarke & Emerson get Turing Award Logical Gate Level Equivalence Checking

Transistor Level

31 What is Formal Verification?

 Formally checking whether the implementation satisfies the specification

Specification Yes Formal checker Implementation No

What are the ways to specify the specification? Types of specifications

 The specification may be: ■ Boolean functions (combinational) – adder, multiplier, etc. ■ An implementation at a higher level of the design ■ A set of temporal properties

■ For the first two: ● We convert both specification and implementation into a common canonical form (BDD, BMD, SAT, etc) ● We then do formal equivalence checking

■ The third calls for Formal Property Verification (FPV) What is Formal Property Verification?

 The design intent is expressed in terms of formal properties.

 We check formally whether the implementation satisfies these properties.

■ If so, the checker reports success ■ Otherwise it produces a counter-example

 The formal method is called model checking Example: A Simple Pedestrian Crossing Control

g1 g2

r2 r1

r1 g1 Control r2 g2

35 Example: A Simple Traffic Control

Properties: 1. Request line r1 has higher priority than request line r2. Whenever r1 goes high, g1 must be asserted for the next two cycles always [ r1 ⇒ next g1 ∧ next next g1 ] 2. When none of the request lines are high, the control parks the grant on g2 in the next cycle always [ ¬r1 ∧ ¬r2 ⇒ next g2 ] 3. The grant lines g1 and g2 are mutually exclusive g1 always [ ¬g1 ∨ ¬g2 ] g2

r2 r1

36 Is the specification correct?

g1 1. always [ r1 ⇒ next g1 ∧ next next g1 ] g2 2. always [ ¬r1 ∧ ¬r2 ⇒ next g2 ] 3. always [ ¬g1 ∨ ¬g2 ]

r2 r1  Consider the case when r1 is high at time t and low at time t+1, and r2 is low at both time steps. ■ The first property forces g1 to be high at time t+2 ■ The second property forces g2 to be high at time t+2 ■ The third property says g1 and g2 cannot be high together ■ We have a conflict !! ■ Lets go back to the specification

37 Pedestrian Crossing: Revised Specs

g1 Properties: g2 1. Request line r1 has higher priority than request line r2. Whenever r1 goes high, the grant line g1 must be asserted for r2 the next two cycles r1 always [ r1 ⇒ next g1 ∧ next next g1 ] 2. When none of the request lines are high, the control parks the grant on g2 in the next cycle always [ ¬r1 ∧ ¬r2 ⇒ next g2 ] revised to always [ ¬g1 ⇒ g2 ] 3. The grant lines g1 and g2 are mutually exclusive always [ ¬g1 ∨ ¬g2 ]

38 Pedestrian Crossing: Is the specs complete?

1. always [ r1 ⇒ next g1 ∧ next next g1 ] g1 2. always [ ¬g1 ⇒ g2 ] g2 3. always [ ¬g1 ∨ ¬g2 ]

r2 r1

 Observation: We can satisfy the specification by designing a control which always asserts g1 and never asserts g2!! ■ We need to add either of the following types of properties: ● Ones which specify when g2 should be high, or ● Ones which specify when g1 should be low ■ Lets go back to the specification

39 Pedestrian Crossing: Revised specs

Properties: g1 1. Request line r1 has higher priority than g2 request line r2. Whenever r1 goes high, the grant line g1 must be asserted for the next two cycles ⇒ ∧ r2 always [ r1 next g1 next next g1 ] r1 2. When none of the request lines are high, the arbiter parks the grant on g2 in the next cycle always [ ¬g1 ⇒ g2 ] 3. When r1 is low for consecutive cycles, then g1 should be low in the next cycle ¬ ∧ ¬ ⇒ ¬ always [ r1 next r1 next next g1 ] New!! 4. The grant lines g1 and g2 are mutually exclusive always [ ¬g1 ∨ ¬g2 ]

40 Model Checking

G(p  F q) yes temporal formula

MC algorithm

no p p q q

finite-state model counterexample Simplistic view

 Formal properties tell us which are the good states / bad states ■ Safety property: Bad states should be unreachable. ■ Liveness property: Some good state is eventually reached.

 A model checking tool checks whether bad states are unreachable / good states are eventually reachable ■ For this they must traverse the state space ■ Main challenge is to perform the traversal symbolically – without explicitly generating all states

42 How does one use FPV?

 Things to know: ■ Syntax and semantics of property specification languages ■ How to express the intent in terms of formal properties ■ Can I express everything in terms of formal properties? ■ Can I verify every property that I write? ■ Are my properties correct? ■ Have I written enough properties? ■ Why does the FPV tool run into capacity issues? ■ How do I integrate FPV into my validation flow? ■ What lies between simulation and FPV? Why do we need “temporal” logic?

Propositional Logic – Boolean formulas

⇔ ∧ a1 Half s cout a1 a2 a2 Adder cout s ⇔ a1 ⊕ a2

r1 g1 TLC r2 g2 Temporal Logic ■ Properties span across cycle boundaries ■ Consider a property of the traffic controller ● If the request bit r1 is true in a cycle then the grant bit g1 has to be true within the next two cycles What does “temporal” mean?

g1 r1 RR r2 Arbiter g2 If r1 is true in a cycle then g1 has to be true within the next two cycles

Temporal worlds r1(0) r1(1) r1(2) r2(0) r2(1) r2(2) g1(0) g1(1) g1(2) g2(0) g2(1) g2(2) ∀ ⇒ ∨ time:0 time:1 time:2 t [ r1(t) g1(t+1) g1(t+2) ] In propositional temporal logic, the time variable t is implicit. • For example, we may write: always r1  (next g1) or (next next g1) Property Specification Languages

 Temporal Logics ■ Linear Temporal Logic (LTL) – linear time ■ Computation Tree Logic (CTL) – branching time

 Forspec – Intel  PSL – Accellera  Open Vera Assertions (OVA) – Synopsys  System Verilog Assertions (SVA) – Accellera  Open Verification Library (OVL) – Accellera Temporal Logics

 Logic extended with the notion of time ■ Reason about propositions qualified in terms of time

 Tradeoff between expressibility and complexity of verification

 Two popular forms of temporal logic for formal verification ■ Linear Temporal Logic (LTL) ■ Computation Tree Logic (CTL) Linear Temporal Logic (LTL)

 Introduced by Pnueli in 1977  Propositional Logic + discrete time  Time is viewed as a single linear sequence of events  Properties specified over a single path  Temporal operators to represent discrete tim ■ p is a proposition – p should hold at current time ■ X p – p should hold at next time ■ F p – p should hold in the future ■ G p – p should hold globally LTL Formulas

X p

F p

G p

p U q

p W q

Time LTL - Examples

 Safety Properties - G ¬(Critical1 ∧ Critical2) ■ Something bad never happens

 Liveness - F (Req1 ∨ Req2) ■ Something Good will eventually happen

 Fairness - G (Req1  F Scheduled1) ■ If something is requested, it eventually gets scheduled The TLC Example

• Either g1 or g2 is always r1 g1 false (mutual exclusion)

g2 G[¬g1 ∨ ¬g2] r2

• Whenever r1 is asserted, g1 is given in the next cycle G[ r1 ⇒ Xg1 ]

• When r2 is the sole request, g2 comes in the next cycle G[ (¬r1 ∧ r2) ⇒ Xg2 ]

• When none are requesting, the controller parks the grant on g2 G[ (¬r1 ∧ ¬r2) ⇒ Xg2 ] Violation!! Duality between Temporal Operators

G p

p holds always

¬p does not hold eventually

¬( ¬p holds eventually )

¬F( ¬p ) Overview of PSL

 Boolean Expressions ■ HDL expressions ■ PSL functions: rose(), fell(), prev(), ... How When What  Temporal Operators ■ always, never, next, until, before, eventually, abort, ... ■ @ -> |-> |=> ; { } [* ] [= ] [-> ] && & | :

 Verification Directives ■ assert, assume, restrict, cover, ...

 Modeling Constructs ■ HDL statements used to model the environment Invariants

Something that should never happen! For example: An underflow should never occur

Verification Directive

How Temporal When Operator Boolean What Expression

assert_no_underflow : assert never (read && empty); How When What label (to apply) (expression (to check) should be true) The verification method

Formal properties P True Specification Model Checker False M Implementation Counterexample

To prove mathematically that the machine M satisfies its specification P ■ M is typically a finite state machine (often called a Kripke structure) ■ P is typically a set of formal properties capturing the design intent

 State of technology ■ Significant body of literature ■ Widely used in chip design industry ● Language standards (PSL, SVA) + wide arsenal of tools ■ Becoming mandatory in railway and automotive safety standards Model Checking

 Developed independently by Clarke and Emerson and by Queille and Sifakis in early 1980’s.

 Properties are written in propositional temporal logic.

 Systems are modeled by finite state machines.

 Verification procedure is an exhaustive search of the state space of the design.

 Model checking complements testing/simulation Mutual Exclusion Example

• Two process mutual exclusion with shared semaphore

• Each process has three states • Non-critical (N) • Trying (T) • Critical (C)

• Semaphore can be available (S0) or taken (S1)

• Initially both processes are in the Non-critical state and the semaphore is available --- N1 N2 S0

N1 → T1 N2 → T2 T ∧ S → C ∧ S 1 0 1 1 || T2 ∧ S0 → C2 ∧ S1 C1 → N1 ∧ S0 C2 → N2 ∧ S0 Mutual Exclusion Example

N1N2S0

T1N2S0 N1T2S0