The climactic step in Gödel's proof of the incompleteness theorem is the construction of a sentence asserting its own unprovability. Since provability is a metatheoretic notion, the construction of such a sentence within Z2 requires that some part of the metatheory of Z2 be represented within Z2 itself. The main result of this chapter is an outline of the proof of the representability of the metatheory of Z2 (as described in Chapter 2) within Z2. The formalization of the representability theorem is perhaps the single most substantial and difficult part of our mechanical verification. The machinery of derived inference rules developed in Chapter 3 is heavily exploited in the representability proofs. The representability theorem is used in the construction of the undecidable sentence in Chapter 5.

The contents of this and the succeeding chapter are quite complicated since they define and use a seemingly unmanageable variety of encodings. One encoding represents the syntax of Z2 expressions using only numbers and the pairing operation of Lisp, and another encoding represents these latter Lisp data structures as sets in Z2. The representability theorem then shows the correspondence (under the encoding) between the metatheoretic Lisp computations and certain kinds of proofs in Z2.

A Brief Overview

We saw in Chapter 2 how the metatheory of Z2 could be formalized in terms of Lisp functions such as Collect-Free, Subst, Prf, and Proves.

Thus began Gödel's 1931 paper [Göd67b] in which he demonstrated the existence of formally undecidable sentences in a wide class of formal systems. The first part of this book describes a formalization and proof of this theorem that was carried out according to a “few mechanical rules.” The proof here is not a direct mechanization of any particular previously published version of the incompleteness proof. The statement of the theorem differs from Gödel's original statement which involved the notion of w-consistency. The statement here only involves the weaker notion of consistency and this form of the theorem was first proved by Rosser [Ros36]. The theorem we establish asserts the incompleteness of cohen's Z2 [Coh66]. The first-order logic of Z2 is taken from that of Shoenfield [Sho67]. Various metatheorems about Z2 are formalized and proved using the Boyer–Moore theorem prover.

This chapter presents a complete description of the formal statement of the incompleteness theorem. The main part of this description is the definition of the metatheory of Z2 in terms of a Lisp representation for the formulas and proofs of Z2, and a Lisp predicate that checks the validity of Z2 proofs represented in this manner. The representation of the symbols (variables, functions, predicates) and expressions (terms, atomic formulas, negation, disjunction, quantification) is first described. Various operations are defined for checking the well-formedness of expressions along with the important operation of substitution.

Electronic computers are mostly used to automate clerical tasks, but it is well known that they can also be programmed to play chess, compose music, and prove mathematical theorems. Since logical, mathematical reasoning is one of the purer forms of human, intellectual thought, the automation of such reasoning by means of electronic computers is a basic and challenging scientific problem. This book is about how computers can be used to construct and check mathematical proofs. This use of computers relies on their symbolic and deductive capabilities and is radically different from their use as fast numerical calculators. The impact of computers as intellectual, rather than clerical, tools is likely to be quite profound. This book tries to demonstrate in a concrete way that the capabilities of computing machines in this regard are quite powerful. It describes proofs of some significant theorems of mathematical logic that were completely checked by means of a computer.

This chapter gives an example to illustrate the idea of an abstraction relationship between two hardware models which was introduced in chapter 4. The two models considered are the threshold switching model of CMOS transistor behaviour defined in chapter 5 and the simpler switch model defined in chapter 2.

Both of these models of the CMOS technology are, of course, abstractions of the physical reality they represent, and both models are therefore bound to be inaccurate in some respects. But the switch model is also an abstraction of the threshold switching model, in the sense that both models describe the same set of primitive components—power, ground, N-type and P-type transistors—but the switch model presents a more abstract view of these components. The threshold switching model reflects the fact that real CMOS transistors do not pass both logic levels equally well. But in the more abstract (and therefore simpler) switch model, this aspect of transistor behaviour is ignored.

