DAC 2002 Teaching Functional Formal Verification Dr Yaron

DAC 2002 Teaching Functional Formal Verification Dr. Yaron Wolfsthal Manager, Formal Methods IBM Haifa Research Laboratories

Overview n Functional Formal Verification - Motivation and Taxonomy n Property Verification – – – n Experience using Rule. Base – – n n Model Checking The Rule. Base tool, the Sugar language The pragmatic view IBM Server Group IBM's industrial partners Example: The Buffer Summary, final remarks, and answers to some questions which students often ask

Taxonomy of Verification "concept" n what you specified is what you envisioned – n functional verification - specification level what you designed (RTL) is what you specified – specification functional verification - implementation level VHDL n what you taped-out is what you designed in RTL – n equivalence checking what was manufactured is what you taped-out – transistors production testing silicon

Motivation for Functional Formal Verification Philosophy Behind Formal Methods Engineers build mathematical models of systems so they can predict their properties through the power of calculation n It's the power of mechanized calculations (eg. fluid dynamics, finite-element analysis) that makes the construction of complex physical systems possible n Formal Methods apply these ideas to the complex logical design of computer systems n Build a formal mathematical model of some aspect of the system n Calculate whether or not it has some desired property n

Motivation for Functional Formal Verification Historical Perspective of Verification Solutions n In the beginning there was Simulation – – – n event-based cycle-based clever test generation Simulasaurus But. . . simulation alone has inherent limitations

Example: A 256 -Entry Arbiter n Exhaustively simulating all input combinations. . . Req 0 Req 1 Req 255 256 bits ID . . . will require ~10^60 years on a simulator executing 1012 c/s.

Motivation for Functional Formal Verification Need for Methodology Shift Observed in Industry COMPLEXITY H/W CRISIS CHANGE Enter Formal Methods: Methodology for Managing Complexity FORMAL METHODS

Motivation for Functional Formal Verification vs. Simulation (Unit View) Covering the Design Space with Simulation Covering the Design Space with Formal Verification (1) Covering the Design Space with Formal Verification (2)

The Property Verification Paradigm a. k. a. ABV, Assertion-Based Verification Conceptually, consists of two major elements l. Property Specification: – Using a language formally specify functional requirements and behaviors of a chip è interface protocols è performance constraints l Analysis: – Using a procedure for establishing that the requirements (properties) hold n Note: – Property Verification in general is not limited to Formal Verification! è In the context of this talk, however, we focus on FV, and in particular on an FV technique called "Model Checking"

Model Checking - Formal Property Verification Doing it the Automatic Way n n Represent design as a finite state machine Automatically calculate truth or falsity of specification by traversing the stat space "if a request is received, it will be processed within 3 clocks" process 1 0 2 6 request 5 Type text request 4 Type text 3

Sample Properties n Temporal relationships between signal values n External and internal protocols n Cache coherency/consistency policies n Mutual exclusion, absence of contentions n Correctness of arithmetic computations

