Results 1  10
of
18
A Practical Method for Rigorously Controllable Hardware Design
 ZUM’97: The Z Formal Specification Notation, volume 1212 of LNCS
, 1996
"... 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 oneinstructionatatime ..."
Abstract

Cited by 21 (3 self)
 Add to MetaCart
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 oneinstructionatatimeview 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.
Structuring and Automating Hardware Proofs in a HigherOrder TheoremProving Environment
 Formal Methods in System Design
, 1993
"... . In this article we present a structured approach to formal hardware verification by modelling circuits at the registertransfer level using a restricted form of higherorder logic. This restricted form of higherorder logic is sufficient for obtaining succinct descriptions of hierarchically design ..."
Abstract

Cited by 20 (7 self)
 Add to MetaCart
. In this article we present a structured approach to formal hardware verification by modelling circuits at the registertransfer level using a restricted form of higherorder logic. This restricted form of higherorder logic is sufficient for obtaining succinct descriptions of hierarchically designed registertransfer 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 hardwarespecific tool called MEPHISTO converts the original goal into a set of simpler subgoals, which are then automatically solved by a generalpurpose, firstorder prover called FAUST. Furthermore, the complete verification framework is being integrated within a commercial VLSI CAD framework. Keywords: hardware verification, higherorder logic 1 Introduction The past decade has witnessed the spiralling of interest within the academic com...
A Correctness Model for Pipelined Microprocessors
"... 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 verific ..."
Abstract

Cited by 18 (1 self)
 Add to MetaCart
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 nonpipelined 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...
The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems
"... An indepth 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 potenti ..."
Abstract

Cited by 11 (1 self)
 Add to MetaCart
An indepth 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.
A Correctness Proof for Pipelining in RISC Architectures
, 1996
"... 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 Patte ..."
Abstract

Cited by 8 (4 self)
 Add to MetaCart
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...
Scalable hybrid verification of complex microprocessors
 In 38th Design Automation Conference (DAC2001
, 2001
"... We introduce a new verification methodology for modern microprocessors that uses a simple checker processor to validate the execution of a companion highperformance processor. The checker can be viewed as an atspeed emulator that is formally verified to be compliant to an ISA specification. This v ..."
Abstract

Cited by 7 (5 self)
 Add to MetaCart
We introduce a new verification methodology for modern microprocessors that uses a simple checker processor to validate the execution of a companion highperformance processor. The checker can be viewed as an atspeed 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.
Specifying InstructionSet Architectures in HOL: A Primer
, 1994
"... . 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 recor ..."
Abstract

Cited by 5 (0 self)
 Add to MetaCart
. 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...
Automating Most Parts of Hardware Proofs in HOL
 In Proceedings of the Third Workshop on Computer Aided Verification, CAV 91
, 1991
"... 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 verificat ..."
Abstract

Cited by 3 (0 self)
 Add to MetaCart
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 firstorderlike with only few higherorder 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 (Firstorder 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...
GATE – a general architecture for text engineering
 In Proceedings of the 16th Conference on Computational Linguistics (COLING96). http://citeseer.nj.nec.com/43097.html
, 2004
"... The hol4 proof system has been used to formally verify the correctness of the ARM6 microarchitecture. This paper describes the specification and verification of one instructions class, block data transfers; these are a form of loadstore instruction in which a set of up to sixteen registers can be ..."
Abstract

Cited by 2 (1 self)
 Add to MetaCart
The hol4 proof system has been used to formally verify the correctness of the ARM6 microarchitecture. This paper describes the specification and verification of one instructions class, block data transfers; these are a form of loadstore 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 3stage pipeline with a multicycled execute stage. A list based programmer’s model specification of the block data transfers is compared with the ARM6’s implementation which uses a 16bit 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
Verifying ARM6 Multiplication
"... Abstract. The hol4 proof system has been used to formally verify the correctness of the ARM6 microarchitecture. 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 us ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
Abstract. The hol4 proof system has been used to formally verify the correctness of the ARM6 microarchitecture. 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 3stage pipeline with a multicycled execute stage. This paper describes the approach used in the formal verification and presents some key lemmas. 1