Results 1  10
of
45
ACL2 Theorems about Commercial Microprocessors
, 1996
"... ACL2 is a mechanized mathematical logic intended for use in specifying and proving properties of computing machines. In two independent projects, industrial engineers have collaborated with researchers at Computational Logic, Inc. (CLI), to use ACL2 to model and prove properties of stateoftheart ..."
Abstract

Cited by 68 (14 self)
 Add to MetaCart
ACL2 is a mechanized mathematical logic intended for use in specifying and proving properties of computing machines. In two independent projects, industrial engineers have collaborated with researchers at Computational Logic, Inc. (CLI), to use ACL2 to model and prove properties of stateoftheart commercial microprocessors prior to fabrication. In the first project, Motorola, Inc., and CLI collaborated to specify Motorola's complex arithmetic processor (CAP), a singlechip, digital signal processor (DSP) optimized for communications signal processing. Using the specification, we proved the correctness of several CAP microcode programs. The second industrial collaboration involving ACL2 was between Advanced Micro Devices, Inc. (AMD) and CLI. In this work we proved the correctness of the kernel of the floatingpoint division operation on AMD's first Pentiumclass microprocessor, the AMD5K 86. In this paper, we discuss ACL2 and these industrial applications, with particular attention ...
Processor Verification with Precise Exceptions and Speculative Execution
"... We describe a framework for verifying a pipelined microprocessor whose implementation contains precise exceptions, external interrupts, and speculative execution. We present our correctness criterion which compares the state transitions of pipelined and nonpipelined machines in presence of exte ..."
Abstract

Cited by 45 (4 self)
 Add to MetaCart
We describe a framework for verifying a pipelined microprocessor whose implementation contains precise exceptions, external interrupts, and speculative execution. We present our correctness criterion which compares the state transitions of pipelined and nonpipelined machines in presence of external interrupts. To perform the verification, we created a tablebased model of pipeline execution. This model records committed and inflight instructions as performed by the microarchitecture.
Trace Table Based Approach for Pipelined Microprocessor Verification
, 1997
"... This paper presents several techniques for formally verifying pipelined microprocessor implementations that contain outoforder execution and dynamic resolution of datadependent hazards. Our principal technique models the trace of executed instructions using a tablebased representation called ..."
Abstract

Cited by 36 (5 self)
 Add to MetaCart
This paper presents several techniques for formally verifying pipelined microprocessor implementations that contain outoforder execution and dynamic resolution of datadependent hazards. Our principal technique models the trace of executed instructions using a tablebased representation called a MAETT. We express invariant properties of pipelined implementations by specifying relations between elds in the MAETT. To show the viability of this technique, we have proved the correctness of a simple outoforder completion pipelined microprocessor design using the ACL2 theorem prover. This verication was performed incrementally by proving that the specied relations hold for all microarchitectural states reachable from a ushed implementation state, eventually permitting us to prove that the entire pipelined machine design implements its ISA specication.
Microarchitecture Verification by Compositional Model Checking
, 2001
"... Abstract. Compositional model checking is used to verify a processor microarchitecture containing most of the features of a modern microprocessor, including branch prediction, speculative execution, outoforder execution and a loadstore buffer supporting reordering and load forwarding. We observe ..."
Abstract

Cited by 31 (2 self)
 Add to MetaCart
Abstract. Compositional model checking is used to verify a processor microarchitecture containing most of the features of a modern microprocessor, including branch prediction, speculative execution, outoforder execution and a loadstore buffer supporting reordering and load forwarding. We observe that the proof methodology scales well, in that the incremental proof cost of each feature is low. The proof is also quite concise with respect to proofs of similar microarchitecture models using other methods. 1
A Mechanically Checked Proof of the Correctness of the Kernel of the AMD5K86 FloatingPoint Division Algorithm
 IEEE Transactions on Computers
, 1996
"... We describe a mechanically checked proof of the correctness of the kernel of the floating point division algorithm used on the AMD5K 86 microprocessor. The kernel is a nonrestoring division algorithm that computes the floating point quotient of two double extended precision floating point numbers, ..."
Abstract

Cited by 30 (11 self)
 Add to MetaCart
We describe a mechanically checked proof of the correctness of the kernel of the floating point division algorithm used on the AMD5K 86 microprocessor. The kernel is a nonrestoring division algorithm that computes the floating point quotient of two double extended precision floating point numbers, p and d (d 6= 0), with respect to a rounding mode, mode. The algorithm is defined in terms of floating point addition and multiplication. First, two NewtonRaphson iterations are used to compute a floating point approximation of the reciprocal of d. The result is used to compute four floating point quotient digits in the 24,,17 format (24 bits of precision and 17 bit exponents) which are then summed using appropriate rounding modes. We prove that if p and d are 64,,15 (possibly denormal) floating point numbers, d 6= 0 and mode specifies one of six rounding procedures and a desired precision 0 ! n 64, then the output of the algorithm is p=d rounded according to mode. We prove that every int...
Mechanized Formal Reasoning about Programs and Computing Machines
, 1996
"... ly every instruction will have an opcode and two arguments, a and b. (defun opcode (ins) (nth 0 ins)) (defun a (ins) (nth 1 ins)) (defun b (ins) (nth 2 ins)) Because nth, like put, extends its list argument with nils, we can write instructions in three formats: (op), (op a), and (op a b) and omitte ..."
Abstract

