We describe a method for rigorously specifying and verifying the control of pipelined microprocessors which can be used by the hardware designer for a precise documentation and justification of the correctness of his design techniques. We proceed by successively refining a one-instruction-at-a-time-view of a RISC processor to a description of its pipelined implementation; the structure of the refinement hierarchy is determined by standard instruction pipelining principles (grouped following the kind of conflict they are designed to avoid: structural hazards, data hazards and control hazards). We illustrate our approach through a formal specification with correctness proof of Hennessy and Patterson's RISC processor DLX but the method can be extended to complex commercial microprocessor design where traditional or purely automatic methods do not scale up. The specification method supports incremental design techniques; the modular proof method offers reusing proofs and supports the designer's intuitive reasoning.

. In this article we present a structured approach to formal hardware verification by modelling circuits at the register-transfer level using a restricted form of higher-order logic. This restricted form of higher-order logic is sufficient for obtaining succinct descriptions of hierarchically designed register-transfer circuits. By exploiting the structure of the underlying hardware proofs and limiting the form of descriptions used, we have attained nearly complete automation in proving the equivalences of the specifications and implementations. A hardware-specific tool called MEPHISTO converts the original goal into a set of simpler subgoals, which are then automatically solved by a general-purpose, first-order prover called FAUST. Furthermore, the complete verification framework is being integrated within a commercial VLSI CAD framework. Keywords: hardware verification, higher-order logic 1 Introduction The past decade has witnessed the spiralling of interest within the academic com...

What does it mean for an instruction pipeline to be correct? We recently completed the specification and verification of a pipelined microprocessor called Uinta. Our proof makes no simplifying assumptions about data and control hazards. This paper presents the specification, describes the verification, and discusses the effect of pipelining on the correctness model. 1 Introduction Much has been written over the years regarding the formal specification and verification of microprocessors. Most of these efforts have been directed at non--pipelined microprocessors [Gor83, Bow87, Hun87, CCLO88, Coh88, Joy88, Hun89, Win90, Her92, SWL93, Win94b]. The verification of pipelined microprocessors presents unique challenges. The correctness model is somewhat different than the standard correctness models used previously (see Section 7.1). Besides the correctness model, the concurrent operations inherent in a pipeline lead to hazards which must be considered in the proof. There are three typ...

An in-depth analysis of the 30x36 processor families identifies architectural properties that may have unexpected, and undesirable, results in secure computer systems. In addition, reported implementation errors in some processor versions render them undesirable for secure systems because of potential security and reliability problems. In this paper, we discuss the imbalance in scrutiny for hardware protection mechanisms relative to software, and why this imbalance is increasingly difficult to justiXy as hardware complexity increases. We illustrate this difficulty with examples of architectural subtleties and reported implementation errors.

We describe a technique for specifying and verifying the control of pipelined microprocessors which can be used where traditional or purely automatic methods do not scale up to complex commercial microprocessor design. We illustrate our approach through a formal specification of Hennessy's and Patterson's RISC processor DLX [HP90] for which we prove the correctness of its pipelined model with respect to the sequential model. First we concentrate our attention on the provably correct refinement of the sequential ground model DLX to the pipelined parallel version DLX p in which structural hazards (resource conflicts) are eliminated. Then we extend the result to the model DLX data in which also data hazards for not jump instructions are treated. The next step consists of building the model DLX ctrl in which control hazards are eliminated. In the last step we define DLX pipe and prove that it refines DLX ctrl correctly and takes care also of data hazards relative to jump instruct...

We introduce a new verification methodology for modern microprocessors that uses a simple checker processor to validate the execution of a companion high-performance processor. The checker can be viewed as an at-speed emulator that is formally verified to be compliant to an ISA specification. This verification approach enables the practical deployment of formal methods without impacting overall performance. 1.

. This paper presents techniques for specifying microprocessor instruction set syntax and semantics in the HOL theorem proving system. The paper describes the use of abstract representations for operators and data, gives techniques for specifying instruction set syntax, outlines the use of records in specifying semantic domains, presents the creation of parameterized semantic frameworks, and shows how all of these can be used to create a semantics for a microprocessor instruction set. The verified microprocessor Uinta provides examples for each of these. 1 Introduction Much has been written over the years regarding the formal specification and verification of microprocessors [CCLO88, Bow87, Hun87, Coh88b, Coh88a, Gor83, Joy88, Hun89, Joy89, SB90, Her92, SWL93, TK93]. These efforts use many different proof systems and styles. We have verified a number of microprocessors in the HOL theorem proving system [Win90a, Win90b, Win94, WC94] and have developed techniques which clarify t...

This paper focuses on possibilities for automation which can be achieved##h a twofold way. Our experiences in interactive hardware verification with HOL and LAMBDA [12] have##ve 48 that most proofs follow a specific sequence of steps. This observation can ##n used to structure the hardware verification process and to find automatic decomposition##ecompo (similar to a manually performed proof) to transform the original goal into smaller ##aller This kind of automation is implemented in MEPHISTO (Managing Exhaustive Proofs of Hardware for Integrated circuit designers by Structuring Theorem proving Operations), elaborated in more detail in the next section. A large number of subgoals emerge from the decomposition process. The##e 442 proof is cumbersome and takes a lot of time, although most of these subgoals are quite simple to## 492 since they are first-order-like with only few higher-order constructs. ##nstructs. the proof of these subgoals is also possible by integrating an automated theorem ##eorem tool in HOL. It is based on RSEQ, a modified form of the known sequent calculus SEQ. RSEQ overcomes the inefficiencies of the standard sequent calculus approach. In section 3# RSEQ is described. The implementation of the prover FAUST (First-order Automation using Unification in a Sequent calculus Technique), which is based on RSEQ is explained in chapter 4.#Experimental results are reported in section 5 and section 6 concludes the paper. 2 STRUCTURE OF HARDWARE PROOFS In this section a brief overview of the structure of hardware proofs is## 4033 A more elaborate version of MEPHISTO -- the hardware oriented proof tool -- is found in## 409 A thorough study of various reports on hardware verification [6], [7], [8] as well as## 4 own investigations have shown, that it is possi...

The hol-4 proof system has been used to formally verify the correctness of the ARM6 micro-architecture. This paper describes the specification and verification of one instructions class, block data transfers; these are a form of load-store instruction in which a set of up to sixteen registers can be transferred atomically. The ARM6 is a commercial RISC microprocessor that has been used extensively in embedded systems – it has a 3-stage pipeline with a multi-cycled execute stage. A list based programmer’s model specification of the block data transfers is compared with the ARM6’s implementation which uses a 16-bit mask. The models are far removed and reasonably complex, and this poses a verification challenge. This paper describes the approach and some key lemmas used in verifying correctness, which is defined using data and temporal abstraction maps. 1

Abstract. The hol-4 proof system has been used to formally verify the correctness of the ARM6 micro-architecture. This paper describes the specification and verification of the multiply instructions. The processor’s implementation is based on the modified Booth’s algorithm. Correctness is defined using data and temporal abstraction maps. The ARM6 is a commercial RISC microprocessor that has been used extensively in embedded systems – it has a 3-stage pipeline with a multi-cycled execute stage. This paper describes the approach used in the formal verification and presents some key lemmas. 1