The switch model is less accurate than the threshold switching model; a circuit that can be proved correct using the switch model may in fact be incorrect according to the threshold switching model. For certain circuits, however, the two models are effectively equivalent. For these circuits, a proof of correctness in the switch model amounts to a proof of correctness in the threshold switching model. The switch model is an adequate basis for verification of these circuits, and the extra accuracy of the more complex threshold switching model is not needed.

This book shows how formal logic can be used to reason about the behaviour of digital hardware designs. The main focus is on a fundamental tool for dealing with the complexity of this activity—namely the use of abstraction in bridging the gaps between logical descriptions of hardware at different levels of detail.

The text of this book was adapted from a Ph.D. dissertation on abstraction mechanisms for reasoning about hardware, written at the University of Cambridge Computer Laboratory. This work was originally motivated by my experience with using the LCF_LSM theorem prover to verify the correctness of an associative memory device intended for use in a local area network. This device comprised 37 SSI and MSI TTL chips, the most complex of which was an AM 2910 microprogram controller. Although the design was straightforward, its verification using the LCF_LSM system was remarkably difficult. The main problem was simply the almost intractably large size of the intermediate theorems generated during the proof. Single theorems were generated that were hundreds of lines long, and several minutes or even several hours of CPU time were needed to manipulate them. The proof was completed only with considerable difficulty—unfortunately, some time after the LCF_LSM system had become obsolete.

These difficulties were for the most part due not to problems with the LCF_LSM theorem prover itself, but to deficiencies in the underlying formalism for hardware verification supported by the system.

Data abstraction is based formally on the use of logical types to model data. To make effective use of data abstraction, it is generally necessary to define special-purpose types for both design models and specifications of required behaviour. The formal properties these types are required to have will depend on the kind of behaviour being specified, on the level of abstraction at which the devices are described, and on how accurate the specifications are intended to be.

This means that no fixed collection of logical types can be an adequate basis for specifying all devices. The types bool and num→bool, for example, are sufficient for specifying hardware behaviour at the level of abstraction where the devices used are flip-flops and combinational logic gates. But at the level of abstraction where the primitive components are transistors, an accurate model of behaviour has to account for more kinds of values than can be represented by the two truth-values T and F. It may be necessary to represent electrical signals of several different strengths, or to represent ‘undefined’ or ‘floating’ values. The types bool and num→bool are also insufficient for specifications at the register-transfer level of abstraction, where it is often necessary to specify behaviour not in terms of the values on single wires but in terms of vectors of bits and arithmetical operations on fixed-width binary words. At the architecture level, concise specifications may require comparatively complex abstract data types, such as stacks and queues.

This chapter provides an overview of the formulation of higher order logic used in this book for reasoning about hardware. A brief account is also given of the mechanization of this logic in the HOL theorem proving system.

The version of higher order logic described in this chapter was developed by Mike Gordon at the University of Cambridge [41]. Gordon's version of higher order logic is based on Church's formulation of simple type theory [24], which combines features of the λ-calculus with a simplification of the original type theory of Whitehead and Russell [115]. Gordon's machine-oriented formulation extends Church's theory in two significant ways: the syntax of types includes the polymorphic type discipline developed by Milner for the LCF logic PPλ [48], and the primitive basis of the logic includes rules of definition for extending the logic with new constants and types.

The description of higher order logic given in this chapter is not complete, though it does cover all the aspects of the logic important to an understanding of later chapters. This book is concerned more with specifications than with proofs, and verification of theorems will be left mainly to the reader's logical and mathematical intuition. This chapter therefore deals mostly with notation. See Gordon's paper [41] or the HOL system manual [47] for a full account of higher order logic, including a list of the primitive rules of inference and a set-theoretic semantics.

Continued advances in microelectronics have allowed hardware designers to build devices of remarkable size and complexity. With increasing size and complexity, however, it becomes increasingly difficult to ensure that these devices are free of design errors. Exhaustive simulation of even moderately-sized circuits is impossible, and partial simulation offers only partial assurance of correctness.