Cited by 28 (11 self)
 Add to MetaCart
ly every instruction will have an opcode and two arguments, a and b. (defun opcode (ins) (nth 0 ins)) (defun a (ins) (nth 1 ins)) (defun b (ins) (nth 2 ins)) Because nth, like put, extends its list argument with nils, we can write instructions in three formats: (op), (op a), and (op a b) and omitted arguments default to nil. For example, the constant (times (movi 2 0) ; 0 mem[2] / 0 (jumpz 0 5) ; 1 if mem[0]=0, go to 5 (add 2 1) ; 2 mem[2] / mem[1] + mem[2] (subi 0 1) ; 3 mem[0] / mem[0]  1 (jump 1) ; 4 go to 1 (ret))) ; 5 return to caller defines one program in our language. The constant is a list of seven elements. The first, times, is the name of the program and the other six elements are the 8 Chapter 4 instructions. For example, the first instruction is (movi 2 0), which has an opcode of movi, an a argument of 2 and a b argument of 0; the last instruction is (ret), which has an opcode of ret and a and b arguments of nil. A typical code memory will contain many such ...
Formal Hardware Verification By Symbolic Trajectory Evaluation
, 1997
"... Formal verification uses a set of languages, tools, and techniques to mathematically reason about the correctness of a hardware system. The form of mathematical reasoning is dependent upon the hardware system. This thesis concentrates on hardware systems that have a simple deterministic highlevel s ..."
Abstract

Cited by 19 (1 self)
 Add to MetaCart
Formal verification uses a set of languages, tools, and techniques to mathematically reason about the correctness of a hardware system. The form of mathematical reasoning is dependent upon the hardware system. This thesis concentrates on hardware systems that have a simple deterministic highlevel specification but have implementations that exhibit highly nondeterministic behaviors. A typical example of such hardware systems are processors. At the high level, the sequencing model inherent in processors is the sequential execution model. The underlying implementation, however, uses features such as nondeterministic interface protocols, instruction pipelines, and multiple instruction issue which leads to nondeterministic behaviors. The goal is to develop a methodology with which a designer can show that a circuit fulfills the abstract specification of the desired system behavior. The abstract specification describes the highlevel behavior of the system independent of any timing or implem...
Comparing Verification Systems: Interactive Consistency in ACL2
 PROCEEDINGS OF 11TH ANNUAL CONFERENCE ON COMPUTER ASSURANCE
, 1996
"... Achieving interactive consistency among processors in the presence of faults is an important problem in fault tolerant computing, first cleanly formulated by Lamport, Pease and Shostak and solved in selected cases with their Oral Messages (OM) Algorithm. Several machinesupported verifications of th ..."
Abstract

Cited by 13 (0 self)
 Add to MetaCart
Achieving interactive consistency among processors in the presence of faults is an important problem in fault tolerant computing, first cleanly formulated by Lamport, Pease and Shostak and solved in selected cases with their Oral Messages (OM) Algorithm. Several machinesupported verifications of this algorithm have been presented, including a particularly elegant formulation and proof by John Rushby using EHDM and PVS. Rushby proposes interactive consistency as a benchmark problem for specification and verification systems. We present a formalization of the OM algorithm in the ACL2 logic and compare our formalization and proof to his. We draw some conclusions concerning the range of desirable features for verification systems. In particular, while higherorder functions, strong typing, lambda abstraction and full quantification have some value they come with a cost; moreover, many uses of such feature can be easily translated into simpler logical constructs which facilitate more autom...
A Proof Planning Framework for Isabelle
, 2005
"... Proof planning is a paradigm for the automation of proof that focuses on encoding intelligence to guide the proof process. The idea is to capture common patterns of reasoning which can be used to derive abstract descriptions of proofs known as proof plans. These can then be executed to provide fully ..."
Abstract

Cited by 13 (9 self)
 Add to MetaCart
Proof planning is a paradigm for the automation of proof that focuses on encoding intelligence to guide the proof process. The idea is to capture common patterns of reasoning which can be used to derive abstract descriptions of proofs known as proof plans. These can then be executed to provide fully formal proofs. This thesis concerns the development and analysis of a novel approach to proof planning that focuses on an explicit representation of choices during search. We embody our approach as a proof planner for the generic proof assistant Isabelle and use the Isar language, which is humanreadable and machinecheckable, to represent proof plans. Within this framework we develop an inductive theorem prover as a case study of our approach to proof planning. Our prover uses the difference reduction heuristic known as rippling to automate the step cases of the inductive proofs. The development of a flexible approach to rippling that supports its various modifications and extensions is the second major focus of this thesis. Here, our inductive theorem prover provides a context in which to evaluate rippling experimentally. This work results in an efficient and powerful inductive theorem prover for Isabelle as well as proposals for further improving the efficiency of rippling. We also draw observations in order