1 / 47

Teaching Functional Formal Verification

DAC 2002. Teaching Functional Formal Verification. Dr. Yaron Wolfsthal Manager, Formal Methods IBM Haifa Research Laboratories. Functional Formal Verification - Motivation and Taxonomy Property Verification Model Checking The RuleBase tool, the Sugar language The pragmatic view

edgarhill
Download Presentation

Teaching Functional Formal Verification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. 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 • It's the power of mechanized calculations (eg. fluid dynamics, finite-element analysis) that makes the construction of complex physical systems possible • Formal Methods apply these ideas to the complex logical design of computer systems • Build a formal mathematical model of some aspect of the system • Calculate whether or not it has some desired property

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

  6. Exhaustively simulating all input combinations... Req0 256 bits ID Req1 Req255 Example: A 256-Entry Arbiter ... will require ~10^60 years on a simulator executing 1012 c/s.

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

  8. 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) Covering the Design Space - with Formal Verification (2)

  9. The Property Verification Paradigm a.k.a. ABV, Assertion-Based Verification Conceptually, consists of two major elements • Property Specification: • Using a language for formally specify functional requirements and behaviors of a chip • interface protocols • performance constraints • Analysis: • Using a procedure for establishing that the requirements (properties) hold • 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"

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

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

  12. L H Key Formal Verification Method: "Model Checking" • A method formathematically 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 • Improved verification quality, reduced cost • less tapeouts • less bugs in the field • ideally, investment in sim+FV should remain flat

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

  14. Collection of powerful verification algorithms (BDD-based, SAT) under same front-end • 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 RuleBase: The IBM Model Checker

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

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

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

  18. Automated Reductions/abstractions • 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 RuleBase - Under the Hood

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

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

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

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

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

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

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

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

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

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

  29. 2.0 Property-Based Verification of the Buffer: Sugar Formulation of the Overflow/Underflow Properties 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) ) } }

  30. Property-Based Verification of the Buffer: Handshaking Properties • The protocol sequence must always be honored • Focus on Request signals first • 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

  31. 2.0 Property-Based Verification of the Buffer Sugar Formulation of the Handshaking Properties - LHS 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) } }

  32. 2.0 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) } } Property-Based Verification of the Buffer Sugar Formulation of the Handshaking properties - RHS

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

  34. 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(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)) ) } } Property-Based Verification of the Buffer: Data-Path Sugar Property

  35. 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: How do you remember what was sent? • Answer: You use an auxiliary state-machine for bookkeeping

  36. Declare it Initialize it Give it a behavior The Bookkeeping FSM ("Satellite"): Stores last input driven by sender 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;

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

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

  39. 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? F.A.Q.

  40. Sugar Tutorial • http://www.haifa.il.ibm.com/projects/verification/sugar/sugar_tutorial.pdf • Generalized Buffer • 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 Tutorials

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

  42. Partitioning for Model Checking (1)

  43. Partitioning for Model Checking (2)

  44. Unit Unit (1000s) B B (10s) B B B B B B RTL Capacity (in terms of State Variables) • 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

  45. Falsification, Bug Hunting: A Pragmatic Approach • Cannot provide absolute guarantee of success • 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

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

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

More Related