1 / 12

ACL2 Panel: What is the Future of Theorem Proving? Arvind

ACL2 Panel: What is the Future of Theorem Proving? Arvind Computer Science & Artificial Intelligence Laboratory Massachusetts Institute of Technology Eighth International Workshop On The ACL2 Theorem Prover and Its Applications, Boston, MA, USA May 11-12, 2009.

henninge
Download Presentation

ACL2 Panel: What is the Future of Theorem Proving? Arvind

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. ACL2 Panel: What is the Future of Theorem Proving? Arvind Computer Science & Artificial Intelligence Laboratory Massachusetts Institute of Technology Eighth International Workshop On The ACL2 Theorem Prover and Its Applications, Boston, MA, USA May 11-12, 2009

  2. What is the Future of Theorem Proving? • ATP will continue to exist • Has already proved its utility • ATP in its present form is unlikely to be used widely • Very few systems requires the level of correctness guaranteed by ATP • ATP is currently unsuitable for evolving designs (all useful designs) http://csg.csail.mit.edu/arvind

  3. Widespread Use of ATP Technology • Integrate it into design flow (not post-facto) • ATP as debugging aid • Use in the development of rock-solid components which can be used without concern for correctness • reduces space of possible design bugs • Use ATP with synthesis methodologies • correct by construction • High-Level Synthesis http://csg.csail.mit.edu/arvind

  4. Cost Matters • The goal is to design systems that meet cost, performance, power, correctness, compatibility, robustness, etc. • Design time  $$$ • Designers will use any technique that increases their confidence in the system provided it: • gives useful feedback quickly • is better than manual debugging • doesn’t require learning a “foreign language” • is not elitist (No PhD requirement) http://csg.csail.mit.edu/arvind

  5. Some “Do”s and “Don’t”s • Most successful formal techniques (e.g. types) help the designer, not just the verifier • Separation of design and verification languages is a non-starter • what are you verifying? • manual abstraction, changing specs, … • Writing specs is a good idea, but it rarely happens • error prone • time consuming • incomplete • incomprehensible • changing requirements http://csg.csail.mit.edu/arvind

  6. What is needed • High-level notation • with precise semantics • capable of expressing nondeterminism and parallelism • amenable to synthesis of actual implementation • Powerful tools for proving properties of such designs Automatic extraction of abstract models from designs expressed in Verilog or C or SystemC is a lost cause Thanks! http://csg.csail.mit.edu/arvind

  7. http://csg.csail.mit.edu/arvind

  8. A personal anecdote • My student Xiaowei Shen designed an adaptive protocol called Caché • Very difficult for me to understand and be sure of its correctness • We used TRS to give a precise definition and TLAs to prove its correctness This was not enough … http://csg.csail.mit.edu/arvind

  9. Realization • The proof was so long that we could have made a mistake easily • Nobody else was going to read the proof – “it is not interesting” Even though the protocol correctness is of extreme importance the burden of its correctness is solely on its designers. Different from a math theorem Mechanical theorem proving http://csg.csail.mit.edu/arvind

  10. It took Joe Stoy more than 6 months to learn PVS and show that some of the proofs in Xiaowei Shen’s thesis were correct This technology is not ready for design engineers http://csg.csail.mit.edu/arvind

  11. Model Checking • CC is one of the most popular applications of model checking • The abstract protocol needs to be abstracted more to avoid state explosion • For example, only 3 CPUs, 2 addresses • There is a separate burden of proof why the abstraction is correct • Nevertheless model checking is a very useful debugging aid for the verification of abstract CC protocols http://csg.csail.mit.edu/arvind

  12. Implementation • Design is expressed in some notation which is NOT used directly to generate an implementation • The problem of verification of the actual protocol remains formidable • Testing cannot uncover all bugs because of the huge non-deterministic space Proving the correctness of cache coherence protocol implementations remains a challenging problem http://csg.csail.mit.edu/arvind

More Related