This is an especially serious problem in safety-critical applications, where failure due to design errors may cause loss of life or extensive damage. In these applications, functional errors in circuit designs cannot be tolerated. But even where safety is not the primary consideration, there may be important economic reasons for doing everything possible to eliminate design errors, and to eliminate them early in the design process. A flawed design may mean costly and time-consuming refabrication, and mass-produced devices may have to be recalled and replaced.

A solution to these problems is one of the goals of formal methods for verification of the correctness of hardware designs—sometimes just called hardware verification. With this approach, the behaviour of hardware devices is described mathematically, and formal proof is used to verify that they meet rigorous specifications of intended behaviour. The proofs can be very large and complex, so mechanized theorem-proving tools are often used to construct them.

Considerable progress has been made in this area in the past few years.

The notion of abstraction plays a central role in making formal proof an effective method for dealing with the problem of hardware correctness. This chapter explains how two important types of abstraction—which will be referred to as abstraction within a model of hardware behaviour and abstraction between models of hardware behaviour—can be expressed in higher order logic.

Abstraction within a model has to do with the way in which the correctness of individual designs is formulated. With the approach to hardware verification introduced in the previous chapter, correctness is stated by a proposition which asserts that some relationship of ‘satisfaction’ holds between the model of a circuit design and a specification of its intended behaviour. This relationship must, in general, be one of abstraction—it must relate a detailed model of an actual design to a more abstract specification of required behaviour. Sections 4.1–4.6 show how this notion of correctness as an abstraction relationship can be formalized in logic and incorporated into the method of hardware verification already introduced.

The second type of abstraction, called abstraction between models, is discussed in section 4.7. Here the concern is not with the correctness of individual designs, but with the relationship between two different collections of specifications for the primitive components used in all designs. One such collection can be an abstraction of another in the sense that it presents a more abstract view of the same primitive components.

This chapter describes the basic techniques for using higher order logic to specify hardware behaviour and to prove the correctness of hardware designs.

The advantages of higher order logic as a formalism for hardware verification are discussed by Gordon in [45] and by Hanna and Daeche in [57, 58]. Higher order logic makes available the results of general mathematics, and this allows one to construct any mathematical tools needed for the verification task in hand. Its expressive power permits hardware behaviour to be described directly in logic; a specialized hardware description language is not needed. In the formulation used here, new constants and types can be introduced by purely definitional means. This allows special-purpose notation for hardware verification to be introduced without the danger associated with postulating ad hoc axioms. In addition, the inference rules of the logic provide a secure basis for proofs of correctness; a specialized deductive calculus for reasoning about hardware behaviour is not required.

Although higher order logic has all these pragmatic advantages, to say that it is the only feasible formalism for hardware verification would be an exaggeration. Some other approaches axe briefly discussed at the end of this chapter. Furthermore, higher order logic does not make traditional hardware description languages (HDLs) obsolete. A major problem with these languages is that they usually lack a formal semantics, which precludes using them to reason about hardware behaviour.

INTRODUCTION

This case study is a formal description of a protocol for a local area network, using the specification language PSF.

One approach to local networking is the ring network. Although various types of rings have been proposed and built, we will study one of the more popular organizations, the token ring network. In such a network, a token circulates around the ring, which can be captured by one of the components. The component guarding the token is allowed to transmit a message.

The protocol specified in this paper is based on the token ring described in [IEEE85b] as an IEEE standard. This description is given partly in informal, natural language and drawings, and partly by means of state transition systems. The intention of this chapter is to apply a Formal Description Technique in order to give a formal specification of the protocol. In contrast to the protocols in the previous chapters, we try to provide a specification, that resembles an existing standard as much as possible.

TOKEN RING NETWORK, AN INTRODUCTION

A ring consists of a collection of ring interfaces connected by point-to-point links that form a circle, as shown in Figure 7.1. Point-to-point links involve a well-understood and field-proven technology. Due to the sequential ordering of the stations attached to a ring, a ring-based protocol is in general fair in the sense that each station eventually will get control of the ring. In a token ring, each station has a known upper bound on channel access. The ring network standardized in [IEEE85b] is called a token ring and in this section we will take a closer look on what this is.