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

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

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

4. n Goal: eliminate H/W design defects before a product is shipped Specification Implementation = ~ ? The Functional Verification Problem Major Challenges: l Micro-architecture complexities grow l Market requirements get tougher l Silicon technologies improve Verification Exposure: Quality risks, soaring costs

5. n 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 Motivation for Functional Formal Verification Philosophy Behind Formal Methods

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

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

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

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

10. l Property Specification: – Using a language for formally specify functional requirements and behaviors of a chip è interface protocols è pe rformance 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" The Property Verification Paradigm a.k.a. ABV, Assertion-Based Verification Conceptually, consists of two major elements

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

12. 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 Sample Properties

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

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

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

16. "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. " User Experience: Model Checking the IBM eServer p690

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

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

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

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

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

22. n Natural, concise way for formulating properties n English: 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 n Sugar: n always { req; ack; !cancel } |=> { start_trans; data_valid [=1..8]; write_end } Specifying Properties - the Sugar 2.0 Language

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

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

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

26. 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: Sender Rcvr BUF StoB_REQ BtoR_REQ RtoB_ACK BtoS_ACK DI(0..31) DO(0..31)

27. Example: The Buffer Sender Rcvr BUF StoB_REQ BtoR_REQ RtoB_ACK BtoS_ACK DI(0..31) DO(0..31) 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 StoB_REQ (Server to Buffer REQuest). If BUF is free, it reads the data and asserts BtoS_ACK (Buffer to Server ACKnowledge). Otherwise the sender waits. After seeing BtoS_ACK, the sender may release the data bus and deassert StoB_REQ. To conclude the transaction, BUF deasserts BtoS_ACK. When BUF has data, it initiates a transfer to the receiver by putting the data on the data bus and asserting BtoR_REQ (Buffer to Receiver REQuest). If the receiver is ready, it reads the data and asserts RtoB_ACK (Receiver to Buffer ACKnowledge). Otherwise, BUF waits. After seeing RtoB_ACK, BUF may release the data bus and deassert BtoR_REQ. To conclude the transaction, the receiver deasserts RtoB_ACK.

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

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

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

31. n The protocol sequence must always be honored n Focus on Request signals first – Request signals will not be prematurely asserted – Once asserted, Request signals will stay high until acknowledged n 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: Handshaking Properties

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

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

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

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

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

37. . sticky_bit: if rises, it stays active forever. 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; Declare it Initialize it Give it a behavior The Bookkeeping FSM ("Satellite"): Stores last input driven by sender

38. 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) ) } Property-Based Verification of the Buffer Sugar Formulation of the Data Transfer Property 2.0

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

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

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

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

43. Partitioning for Model Checking (1)

44. Partitioning for Model Checking (2)

45. n Practical for block-level verification ("designer-level verification") n 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 Capacity (in terms of State Variables) Unit B B B B Unit (1000s) B (10s) B B B RTL

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

47. Avail Predict Sample Bug Found with RuleBase The Rule: If Cmd is pending in the L2 Queue, eventually it will be routed to the L2 Bus Interface L1L2 Cmd Prediction Cmd Avail PowerPC Bus L1/L2 Control CPU

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

49. Back-Up Foils

50. n User Survey, 2001 User Difficulties in Model Checking

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

52. n Counter-examples as waveforms/tests n Witness Production n Explanation of – counter-examples witnesses – vacuity (which precondition is always false) n Reduction analyzer Formal Verification Challenges - Putting it to Work The Usability Perspective EXPLANATION data hold trdy frame irdy WrtRdWrtRetry

53. n Searching for error states (e.g. where properties are violated) in expanding circles n The wisdom is in the search algorithm! S4S4 S0S0 S1S1 S2S2 Model Checking: Classic Algorithm