Design Verification Introduction Virendra Singh Associate Professor Computer Architecture and Dependable Systems Lab Department of Electrical Engineering Indian Institute of Technology Bombay http://www.ee.iitb.ac.in/~viren/ E-mail: viren@ee.iitb.ac.in Testing & Verification of VLSI Circuits Lecture 2 CADSL
Importance of Formal Verification Simulation Can be applied in any design level But quality of verification fully depends on Simulation Patterns Corner cases may be missed Random is just random and does not cover corner cases Emulation Implement on FPGA or other programmable device – need lot of preparation Still verification quality fully depends on Simulation Patterns – corner cases problem remains Famous bug: Pentium Floating point bug - $500 m CADSL 15 Jan 2013 EE-709@IITB 2
Design Verification Specification Formal Simulation with Automatic Specification Checkers/ drivers Implementation (Synthesis) Simulation Based Property checking Verification Equivalence Checking Formal Correct-by Verification Construction Implementation CADSL 15 Jan 2013 EE-709@IITB 3
Simulation-Based Verification Bug Bug Bug Bug Bug Bug Initial Bug State CADSL 15 Jan 2013 EE-709@IITB 4
Simulation Vs Formal Verification • Simulation/emulation • Formal Verification o Cannot cover all cases Equivalent to all case o Corner cases may be missed simulation o Essential method and good for No corner case w.r.t initially debugging given property CADSL 15 Jan 2013 EE-709@IITB 5
Simulation vs Formal Verification • Program testing can be used to show the presence of the bugs, but never to show the absence! (E.W. Dijkstra) CADSL 15 Jan 2013 EE-709@IITB 6
Simulation Vs Formal Verification Example: • Exclusive-OR circuit • z = (~x & y) + (x & ~y) CADSL 15 Jan 2013 EE-709@IITB 7
Simulation Vs Formal Verification • Transform the formulae for circuit to the one for specification by mathematical reasoning z = ~b + ~c b = ~x + ~a c = ~a + ~y a = ~x + ~y z = ~b + ~c = ~(~x + ~a) + ~(~x + ~y) = a & x + a & y = (~x + ~y) & x + (~x + ~y )& y = x & ~y + ~x & y • All transformation are based on axioms and theorems • Mathematical proof of correctness of design CADSL 15 Jan 2013 EE-709@IITB 8
Formal Verification Techniques Deductive Verification (Theorem proving) Uses axioms, rules to prove system correctness Difficult and time consuming Model Checking Automatic technique to prove correctness of concurrent systems Symbolic algorithms (using BDD) Equivalence Checking Check if two circuits are equivalent CADSL 15 Jan 2013 EE-709@IITB 9
SoC Verification • System-on-Chip (SOC) design • Increase of design complexity • Move to higher levels of abstraction Level Number of components 1E0 System level System level System level System level 1E1 Algorithm 1E2 Abstraction Accuracy 1E3 RTL 1E4 1E5 Gate 1E6 Transistor 1E7 CADSL 15 Jan 2013 EE-709@IITB 10
System-on-Chip (SoC) design • Specification to architecture and down to implementation • Behavior (functional) to structure – System level: system specification to system architecture – RT/IS level: component behavior to component micro- architecture µProcessor Control Pipeline IF FSM IP Netlist IP Memory RAM Comp. State PC Interface Interface IR Bus Control Datapath IF FSM Memory Interface Interface Mem RF State State Processors Registers IPs ALUs/FUs Memory Memories Memories ALU Busses Gates Custom HW Specification System architecture RTL/IS Implementation + constraints + estimates + results CADSL 15 Jan 2013 EE-709@IITB 11
Verification challenge Bottlenecks in Design Cycles: Survey of 545 engineers by EETIMES 2000 CADSL 15 Jan 2013 EE-709@IITB 12
System-level design & verification 3 minutes delay System-level 3 days RTL delay 3 weeks Transistor level delay Cost due to the delay/late time-to-market Bugs fix time revenue loss Remove as many bugs as possible in the earlier stages Do not introduce new design errors when refining designs ⇓ Formal verification in system-level designs: Property checking and equivalence checking CADSL 15 Jan 2013 EE-709@IITB 13
Formal verification • “ Prove ” the correctness of designs – Both design and spec must be represented with mathematical models Spec Design – Mathematical reasoning – Equivalent to “ all cases ” simulations • Possible mathematical models Front-end tool – Boolean function (Propositional logic) • How to represent and manipulate on computers – First-order logic • Need to represent “ high level ” designs Mathematical models – Higher-order logic • Theorem proving = Interactive method • Front-end is also very important Verification – Often, it determines the total performance of the engines tools CADSL 15 Jan 2013 EE-709@IITB 14
Backgrounds Technology in Formal Verification • Methods for reasoning about mathematical models Spec Design – Boolean function (Propositional logic) • SAT (Satisfiability checker) Front-end • BDD (Binary Decision Diagrams) tool – First-order logic • Logic of uninterpreted functions Mathematical with equality models – Higher-order logic • Theorem proving = Interactive Verification method engines CADSL 15 Jan 2013 EE-709@IITB 15
Formal Equivalence Checking CADSL 15 Jan 2013 EE-709@IITB 16
Formal Equivalence Checking CADSL 15 Jan 2013 EE-709@IITB 17
Formal Equivalence Checking • Equivalence checking can be applied at or across various levels CADSL 15 Jan 2013 EE-709@IITB 18
CEC in Practice Key observation: The circuit being verified usually have a number of internal equivalent functions CADSL 15 Jan 2013 EE-709@IITB 19
Formal Equivalence Checking Canonical Forms a f = ab + c b a b c f c 0 0 0 1 0 0 1 0 0 1 0 1 a 0 1 1 0 F’ = (a+ c)(b+c) 1 0 0 1 1 0 1 1 b 1 1 0 1 c 1 1 1 1 CADSL 15 Jan 2013 EE-709@IITB 20
Formal Equivalence Checking Complexity Efficiency of the conversion to canonical form Memory requirement Efficiency of the comparison of two representation of the canonical form Efficiency to generate the counter example in case of a miscompare CADSL 15 Jan 2013 EE-709@IITB 21
Recommend
More recommend
