630 likes | 733 Vues
Fully automatic approach to formal verification of control logic in digital systems, with scalability, refinement, and efficient reasoning. Demonstrates automatic abstraction and verification framework for efficient design control logic verification.
E N D
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
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
Turn-Key Formal Verification of Control Logic in Digital Systems Automatic Abstraction Automatic Scalability Refinement Automatic Formal Efficient Reasoning
Instruction memory DMEM Register File Pipelining Control Logic: Instruction Decode PC ALU
Instruction memory DMEM Register File Pipelining Control Logic: Instruction Decode PC ALU
Instruction memory DMEM Register File Control Logic: Decoding, Bypassing/Forwarding, Stalling PC ALU
Instruction memory Instruction memory DMEM DMEM Register File Register File SPEC Control Logic IMPL Control Logic PC PC ALU Equivalence ALU
Outline • Verification Framework • Datapath Abstraction and Basic Refinement • Advanced Refinement • The Reveal System • Results • Conclusions
Verification Framework Golden Model (Spec) Implementation Equivalence ISA (document) Non-pipelined Verilog Transaction C/C++ Module Register Transfer Level Verilog
Unfolding Combinational Logic Combinational Logic Combinational Logic Combinational Logic FF p property = Combinational Logic Combinational Logic Combinational Logic Combinational Logic Combinational Logic FF FF
Unfolding Combinational Logic Combinational Logic Combinational Logic Combinational Logic FF p property Combinational Logic Combinational Logic Combinational Logic Combinational Logic Combinational Logic FF FF
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?
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 Ep=1 for all variable assignments?
Impl p in Spec SAT-based Verification Formula Generation YES Bug Witness State Explosion NO Design is Correct
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]
Outline • Verification Framework • Datapath Abstraction and Basic Refinement • Advanced Refinement • The Reveal System • Results • Conclusions
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
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 Ep=1 for all variable assignments?
0 0 1 1 = = = = 1 1 0 0 EX2 EX1 SR CT EX3 SR Is Ep=1 for all variable assignments? Is Ap=1 for all variable assignments?
Impl p p in in Spec Abstraction-based Verification Abstraction Formula Generation Abstraction is Sound YES ? X* NO Design is Correct
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 ?
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
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
Outline • Verification Framework • Datapath Abstraction and Basic Refinement • Advanced Refinement • The Reveal System • Results • Conclusions
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
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
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
0 1 1 0 = = = = 0 0 1 1 1 EX2 EX1 SR 0 CT EX3 0 0 SR
0 1 1 0 = = = = 0 0 1 1 EX2 EX1 SR 3 CT EX3 0 l=1 2 SR
0 1 0 1 = = = = 1 1 0 0 EX2 EX1 SR 3 3 CT EX3 0 2 SR 2
0 1 1 0 = = = = 0 1 1 0 EX2 EX1 SR CT EX3 SR
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
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
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
Minimization An All-MUS algorithm can generate lemmas • As many as possible • As compact as possible (UNSAT) (UNSAT) (Lemma) (Lemma)
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
Trade-Offs • Efficiency in each Step • Validity Check • Feasibility Check • Refinement • Preciseness of Initial abstraction • Precise (detailed) versus Impresice (coarse) • Refinement Convergence Overall Performance
Outline • Verification Framework • Datapath Abstraction and Basic Refinement • Advanced Refinement • The Reveal System • Results • Conclusions
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
Outline • Verification Framework • Datapath Abstraction and Basic Refinement • Advanced Refinement • The Reveal System • Results • Conclusions
Test Cases and Setup Setup: 2.2 GHz AMD Opteron Processor, 8GB RAM, Linux
1 0 1 0 Test Case1: Sorter Sort2 d1>d2 d1 res1 res1 d1 d2 d1>d2 res2 d2 d2 res2 d1
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
C O N T R O L s1 Sub d1 sres1 s2 d2 sres2 s3 Sub sres3 d3 s4 d4 sres4 Registers Sorter: Specification
Sorter Equivalence Implementation d1 d2 Equivalent? d3 d4 Specification
Test Case 1: Sorter • A Sort Algorithm for 4 W-bits vectors • Equivalence between 2 Implementations
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:
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:
Test Case4: X86* * http://vlsi.cs.iitm.ernet.in/x86_proj/x86HomePage.html