Results 1  10
of
65
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
(Show Context)
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 50 (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 39 (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.
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 32 (11 self)
 Add to MetaCart
(Show Context)
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...
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
(Show Context)
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
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 implementation details. The natural specification of a processor is the instruction set architecture. The specification is defined as a set of abstract assertions defining the effect of each operation on the uservisible state. An implementation mapping is used to relate abstract states to detailed circuit states. The mapping captures the microarchitecture of an implementation of the processor. Symbolic Trajectory Evaluation is used to verify that the circuit fulfills each individual abstract assertion under the implementation mapping. Symbolic Trajectory Evaluation can be considered to be a hybrid approach based on symbolic simulation and model checking algorithms. The methodology has been applied to the fixed point unit of a superscalar processor that implements the PowerPC architecture. The processor represents a significant leap of complexity compared to previous attempts at formal verification of processors. Our approach seems to be the first one that can truly deal with the complexity of pipeline interlocks.
Automated Pipeline Design
 38TH DESIGN AUTOMATION CONFERENCE (DAC ’01), JUNE, LAS VEGAS
, 2001
"... The interlock and forwarding logic is considered the tricky part of a fullyfeatured pipelined microprocessor and especially debugging these parts delays the hardware design process considerably. It is therefore desirable to automate the design of both interlock and forwarding logic. The hardware de ..."
Abstract

Cited by 15 (2 self)
 Add to MetaCart
(Show Context)
The interlock and forwarding logic is considered the tricky part of a fullyfeatured pipelined microprocessor and especially debugging these parts delays the hardware design process considerably. It is therefore desirable to automate the design of both interlock and forwarding logic. The hardware design engineer begins with a sequential implementation without any interlock and forwarding logic. A tool then adds the forwarding and interlock logic required for pipelining. This paper describes the algorithm for such a tool and the correctness is formally verified. We use a standard DLX RISC processor as an example.
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 15 (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...