1 / 63

The Reveal Turn-Key Formal Verification System

The Reveal Turn-Key Formal Verification System. Zaher Andraus, Karem Sakallah University of Michigan, Ann Arbor Dagstuhl Seminar 09461 Algorithms and Applications for Next Generation SAT Solvers Nov. 8-13, 2009. Motivation. Core Duo. Requirements :

osanna
Download Presentation

The Reveal Turn-Key Formal Verification System

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. The Reveal Turn-KeyFormal Verification System Zaher Andraus, Karem Sakallah University of Michigan, Ann Arbor Dagstuhl Seminar 09461Algorithms and Applications for Next Generation SAT SolversNov. 8-13, 2009

  2. Motivation Core Duo Requirements: Power, Performance, Reliability, Features, … 8086 80286 80486 Pentium 80386 High-Level Control Optimizations: Pipelining, Caching, Multi-Core, Power Management, .. Design Control Logic: Complex, Error-Prone, Non-reusable, .. Control Logic Complexity Lack of Automation Limits Scalability Gap Verification Capability We Demonstrate a Fully Automatic Approach to Formal Verification of Control Logic Time

  3. Turn-Key Formal Verification of Control Logic in Digital Systems Automatic Abstraction Automatic Scalability Refinement Automatic Formal Efficient Reasoning

  4. Instruction memory DMEM Register File Pipelining Control Logic: Instruction Decode PC ALU

  5. Instruction memory DMEM Register File Pipelining Control Logic: Instruction Decode PC ALU

  6. Instruction memory DMEM Register File Control Logic: Decoding, Bypassing/Forwarding, Stalling PC ALU

  7. Instruction memory Instruction memory DMEM DMEM Register File Register File SPEC Control Logic IMPL Control Logic PC PC ALU Equivalence ALU

  8. Outline • Verification Framework • Datapath Abstraction and Basic Refinement • Advanced Refinement • The Reveal System • Results • Conclusions

  9. Verification Framework Golden Model (Spec) Implementation Equivalence ISA (document) Non-pipelined Verilog Transaction C/C++ Module Register Transfer Level Verilog

  10. Unfolding Combinational Logic Combinational Logic Combinational Logic Combinational Logic FF p property = Combinational Logic Combinational Logic Combinational Logic Combinational Logic Combinational Logic FF FF

  11. Unfolding Combinational Logic Combinational Logic Combinational Logic Combinational Logic FF p property Combinational Logic Combinational Logic Combinational Logic Combinational Logic Combinational Logic FF FF

  12. 0 0 a 1 1 2 2 3 3 1 1 0 0 = = = = 1 0 0 1 0 >>1 h 0 b {.,.} g >>2 Does the property hold? Is p=1 for all assignments to circuit inputs?

  13. 0 0 a 1 1 2 2 3 3 1 1 0 0 = = = = 1 0 1 0 0 >>1 h 0 b {.,.} g >>2 Is p=1 for all assignments to circuit inputs? Is Ep=1 for all variable assignments?

  14. Impl p in Spec SAT-based Verification Formula Generation YES Bug Witness State Explosion NO Design is Correct

  15. Approximation • Replace exact behavior of the design with a less precise behavior to speed up verification • Compromise Accuracy for Speed • Sound Approximation [Approximation Correct  Design Correct] • Complete Approximation [Approximation Buggy  Design Buggy]

  16. Outline • Verification Framework • Datapath Abstraction and Basic Refinement • Advanced Refinement • The Reveal System • Results • Conclusions

  17. Datapath Abstraction 32 x x ADD x+y ADD(x,y) y y Functional Consistency: x1=y1 & x2=y2 ADD(x1,y1)=ADD(x2,y2) Adder Un-interpreted Function PC 32 PC ADD ADD(PC,four) four 4 succ4 succ4(PC) PC Counting Aritmetic: pred(succ(PC))=PC Memory Consistency: Dout presents the last Din written to same address Mem 32 Mem Din Din Dout Dout Ain Ain

  18. 0 0 a 1 1 2 2 3 3 1 1 0 0 = = = = 0 1 1 0 0 >>1 h 0 b {.,.} g >>2 Is Ep=1 for all variable assignments?

  19. 0 0 1 1 = = = = 1 1 0 0 EX2 EX1 SR CT EX3 SR Is Ep=1 for all variable assignments? Is Ap=1 for all variable assignments?

  20. Impl p p in in Spec Abstraction-based Verification Abstraction Formula Generation Abstraction is Sound YES ? X* NO Design is Correct

  21. 0 1 0 1 = = = = 1 1 0 0 1 EX2 EX1 1 1 0 0 SR 5 4 3 3 CT EX3 15 0 0 0 2 5 SR 2 Property is violated on the abstract design Is property violated on the concrete design? Is ?

  22. 0 0 a 1 1 2 2 3 3 0 1 0 1 = = = = 0 0 1 1 0 1 0 0 0 0 1 0000 >>1 0 0 1 0 0011 h 0101 0 b 1111 {.,.} 0011 0 0 0 0101 0010 0100 g >>2 0010 Violation is inconsistent with concrete design

  23. Impl p p in in Spec Counterexample Guided Abstraction Refinement Abstraction Refine by Refuting the Counterexample Formula Generation Running example: 14148 iterations Check Feasibility No YES X* Yes NO Bug Witness Design is Correct

  24. Outline • Verification Framework • Datapath Abstraction and Basic Refinement • Advanced Refinement • The Reveal System • Results • Conclusions

  25. 0 0 1 1 = = = = 1 1 0 0 EX2 EX1 0 0 SR 5 3 4 3 CT EX3 15 0 0 0 5 2 SR 2

  26. Impl p in Spec Counterexample Guided Abstraction Refinement Abstraction & Formula Generation Refute a Family of Counterexamples Similarity to Learning in SMT Running example: 444 iterations Generalization YES X* NO viol Design is Correct No Yes Bug Witness

  27. Generalization • Pros • Resolves the issue of out-of-bound constants • Captures and refines a family of counterexamples • Cons • Expensive feasibility check on the circuit itself • Many refinement iterations due to unnecessary (dis-) equalities • Only cone-of-influence (w.r.t. counterexample) is relevant in each refinement iteration • Only a subset of the (dis-)equalities is needed in each iteration • A one-time only lemma  cannot be reused

  28. 0 1 1 0 = = = = 0 0 1 1 1 EX2 EX1 SR 0 CT EX3 0 0 SR

  29. 0 1 1 0 = = = = 0 0 1 1 EX2 EX1 SR 3 CT EX3 0 l=1 2 SR

  30. 0 1 0 1 = = = = 1 1 0 0 EX2 EX1 SR 3 3 CT EX3 0 2 SR 2

  31. 0 1 1 0 = = = = 0 1 1 0 EX2 EX1 SR CT EX3 SR

  32. Feasibility/Refinement based on Explaining the Abstract Counterexample • Distill a simplified expression • Include only equalities/dis-equalities • Exclude logic that is not in the cone-of-influence • Exclude numeric values • Exclude Control Logic • Based on Primary Inputs  allow independent feasibility checking

  33. Improved Feasibility/Refinement (2) UNSAT

  34. Improved Feasibility/Refinement (3) • Lemma: A high-level universal truth • Refutes a family of spurious counterexamples • Can be reused whenever relevant • Across refinement iterations • Across various invocations of the verification on modifications of the design/property

  35. Impl p in Spec Refinement based on Lemmas Abstraction & Formula Generation Lemma Database Running example: 3 iterations Generalization & Explanation YES X* NO viol Design is Correct No Yes Bug Witness

  36. Minimization An All-MUS algorithm can generate lemmas • As many as possible • As compact as possible (UNSAT) (UNSAT) (Lemma) (Lemma)

  37. Impl p in Spec Refinement based on Lemmas User Input Running example: 2 iterations In general: crucial for convergence Abstraction & Formula Generation Lemma Database Generalization & Explanation Explain Infeasibility YES X* NO viol Design is Correct No Yes Bug Witness

  38. Trade-Offs • Efficiency in each Step • Validity Check • Feasibility Check • Refinement • Preciseness of Initial abstraction • Precise (detailed) versus Impresice (coarse) • Refinement Convergence  Overall Performance

  39. Outline • Verification Framework • Datapath Abstraction and Basic Refinement • Advanced Refinement • The Reveal System • Results • Conclusions

  40. RTL Verilog User Input Impl Abstraction & Formula Generation p in Spec Lemma Database Generalization & Explanation Explain Infeasibility YES X* YICES SMT Solver NO viol CAMUS: Extraction of MUSES based on SMT Solving Design is Correct No YICES using the BV Theory Yes Bug Witness The Reveal System C++ Implementation

  41. Outline • Verification Framework • Datapath Abstraction and Basic Refinement • Advanced Refinement • The Reveal System • Results • Conclusions

  42. Test Cases and Setup Setup: 2.2 GHz AMD Opteron Processor, 8GB RAM, Linux

  43. 1 0 1 0 Test Case1: Sorter Sort2 d1>d2 d1 res1 res1 d1 d2 d1>d2 res2 d2 d2 res2 d1

  44. s21 s11 Sub Sub d1 ires1 s22 s12 d2 Sub ires2 ires3 Sub Sub d3 s23 s13 ires4 d4 s24 s14 Sorter: Implementation Registers Registers Registers

  45. C O N T R O L s1 Sub d1 sres1 s2 d2 sres2 s3 Sub sres3 d3 s4 d4 sres4 Registers Sorter: Specification

  46. Sorter Equivalence Implementation d1 d2 Equivalent? d3 d4 Specification

  47. Test Case 1: Sorter • A Sort Algorithm for 4 W-bits vectors • Equivalence between 2 Implementations

  48. Test Case2: RISC16F84 • A Microcontroller from OpenCores.org • 213x14-bit I-Mem, 29x8-bit D-Mem • 34 Op-codes • 4-stage pipeline • Property: Equivalence to a 1-stage Spec starting from an arbitrary state:

  49. Test Case3: DLX • DLX is a 32-bit RISC microprocessor* • 32-bit address space, I-memory, D-memory • 32-word register file, 2 read ports, 1 write port • 38 op-codes • 5-stage Pipeline • Property: Pipeline to Non-pipeline Equivalence Starting from Reset:

  50. Test Case4: X86* * http://vlsi.cs.iitm.ernet.in/x86_proj/x86HomePage.html

More Related