Key Formal Verification Method: "Model Checking" n n A method for mathematically proving functional properties ('"specifications") on the design. No tests required Proving a property is showing that it holds for all possible input combinations, across all execution paths L n Improved verification quality, reduced cost – – – less tapeouts less bugs in the field ideally, investment in sim+FV should remain flat H

Model Checking Flow n n Answer questions like – does my design satisfy these rules. . . e. g. è Request will be always Processed within 3 cycles Inputs: – The design – The environment Type text Request will be always processed within 3 cycles Type text Design (VHDL) Environment (EDL) Model Checker (Rule. Base) (irritator for its inputs) – Rules (Sugar) The rules (specification or properties to verify) n Output: – A documented pass/fail answer (with error trace) Pass/Fail frame irdy trdy hold data Wrt Rd Retry Wrt

Rule. Base: The IBM Model Checker n Collection of powerful verification algorithms (BDD-based, SAT) under same front-end 3 3 n n Will verify a design, typically control logic, against a set of properties, producing documented fail/pass answer Deals with industrial-size designs (a real issue) GA July 1996 Version 1. 4 released June 2002 Used throughout IBM, by external licensees, and in academia Friendly University Program

User Experience: Model Checking the IBM e. Server p 690 "We applied FFV to some extent on approximately 40 design components throughout the processor and found more than 200 design flaws at various stages and of varying complexity. At least one bug was found by almost every application of FFV. In most cases, FFV began significantly later than verification. It is estimated that 15% of these bugs were of extreme complexity and would have been difficult for traditional verification. In some cases, a late bug found in verification or in the laboratory was recreated and its correction verified efficiently with FFV. "

Formal Verification in Practice Type text n Tool Perspective (capacity) – n Type text deal with state-space explosion Type text User Perspective – how to define "functional properties" specification) – (the how to define "assumptions on input" Li Hi – usability Li+1 Hi+1 pi+1

Formal Verification in Practice n Tool Perspective (capacity) – deal with state-space explosion Type text Type text n User Perspective – how to define "functional properties” (the specification) – how to define "assumptions on input" – usability

Rule. Base - Under the Hood n Automated Reductions/abstractions – – n cone-of-influence flip-flop equivalence Advanced Model-Checking Algorithms – – classic CMU algorithm on-the-fly checking of safety formulas bounded model checking guided search

Formal Verification Challenges - Putting it to Work The Specification Perspective n Tool Perspective (capacity) – n deal with state-space explosion User Perspective – how to define "functional properties" (the specification) – how to define "assumptions on input" – usability

Sugar Goes Public n April 22, 2002 – Sugar selected by Accellera as basis for IEEE standard specification language Sugar-based tools already announced by: Cadence, Verplex, Trans. EDA, IBM l frame irdy trdy hold data Wrt Rd Expressions Temporals Env. Modeling Verification Directives Retry Wrt

Specifying Properties - the Sugar 2. 0 Language n Natural, concise way formulating properties n English: n n Whenever we see an assertion of signal req, followed by an assertion of signal ack, which is not followed by an assertion of signal cancel, we should see - starting at the next cycle - an assertion of signal start_trans, followed by between 1 and 8, not necessarily consecutive assertions of signal data_valid, followed by an assertion of signal write_end Sugar: n always { req; ack; !cancel } |=> { start_trans; data_valid [=1. . 8]; write_end }

Formal Verification Challenges - Putting it to Work The "Environment Assumptions" Perspective n Tool Perspective (capacity) – n deal with state-space explosion User Perspective – how to define "functional properties" (the specification) – how to define "assumptions on input" Li Li+1 Hi Hi+1 pi+1 – usability

Why "Environmental Assumptions" n Avoiding "False Fails" ("False Negatives") – – n Only consider legal inputs to the system under test Under illegal inputs, artificial, nonrealistic failures can be reported Limiting search space n reduce set of applicable input behaviors = reduce state-space size env: read only Design env: write only Design

How to Write "Environmental Assumptions" n Same syntax as "properties" – n restrictions on input behavior State-Machine syntax (w/non-determinism) n n n Verilog VHDL EDL Universities: Your installation of Rule. Base currently supports only Sugar 1. 0, which has only EDL flavor

Example: The Buffer BUF is a design block that buffers a word of data (32 bits) sent by a sender to a receiver. It has two control inputs, two control outputs, and a data bus on each side: Sto. B_REQ Rto. B_ACK DI(0. . 31) Sender DO(0. . 31) BUF Bto. S_ACK Rcvr Bto. R_REQ

Example: The Buffer Rto. B_ACK Sto. B_REQ DI(0. . 31) Sender DO(0. . 31) BUF Bto. S_ACK Rcvr Bto. R_REQ Communications (on both sides) takes place by means of a 4 -phase handshaking as follows: When the sender has data to send to the receiver, it initiates a transfer by putting the data on the data bus and asserting Sto. B_REQ (Server to Buffer REQuest). If BUF is free, it reads the data and asserts Bto. S_ACK (Buffer to Server ACKnowledge). Otherwise the sender waits. After seeing Bto. S_ACK, the sender may release the data bus and deassert Sto. B_REQ. To conclude the transaction, BUF deasserts Bto. S_ACK. When BUF has data, it initiates a transfer to the receiver by putting the data on the data bus and asserting Bto. R_REQ (Buffer to Receiver REQuest). If the receiver is ready, it reads the data and asserts Rto. B_ACK (Receiver to Buffer ACKnowledge). Otherwise, BUF waits. After seeing Rto. B_ACK, BUF may release the data bus and deassert Bto. R_REQ. To conclude the transaction, the receiver deasserts Rto. B_ACK.

Property Specification Note: This is not About Sugar Syntax! Yet I will make an attempt to expose you to Sugar 2. 0 n n n Basic functional properties Protocol properties Data-path properties

Property-Based Verification of the Buffer: Basic Functional Properties n First Property: – n Overflow (two reads without a write in between) cannot occur! Second Property: – Underflow (two writes without a read in between) cannot occur!

Property-Based Verification of the Buffer: Sugar Formulation of the Overflow/Underflow Properties 2. 0 rule ack_interleaving { formula "No overflow: Rto. B_ACK is asserted between any two Bto. S_ACK assertions " { always { [*] ; !RST & rose(Bto. S_ACK) ; true }( rose(Rto. B_ACK) before rose(Bto. S_ACK) ) } formula "No underflow: Bto. S_ACK is asserted between any two Rto. B_ACK assertions" { always { [*] ; !RST & rose(Rto. B_ACK) ; true }( rose(Bto. S_ACK) before rose(Rto. B_ACK) ) } }

Property-Based Verification of the Buffer: Handshaking Properties n n The protocol sequence must always be honored Focus on Request signals first – – n Request signals will not be prematurely asserted Once asserted, Request signals will stay high until acknowledged Next, focus on Acknowledge signals – – Acknowledge signals cannot spontaneously be asserted Once asserted, an Acknowledge signal will stay high until the triggering Request signal is turned off

Property-Based Verification of the Buffer Sugar Formulation of the Handshaking Properties - LHS 2. 0 rule four_phase_handshake_left { formula "A request can not be raised when ack is high " { always { [*] ; !Sto. B_REQ & Bto. S_ACK ; Sto. B_REQ } (false) } formula "A request can not be lowered when ack is low" { always { [*] ; Sto. B_REQ & !Bto. S_ACK ; !Sto. B_REQ } (false) } formula "An acknowledge can not be raised when req is low" { always { [*] ; !Bto. S_ACK & !Sto. B_REQ ; Bto. S_ACK } (false) } formula "An acknowledge can not be lowered when req is high" { always { [*] ; Bto. S_ACK & Sto. B_REQ ; !Bto. S_ACK } (false) } }

Property-Based Verification of the Buffer Sugar Formulation of the Handshaking properties - RHS 2. 0 rule four_phase_handshake_right { formula "A request can not be raised when ack is high" { always { [*] ; !Bto. R_REQ & Rto. B_ACK ; Bto. R_REQ } (false) } formula "A request can not be lowered when ack is low" { always { [*] ; Bto. R_REQ & !Rto. B_ACK ; !Bto. R_REQ } (false) } formula "An acknowledge can not be raised when req is low" { always { [*] ; !Rto. B_ACK & !Bto. R_REQ ; Rto. B_ACK } (false) } formula "An acknowledge can not be lowered when req is high" { always { [*] ; Rto. B_ACK & Bto. R_REQ ; !Rto. B_ACK } (false) } }

Property-Based Verification of the Buffer: Data-Path Property n Basic transfer property n n Data sent to receiver (RHS) is the same as received from sender (LHS) To specify in Sugar, we can use next_event (b)(f) n n The next time that b holds, f must hold A conceptual extension of the next operator

Property-Based Verification of the Buffer: Data-Path Sugar Property 2. 0 rule checking_data{ "Data sent to receiver is the same data received from the sender in the last write" formula { always ((!RST & rose(Bto. S_ACK) & DI(0)) next_event(rose(Rto. B_ACK))( DO(0)) ) } d formula { always ((!RST & rose(Bto. S_ACK) & !DI(0)) next_event(rose(Rto. B_ACK))( !DO(0)) ) } } d

Property-Based Verification of the Buffer: Data-Path Property - Another Way Basic transfer property – Data sent to receiver (RHS) is the same as received from sender (LHS) – è è Question: Answer: How do you remember what was sent? You use an auxiliary state-machine for bookkeeping

The Bookkeeping FSM ("Satellite"): Stores last input driven by sender sticky_bit: if rises, it stays active forever. Declare it var tmp(0. . 31): Boolean; assign init(tmp(0. . 31)) : = {0}; assign next(tmp(0. . 31)) : = IF rose(BTOS_ACK) THEN DI(0. . 31) ELSE tmp(0. . 31) ENDIF; . Give it a behavior Initialize it

Property-Based Verification of the Buffer Sugar Formulation of the Data Transfer Property 2. 0 var tmp(0. . 31): boolean; assign init(tmp(0. . 31)) : = 0; assign next(tmp(0. . 31)) : = IF rose(BTOS_ACK) THEN DI(0. . 31) ELSE tmp(0. . 31) ENDIF; rule checking_data{ "Data sent to receiver is the same data received from the sender in the last write" formula { Always { [*] ; !RST & rose(RTOB_ACK) }( DO(0. . 31) = tmp(0. . 31) ) } }

This Syntax is Really the "Modeling Layer of Sugar" a. k. a. EDL - Environment Description Language sticky_bit: if rises, it stays active forever. Declare it //sticky_bit: //once asserted, stays active forever. var sticky_bit: Boolean; assign init(sticky_bit) : = {0, 1}; assign next(sticky_bit) : = case. Give it a behavior non-det. behavior until asserted sticky_bit : 1; else : {0, 1}; esac; Initialize it (non-det. behavior)

F. A. Q. n n What tutorials are available? What else can be done to address large state spaces? What is the typical size of design units that can be addressed? What kind of bugs are we after?

Tutorials n Sugar Tutorial – n Generalized Buffer – n http: //www. haifa. il. ibm. com/projects/verification/sugar_tutorial. pdf http: //www. haifa. il. ibm. com/projects/verification/RB_Homepage/tutorials. html New! Fresh Arbiter from the Server Group – contact Emmanuel Zarpas, zarpas@il. ibm. com

Design for Formal Verification: Proper Methodology is Useful for Overcoming Size Limitations n Verify control logic alone – n n leave datapath for simulation Abstract out internal parts Degenerate design parts by limiting environment behavior Partitioning Modes

Partitioning for Model Checking (1)

Partitioning for Model Checking (2)

Capacity (in terms of State Variables) n n Practical for block-level verification ("designer-level verification") Practical also - with proper training - for – – unit-level verification of complicated control logic (up to 1000's of FFs) system-level verification of abstract architectural models Unit (1000 s) B B B (10 s) B RTL B B

Falsification, Bug Hunting: A Pragmatic Approach n Cannot provide absolute guarantee of success – – n Done w. r. t. user-provided specification On abstract model which may not fully capture reality Focus on adding value to existing processes – – Finding bugs ASAP! Debugging, explore requirements

Sample Bug Found with Rule. Base The Rule: If Cmd is pending in the L 2 Queue, eventually it will be routed to the L 2 CPU Avail Cmd Prediction L 1 Cmd L 1/L 2 Control Avail Cmd L 2 Predict Bus Interface Power. PC Bus

Summary: Teaching (Functional (Formal Verification)) n Model Checking is accessible to engineering students – – n n Property Verification via model checking is a powerful tool Start from the beginning – – – n some will say: essential prerequisites: Digital Systems / Logic Design design formal verification pragmatically approach your verification problem thorough verification plan Friendly Rule. Base University Program!