1 / 41

A Mathematical Approach to RTL Verification

A Mathematical Approach to RTL Verification. David M. Russinoff July 5, 2007. Outline. Relevance of software verification Relevance of traditional mathematics Future directions. Outline. Relevance of software verification Relevance of traditional mathematics Future directions.

quana
Download Presentation

A Mathematical Approach to RTL 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. A Mathematical Approach to RTL Verification David M. Russinoff July 5, 2007

  2. Outline • Relevance of software verification • Relevance of traditional mathematics • Future directions

  3. Outline • Relevance of software verification • Relevance of traditional mathematics • Future directions

  4. Background • John McCarthy (1961): LISP • Bob Boyer and J Moore (1971): NQTHM • J Moore and Matt Kaufmann (1989) : ACL2

  5. Requirements • A problem of limited size and complexity • A concise and unambiguous specification of correctness • Cooperative development of a program and its proof of correctness • A simple and elegant programming solution • A programming language with clear and simple semantics

  6. Requirements • A problem of limited size and complexityX • A concise and unambiguous specification of correctness • Cooperative development of a program and its proof of correctness • A simple and elegant programming solution • A programming language with clear and simple semantics

  7. Requirements • A problem of limited size and complexityX • A concise and unambiguous specification of correctness p • Cooperative development of a program and its proof of correctness • A simple and elegant programming solution • A programming language with clear and simple semantics

  8. Cooperative Development of Program and Proof "A program and its proof should be developed hand-in-hand, with the proof usually leading the way." -- Edsger Dijkstra

  9. Cooperative Development of Program and ProofX "A program and its proof should be developed hand-in-hand, with the proof usually leading the way." -- Edsger Dijkstra"Do you think that we need some academic to tell us how to design a multiplier?" -- Anonymous FP designer (1997)

  10. Simple and Elegant Solutions "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."-- Tony Hoare"Elegant algorithms are easy to program correctly, as well as being efficient." -- Robert Tarjan””A ditch dug in a straight line is both more appealing and more useful than one that zigzags at random ...." -- Daniel Kohansky, "The Philosophical Programmer"

  11. Simple and Elegant SolutionsX "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."-- Tony Hoare"Elegant algorithms are easy to program correctly, as well as being efficient." -- Robert Tarjan””A ditch dug in a straight line is both more appealing and more useful than one that zigzags at random ...." -- Daniel Kohansky, "The Philosophical Programmer"

  12. A Naïve Floating-Point Adder Compare Exponents Right Shift Add/Subtract Detect Cancellation Left Shift Assemble Result

  13. An Optimized Floating-Point Adder Predict Leading 1 Compare Exponents Left Shift Select Path Right Shift Add/Subtract Assemble Result

  14. Simple Program Semantics "Are you quite sure that all those bells and whistles, all those wonderful facilities of your so-called 'powerful' programming languages belong to the solution set rather than to the problem set?” --Dijkstra

  15. Simple Program Semanticsp "Are you quite sure that all those bells and whistles, all those wonderful facilities of your so-called 'powerful' programming languages belong to the solution set rather than to the problem set?” --Dijkstra Coding guidelines are effectively enforced to limit RTL design to a small and manageable subset of Verilog, thereby enabling formal analysis.

  16. Verilog-ACL2 Translation rc_co[70:0] = esub ? {1’b0, rc[70:1]} : {rc[69:0], rc[0]}; sum[70:0] <= rc[70:0] ^ a[70:0] ^ b[70:0]; (defun rc_co (n) (if (not (= (esub n) 0)) (bits (rc n) 70 1) (cat (bits (rc n) 69 0) (bitn (rc n) 0) 1))) (defun sum (n) (if (zp n) (reset ‘sum 71) (logxor (logxor (bits (rc (1- n)) 70 0) (bits (a (1- n)) 70 0)) (bits (b (1- n)) 70 0))))

  17. Outline • Relevance of software verification • Relevance of traditional mathematics • Future directions

  18. "TheMathematical Revolution" "In 1976, Appel and Haken announced that they had solved the Four Colour Problem by a computer examination of nearly two thousand cases. ... the procedure employed by the machine to analyze each case of necessity involved billions of logical inferences; ... there is not even a remote chance that, in an entire lifetime, a human could trace the program's run on even one case ...

  19. "TheMathematical Revolution" "... Convictions derived in this manner might be valid but they are not mathematics. Such a result is still unproven, and should be so considered. ... Admitting the shenanigans of Appel and Haken to the ranks of mathematics would only leave us intellectually unfulfilled.” -- Daniel Cohen, "The Superfluous Paradigm", 1991

  20. "Last Doubts Removed About the Proof of the Four Color Theorem" “What makes the new result particularly significant from a reliability point of view is that the proof assistant Gonthiers employed, called Coq, is a widely used general-purpose utility, which has been verified experimentally, unlike the special-purpose programs used in the earlier proofs of the four color theorem.” -- Keith Devlin, Mathematical Association of America Online, January 2005

  21. ACL2 • Intended primarily for computer system verification rather than mathematics • Efficient execution • High degree of automation • Weak logic

  22. Illustration: A Test for Primality (defun least-divisor (k n) (if (and (integerp n) (integerp k) (< 1 k) (<= k n)) (if (integerp (/ n k)) k (least-divisor (1+ k) n)) nil)) (defun primep (n) (and (integerp n) (= (least-divisor 2 n) n)))

  23. Identifying Mersenne Primes (2p1) (defthm mersenne-23 (not (primep (- (expt 2 23) 1))))[Time: .02 seconds] (defthm mersenne-31 (primep (- (expt 2 31) 1)))[Time: 65 minutes] (defthm mersenne-999671 (not (primep (- (expt 2 999671) 1))))[Time: 165 minutes] (defthm mersenne-19876271 (not (primep (- (expt 2 19876271) 1))))[Error: Integer too large to represent.]

  24. A Simple Optimization (defun least-divisor-fast (k n) (if (and (integerp n) (integerp k) (< 1 k) (<= k n)) (if (> (* k k) n)) n (if (integerp (/ n k)) k (least-divisor-fast (1+ k) n))) nil))(defthm least-divisor-rewrite (equal (least-divisor 2 n) (least-divisor-fast 2 n)))(defthm mersenne-31 (primep (- (expt 2 31) 1)))[Time: .05 seconds](defthm mersenne-61 (primep (- (expt 2 61) 1)))[Time: 54 minutes]

  25. A Little Number Theory If p is an odd prime, then a is a quadratic residue modulo p  x2a (mod p) for some x a(p-1)/2 1 (mod p). In particular, 2 is a quadratic residue modulo p p1 (mod 8). Theorem (Euler) If p = 4k+3 and q = 2p+1 are both prime, then q | 2p-1. Proof: Since q = 2(4k+3)+1 = 8k+7  -1 (mod 8), 2p = 2(q-1)/2 1 (mod q), i.e., q | 2p-1. ■

  26. Formalization of Euler's Theorem (defthm euler-corollary (implies (and (primep p) (= (mod p 4) 3) (> p 3) (primep (+ (* 2 p) 1))) (not (primep (- (expt 2 p) 1))))) (defthm mersenne-23-revisited (not (primep (- (expt 2 23) 1)))) [Time: .01 seconds] (defthm mersenne-999671-revisited (not (primep (- (expt 2 999671) 1))))[Time: 1 second](defthm mersenne-19876271 (not (primep (- (expt 2 19876271) 1)))[Time: 47 seconds]

  27. The Value of Mathematical Proof • Confidence in correctness of a result • Explication of underlying principles • Refinement of hypotheses

  28. The Value of Mathematical Proof • Confidence in correctness of a result p • Explication of underlying principles p • Refinement of hypotheses p All of these observations are as valid in the context of industrial hardware verification as they are in pure mathematics.

  29. Case Study: AMD Athlon Processor Adder • Detailed hand-written (informal) proof • 33 page paper • 4 week effort • RTL model mechanically translated to ACL2 logic • 86 KB of RTL • 219 KB of ACL2 • Formal proof mechanically checked by ACL2 • 2200 lemmas • 8 week effort • 1 bug exposed and corrected • Proof published (18 months later)

  30. A Bug in a Square Root Algorithm? • q is a 64-bit underestimate of x, accurate to 38 bits. • c is a 64-bit correction term: q+c is an underestimate, accurate to 74 bits, and 0 < c < 2-38q. • q+c is rounded to 64 bits in both directions to produce r1 and r2 . • In the case of rounding toward +, if (q+c) – r1 is not too big, then r2 is returned. r1 q+cr2

  31. A Bug in a Square Root Algorithm? • q is a 64-bit underestimate of x, accurate to 38 bits. • c is a 64-bit correction term: q+c is an underestimate, accurate to 74 bits, and 0 < c < 2-38q. • q+c is rounded to 64 bits in both directions to produce r1 and r2 . • In the case of rounding toward +, if (q+c) – r1 is not too big, then r2 is returned. r1 q+cr2 But what if r1 = r2?

  32. Mathematical Chaos ”It lacks so completely all plan and system that it is peculiar that so many men could have studied it. The worst of it is, it has never been treated stringently. There are very few theorems … which have been demonstrated in a logically tenable manner. Everywhere one finds this miserable way of concluding from the special to the general ….”

  33. Mathematical Chaos ”It lacks so completely all plan and system that it is peculiar that so many men could have studied it. The worst of it is, it has never been treated stringently. There are very few theorems … which have been demonstrated in a logically tenable manner. Everywhere one finds this miserable way of concluding from the special to the general ….” -- Niels Abel on the state of the calculus in 1826

  34. An ACL2 Library of RTL and FP Arithmetic Some 600 lemmas pertaining to • Bit vectors and logical operations • Floating-point formats and rounding • Special-purpose techniques for efficient implementation of elementary operations (see www.russinoff.com/papers/ )

  35. Interface Specifications in Verilog Required Verilog extensions: • Rational data type • Assertions representing safety and liveness constraints on inputs and outputs Motivation: • Accessibility to design engineers • Executability for the purpose of testing

  36. Outline • Relevance of software verification • Relevance of traditional mathematics • Future directions

  37. Formal Methods at AMD Today • New FP Designs routinely verified with ACL2 • Investigation of model-checking tools, etc. • Increased staffing • Expansion into other areas of functionality

  38. Specification of Control Logic Case study: a bus unit and L2 controller • Interface with dcache, icache, and external memory • Specification requires abstract model of internal state • Bugs exposed in simulation with RTL • Cooperation between specification and design is essential

  39. A Formal Model of X86 ISA • XFL: a simple formal language with C syntax, embedded in C++ • XFL encoding of instruction set forms the core of our simulation environment • Same model is the foundation of a formally based APM • Reliability is ensured by reciprocal validation

  40. Future Directions Formal ISA Model Block Specification Micro-architectural Verification Block Verification OS Verification Fully Verified Processor

  41. AMD, the AMD arrow logo, AMD Athlon, and combinations thereof are trademarks of Advanced Micro Devices, Inc. in the United States and/or other jurisdictions.

More Related