A Transformational Approach to FormalDigital System DesignMats LarssonApril 28, 1993

AcknowledgementsAcknowledgementsI would like to thank my supervisor, Krzysztof Kuchcinski, and the members ofmy advisory group, Tony Larsson and Anders Haraldsson, for their guidance andsupport during this work. A special thanks to Tony for introducing me to formalmethods.A major part of the work presented here was carried out at the University ofCambridge in England. This was made possible thanks to the Prince Bertil Schol-arship. The scholarship was sponsored by the British Foreign and CommonwealthO�ce and Tetra-Pak jointly, and administrated by the British Council in Stockholm,London and Cambridge. Without it I could not have written this thesis.Thanks to everyone at the hardware veri�cation group in Cambridge and in par-ticular to Mike Gordon who made me feel welcome from the start and continuedto be friendly and supportive throughout my stay. I would also like to thank ev-eryone in TP6| Monica, Victor, John and Jim|for making the casual chat a truecompetitor for my time.Jim Grundy must be mentioned explicitly here since proof-reading his papers,and listening to him practising talks he was to give, made me interested in windowinference. I must also thank him for implementing and supporting the windowinference package in HOL in a most excellent way. He also answered questions onLaTEX and HOL without complaining although the nature of the questions sometimesmust have made him doubt my sanity (I know I did). As if this was not enough,he was also kind enough to proof read an earlier version of this thesis and giveinvaluable comments both on the content and on the use of English. John Harrisonalso made valuable comments on early versions of some chapters. All remainingerrors are, of course, my own.I would also like to thank my wife Katarina for her patience as well as for beinga constant source of inspiration and joy to me.Finally, I would like to thank the administrative sta�, especially Bodil Mattsson-Kihlstr�om and Lillemor Wallgren, for their help with administrative matters, andLeif Finmo for keeping the machines running. Link�oping, April 1993Mats Larssoni

ii

Contents1 Introduction 11.1 Our Approach : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 21.2 Contributions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 31.3 Outline of the Thesis : : : : : : : : : : : : : : : : : : : : : : : : : : : 42 Background 52.1 Preliminaries : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 52.2 Previous Work : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 72.2.1 Hardware Description Languages and Simulation : : : : : : : 72.2.2 High-Level Synthesis : : : : : : : : : : : : : : : : : : : : : : : 82.2.3 Formal Veri�cation : : : : : : : : : : : : : : : : : : : : : : : : 82.3 Formal Digital System Design : : : : : : : : : : : : : : : : : : : : : : 102.3.1 The Role of Formal Digital System Design : : : : : : : : : : : 112.3.2 Key Properties : : : : : : : : : : : : : : : : : : : : : : : : : : 122.4 Related work : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 122.4.1 Formal Design Approaches : : : : : : : : : : : : : : : : : : : : 122.4.2 Transformational Design Approaches : : : : : : : : : : : : : : 142.4.3 Other Approaches : : : : : : : : : : : : : : : : : : : : : : : : : 153 HOL and Hardware Veri�cation 1 173.1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 183.2 Terms : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 193.3 Types : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 203.4 Theories and De�nitions : : : : : : : : : : : : : : : : : : : : : : : : : 213.5 Sequents, Theorems and Proofs : : : : : : : : : : : : : : : : : : : : : 213.6 Security and Extensibility : : : : : : : : : : : : : : : : : : : : : : : : 223.7 Proof Styles and Tools : : : : : : : : : : : : : : : : : : : : : : : : : : 233.7.1 Derived Inference Rules : : : : : : : : : : : : : : : : : : : : : 233.7.2 Subgoal Package : : : : : : : : : : : : : : : : : : : : : : : : : 243.7.3 Window Inference : : : : : : : : : : : : : : : : : : : : : : : : : 263.8 Hardware Speci�cation and Models : : : : : : : : : : : : : : : : : : : 283.8.1 Hardware Speci�cation : : : : : : : : : : : : : : : : : : : : : : 283.8.2 Two Transistor Models : : : : : : : : : : : : : : : : : : : : : : 323.9 Veri�cation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 343.9.1 Stating Correctness : : : : : : : : : : : : : : : : : : : : : : : : 34iii

3.9.2 An Example Correctness Proof : : : : : : : : : : : : : : : : : 363.10 Further Reading : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 384 A Transformational Approach 414.1 Design Representation : : : : : : : : : : : : : : : : : : : : : : : : : : 424.1.1 The Logic Level : : : : : : : : : : : : : : : : : : : : : : : : : : 434.1.2 Design Annotation : : : : : : : : : : : : : : : : : : : : : : : : 434.2 Design Transformation : : : : : : : : : : : : : : : : : : : : : : : : : : 474.2.1 Graphical Design State Representation : : : : : : : : : : : : : 504.3 Implementation Method : : : : : : : : : : : : : : : : : : : : : : : : : 504.3.1 Design Annotation Functions : : : : : : : : : : : : : : : : : : 524.3.2 Window Transforms : : : : : : : : : : : : : : : : : : : : : : : 545 High-Level Synthesis 575.1 Design Model : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 575.1.1 Assumptions about Digital Systems : : : : : : : : : : : : : : : 595.2 Transformational Synthesis : : : : : : : : : : : : : : : : : : : : : : : : 605.2.1 Getting Started : : : : : : : : : : : : : : : : : : : : : : : : : : 605.2.2 Allocating Computation : : : : : : : : : : : : : : : : : : : : : 605.2.3 Scheduling Computation : : : : : : : : : : : : : : : : : : : : : 655.2.4 Resolving Constraints : : : : : : : : : : : : : : : : : : : : : : 695.2.5 Synthesising Interconnection : : : : : : : : : : : : : : : : : : : 796 Design by Re�nement 876.1 Formal Re�nement : : : : : : : : : : : : : : : : : : : : : : : : : : : : 876.1.1 Behavioural Re�nement : : : : : : : : : : : : : : : : : : : : : 886.1.2 Data Re�nement : : : : : : : : : : : : : : : : : : : : : : : : : 886.1.3 Temporal Re�nement : : : : : : : : : : : : : : : : : : : : : : : 896.2 An IIR-�lter Example : : : : : : : : : : : : : : : : : : : : : : : : : : 906.2.1 Pre-Processing : : : : : : : : : : : : : : : : : : : : : : : : : : 916.2.2 Window Transformation : : : : : : : : : : : : : : : : : : : : : 916.2.3 Post-Processing : : : : : : : : : : : : : : : : : : : : : : : : : : 1036.3 Behavioural Transformation : : : : : : : : : : : : : : : : : : : : : : : 1047 Summary and Future Work 1077.1 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1077.2 Future work : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1087.2.1 Interfacing to CAD-tools : : : : : : : : : : : : : : : : : : : : : 1087.2.2 Automation : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1097.2.3 Design Validity : : : : : : : : : : : : : : : : : : : : : : : : : : 1097.2.4 Design Documentation : : : : : : : : : : : : : : : : : : : : : : 1107.2.5 Window Inference : : : : : : : : : : : : : : : : : : : : : : : : : 1107.2.6 User Interface : : : : : : : : : : : : : : : : : : : : : : : : : : : 1107.2.7 Hardware/Software Codesign : : : : : : : : : : : : : : : : : : 1117.2.8 Speci�cation Language : : : : : : : : : : : : : : : : : : : : : : 111iv

Index 121

v

vi

List of Figures2.1 Design transitions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 62.2 The role of formal digital system design : : : : : : : : : : : : : : : : : 113.1 A prooftree : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 253.2 A collapsed prooftree : : : : : : : : : : : : : : : : : : : : : : : : : : : 253.3 A device Dev : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 293.4 tm1 [a; x ] and tm2 [x ; b] : : : : : : : : : : : : : : : : : : : : : : : : : : 313.5 tm1 [a; x ] ^ tm2 [x ; b] : : : : : : : : : : : : : : : : : : : : : : : : : : : : 323.6 9x : tm1 [a; x ] ^ tm2 [x ; b] : : : : : : : : : : : : : : : : : : : : : : : : : : 323.7 CMOS components : : : : : : : : : : : : : : : : : : : : : : : : : : : : 333.8 A formal model of a CMOS inverter : : : : : : : : : : : : : : : : : : : 374.1 View of the design process : : : : : : : : : : : : : : : : : : : : : : : : 414.2 Abstract syntax for design annotations : : : : : : : : : : : : : : : : : 454.3 Semantic algebras for design annotations : : : : : : : : : : : : : : : : 464.4 Semantic algebras, continued : : : : : : : : : : : : : : : : : : : : : : : 474.5 Valuation functions for design annotations : : : : : : : : : : : : : : : 484.6 Devices : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 505.1 Constant dummy in the basic library : : : : : : : : : : : : : : : : : : 585.2 Interconnection devices in the basic library : : : : : : : : : : : : : : : 585.3 Devices in the comp library : : : : : : : : : : : : : : : : : : : : : : : 595.4 Timing analysis of the design in session box 7 : : : : : : : : : : : : : 665.5 Scheduling the design in session box 7 : : : : : : : : : : : : : : : : : : 675.6 The design after session box 8 : : : : : : : : : : : : : : : : : : : : : : 685.7 The design after session box 15 : : : : : : : : : : : : : : : : : : : : : 745.8 The design after session box 16 : : : : : : : : : : : : : : : : : : : : : 755.9 The design after session box 19 : : : : : : : : : : : : : : : : : : : : : 785.10 The design after session box 20 : : : : : : : : : : : : : : : : : : : : : 815.11 The design after session box 22 : : : : : : : : : : : : : : : : : : : : : 825.12 The design after session box 23 : : : : : : : : : : : : : : : : : : : : : 845.13 The design after session box 24 : : : : : : : : : : : : : : : : : : : : : 855.14 The design after session box 25 : : : : : : : : : : : : : : : : : : : : : 866.1 The design after session box 7 : : : : : : : : : : : : : : : : : : : : : : 966.2 The completed design after session box 9 : : : : : : : : : : : : : : : : 986.3 The completed design after session box 16 : : : : : : : : : : : : : : : 103vii

viii

List of Tables2.1 A design hierarchy : : : : : : : : : : : : : : : : : : : : : : : : : : : : 52.2 Design transitions in terms of information added : : : : : : : : : : : : 63.1 User-level syntax of HOL : : : : : : : : : : : : : : : : : : : : : : : : : 19

ix

x

Chapter 1IntroductionIn this thesis an approach to the design and veri�cation of digital systems is pre-sented. Our approach is based on formal digital system design, i.e. the idea tocombine the activities of design and formal veri�cation. We de�ne formal digitalsystem design like this:By formal digital system design we mean the integrated process of proofand design that starting from a formal speci�cation of a digital system,generates a proof of correctness of its implementation as a by-product ofthe design process.Thus, by using this method, the designer can interactively transform the speci�ca-tion into a design that implements the speci�cation, and at the same time generatea proof of its correctness.As production technology has continued to improve during the last decades,the complexity of digital systems has increased accordingly. This ever increasingcomplexity has led to digital systems having shorter life cycles and to the designtask growing more di�cult. At the same time, the use of digital systems in safetycritical applications | such as pacemakers, aeroplane stability control, and nuclearplant control | has led to a need to be able to ensure correctness. Correctness isof course an important criteria for all designs, but these applications have servedto emphasise the problem. Thus, an ideal design system would have to ful�ll thefollowing requirements:� reduce the overall design time;� handle more complex systems;� ensure the correctness of the implemented system.The attempts that so far have been made to solve these problems have come fromtwo very di�erent research communities, the `engineering' community has focusedon problems relating to design implementation and the `formal methods' communityhas focused on problems relating to design veri�cation. The currently dominatingproposed solutions are high-level synthesis for design implementation and formal1

veri�cation for design veri�cation. The problem is that these solutions are con ict-ing, i.e. the use of high-level synthesis makes formal veri�cation more di�cult andthe use of formal veri�cation increases the overall design time drastically.The requirements on design methods stated above can only be solved using amethod for the whole design process, i.e. both the implementation and the veri�-cation phase of the design process. We claim that our approach to formal digitalsystem design is such a method and that the following key properties of the approachmakes it satisfy the requirements.First, by integrating the design and veri�cation processes we avoid the iterative`design then verify' cycle of traditional design methods as we detect errors whenthey are introduced. Second, by providing support for design at higher-levels ofabstraction | such as a design calculus in the form of a set of design transforma-tions, the support for arbitrary abstractions in both designs and speci�cations, andthe support for design checks and design analysis | we can reduce design times.Third, by documenting the design process we make designs and design derivationsreusable objects, and thereby facilitate maintenance, re-engineering and reusabil-ity of designs. Fourth, by designing using proved design steps we can ensure thecorrectness of the implemented design with respect to the speci�cation. Fifth, byenforcing the use of pre-design formal speci�cations we require that the design taskis well understood, before the design process begins.1.1 Our ApproachWe call our approach to formal digital system design transformational . By this wemean that we take a transformational view of the design process. That is, we regarddesign as an iterative process that progresses stepwise by applying design decisionsthat transforms the design until a satisfactory design has been reached.As implementation platform we use the HOL proof system. HOL is an acronymfor higher-order logic, and we use it to denote the particular formulation and mecha-nization of higher-order logic in HOL88 version 2.01 from Cambridge. It is a systemthat implements classical higher-order logic. The choice of HOL is motivated by thefact that many years of e�ort and experience have been invested in tools for classicallogic, like the HOL system. To build a system with the security, reasoning ability,and implemented theories of these tools would be a di�cult task. The system hasthe following key features for our approach:� Provides safe symbolic reasoning about design objects. This is done by onlyallowing terms in the HOL logic to be manipulated by applying valid logicalrules.� Provides safe extensions to the basic HOL logic by de�nitions, and throughthe de�nitional mechanism. This makes it possible to embed other formalisms,e.g. hardware description languages, in the logic.� Provides a programmable interface to the logic. This consists of the functionalprogramming language ML in which the logic is embedded. This makes it2

possible to manipulate designs and proofs by writing programs in ML.Since any formalism could be de�ned in classical higher-order logic, the choice of HOLas formal system is no limitation on the choice of design language. A design languagefor formal digital system design must be able to express design speci�cations as wellas design implementations. For our current application of formal digital systemdesign, a simple hardware model in logic is su�cient as implementation language.The ability to express many di�erent styles of speci�cations makes logic a goodchoice as speci�cation language too. Hence, we use the HOL logic to model designsfrom initial speci�cation to �nal implementation [38]. This allows for exible andcompact descriptions, arbitrary mixtures of behaviour and structure, and partialspeci�cations. This way, we are not only free to use classical logic to reason aboutdesign objects, but we can manipulate them directly as terms in the logic.A key component of our approach is the use of the window inference package [41]in HOL to model the transformational design process. Window inference is a styleof reasoning where the user may transform an expression or restrict attention to asubexpression and transform it. While restricting attention to a subexpression theuser can transform the subexpression without a�ecting the rest of the expression.While transforming a subexpression, the user can make assumptions based on thecontext of the subexpression. In window inference the design state is captured bythe current window theorem and a design step is modelled as a transformation ofthe design state. By opening subwindows we can restrict attention to parts of thedesign and thereby partition the design task into smaller subtasks. Through theprogrammability of the proof system we can implement a (custom) design calculusby writing ML programs that implement design transformations. This way we canprovide support for the designer and make the system easier to use for those withouta background in formal methods.To be able to support the process of designing digital systems in a formal envi-ronment, we need to do more than just model the design process, we also need tosupport it. For this we need a more elaborate representation of designs than purelogic. We propose to do this by annotating our design logic with additional infor-mation. These annotations can be used to, for example, capture the intentions ofthe designer and implement design heuristics. This works well since the informationnecessary for making design decisions and checking design heuristics is not the sameas the information necessary to verify designs formally. Design annotations can alsohelp to alleviate the `false implies everything' problem when we use implication assatisfaction relation.1.2 ContributionsThe major contributions of this thesis are:� This is the �rst major application of window inference and of course also the�rst time window inference is used for reasoning about digital systems.3

� We have demonstrated that the formal design approach to designing correctdigital systems can be carried out in `classical'HOL. This is of great signi�cancesince HOL is distributed freely and is widely used throughout the world.� The use of an annotated design logic to support the design process is new.1.3 Outline of the ThesisIn the thesis we will focus on the use of formal digital system design for interactivehigh-level design, i.e. the synthesis and re�nement of abstract behavioural speci�-cations to (more) concrete structural speci�cations.In Chapter 2, we present the necessary background to the work presented inthe thesis. We begin in Section 2.1 with preliminaries where we introduce someclassi�cation and terminology used in the �eld of digital system design, and therebyalso in the thesis. We continue in Section 2.2 with a background to other design andveri�cation methods, existing or proposed. In Section 2.3 we discuss formal digitalsystem design in general. Last, in Section 2.4 we present related work and discusssome of these in relation to the work presented in this thesis.In Chapter 3 we present HOL, the formal system we will use as a platform forthe implementation of our approach. In this chapter we do two things. First, weintroduce the HOL logic and the mechanization of it in the HOL system. Thisincludes di�erent proof styles such as window inference. Second, we explain how tomodel hardware and state correctness in the logic and how to use the system forproving correctness. The material in this chapter is not new, and has already beencovered in considerably more detail elsewhere. The chapter is intended to work asan introduction to the use of formal methods in general | and HOL in particular| in digital systems design and veri�cation.We present our approach to formal digital system design in Chapter 4. We discussthe representation of designs in Section 4.1. Here we introduce the idea of a two-leveldesign representation and the formal language of design annotations. In Section 4.2we discuss the transformation of designs and for this reason introduce and de�neconcepts like design state, design step and design process. Last, in Section 4.3 weshow how a system based on these principles can be implemented using the HOLsystem and the window inference package.In Chapter 5 we demonstrate how a system based on the ideas presented inChapter 4 can be used to perform interactive high-level synthesis. We use a simpleexample of a multiple addition device to make things more concrete, and introducedesign transformations as they are needed in the example.In the same way as in Chapter 5 we use an example to demonstrate design byre�nement in Chapter 6. This time the example is an in�nite impulse response (IIR)�lter with a recursive speci�cation. We start the chapter with a discussion of theuse of abstraction and re�nement in digital system design.We conclude in Chapter 7 with a summary of the work presented here and onfuture research tasks that are of particular interest to us.4

Chapter 2Background2.1 PreliminariesIn computer-assisted digital system design, designs are traditionally described withinthree domains and at a number of abstraction levels that together form a designhierarchy (see Table 2.1). The domains are the behavioural , the structural and theDOMAINSLevel Behaviour Structure PhysicalPMS (System) Communicating Processors, CabinetsProcesses Memories, CablesSwitchesInstruction Set Input-Output Memory, Ports, Board(Algorithm) (Programs) Processors Floor planRegister-Transfer Register ALUs, Regs, ICsTransfers Muxs, Bus Macro CellsLogic Logic Gates, Standard CellEquations Flip ops LayoutCircuit Network Transistors, TransistorEquations Connections LayoutTable 2.1: A design hierarchyphysical . In the behavioural domain, the intended behaviour is speci�ed, ideally ina way that is not biased towards any particular implementation. In the structuraldomain, one deals with the system as a hierarchy of functional units and theirinterconnection. In the physical domain, the structure of the design is mapped intospace, without any reference to its functionality. The abstraction levels used are not�xed, but a typical set (adapted from [66]) can be seen in Table 2.1 together withtypical primitives associated with each level in the three domains.Table 2.1 is a static description of the design hierarchy but it tells us nothingabout the dynamic aspects of designing, the design tasks. There are di�erent ways toclassify these. An approach often used by people working in the area of CAD-tools isto classify the process of designing digital systems into a set of design tasks accord-5

ing to the abstraction level of the input description|system-level design, high-leveldesign, register-transfer design, logic-level design, technology mapping and physi-cal generation|that together form a hierarchy of design tasks. However, since atypical design representation will have mixed levels and mixed domains, such strictclassi�cations are not easily applied to existing design representations and designsteps. Instead, a di�erent classi�cation (from [60]), based on domain transitionscan be seen in Figure 2.1. There transitions from the structural to the physical.

level 1

.

.level n

.level 1

.

.level n

refinement abstraction

PhyStrBeh

analysis extraction

generationsynthesisFigure 2.1: Design transitionsdomain are called generation, reverse transitions are called extraction, those fromthe behavioural to the structural domain synthesis and transitions in the oppositedirection are called analysis. Transitions within a domain but over abstraction levelsare called re�nement if they go from abstract to concrete and abstraction if they gothe opposite way. In �gure 2.1 we have illustrated transitions as arrows between do-mains (synthesis, analysis, generation and extraction) and abstraction levels withina domain (re�nement and abstraction). Abstraction, analysis and extraction areveri�cation transitions as opposed to re�nement, synthesis and generation that aredesign transitions. An alternative way to express this, based on the observation thateach design transition adds information to the system description, can be seen intable 2.2. In the rest of the thesis, we will focus on the synthesis and re�nementNotion Adds Based onSynthesis Structural information Behavioural/StructuralinformationAnalysis Behavioural information Structural informationGeneration Physical information Structural informationStructural Structural information Physical/Geometricalextraction informationBehavioural Behavioural information Physical/Geometricalextraction informationRe�nement More detailed More abstract informationinformation from same domainAbstraction More abstract More detailed informationinformation from same domainOptimization Improved version Former versionfrom same domainTable 2.2: Design transitions in terms of information added6

design transitions, and we will not discuss lower design levels than high-level design.2.2 Previous WorkThe design of a digital system can be partitioned into two phases, design imple-mentation and design veri�cation. Traditionally, design and veri�cation has beencarried out separately with veri�cation as a post-design process. This `design thenverify' process is then carried out in an iterative fashion until an implementationhas been veri�ed correct.We start by presenting the two most widely used methods in high-level designtoday. These are design modelling with hardware description languages, and ver-i�cation using simulation. Then we present the high-level synthesis approach tohigh-level design and the formal veri�cation approach to (high-level) veri�cation.2.2.1 Hardware Description Languages and SimulationThe support for designing at higher-levels of abstraction that is available to design-ers today is hardware description languages [49]. A hardware description language(HDL) is a computer language designed for modelling hardware at higher-levels ofabstraction than the gate-level. All modern HDL's are hierarchical and multi-level.This means that they can model both structure and behaviour, often in the samedescription, and that they can model behaviour at multiple abstraction levels. Ex-amples of modern HDL's are VHDL [55, 61], Verilog [93] and ELLA [24]. Thesemantics of these languages are de�ned in the form of a simulator, i.e. they havea non-formal operational semantics. This makes these languages inappropriate touse as a design calculus since the equivalence of two descriptions cannot be veri-�ed other than by simulation. Instead they have their primary use as modellinglanguages since they allow designers to model and simulate designs described at anabstract behavioural level.The most widely used method for veri�cation today is simulation. Unfortunately,this method has serious limitations. To completely verify a design by simulation,we need to simulate it for all possible sequences of inputs. This does, however,become infeasible already for small designs that contain state. Instead, a set oftest vectors is chosen and the design is simulated with this set as input. This way,a design is veri�ed for the set of input vectors, but is otherwise unveri�ed. Suchpartial veri�cations can, however, show only the presence of errors, not the absenceof errors. The actual veri�cation step is by comparison of the simulation results,either with the output of a simulation of a di�erent representation of the designor with the designers notion of expected behaviour. Both these comparisons areinformal since they rely on the designers ability to interpret the results correctlyand the correctness of the simulator. 7

2.2.2 High-Level SynthesisAn automatic high-level synthesis (HLS) system uses algorithms to implement thedesign steps that generate register-transfer design descriptions from behaviouraldescriptions at the algorithm level. Many di�erent approaches to HLS have beenpresented in the literature, too many for us to be able to list them explicitly here.Instead we refer to some good introductions available [30, 66]. However, we cansummarise their most important common properties in the following way:� use procedural HDL's for input speci�cation;� compile the input language to an internal design representation;� schedule each speci�ed operation to a speci�c control step;� allocate hardware resources for operations, interconnections and storage;� bind each allocated resource to a speci�c implementation of it.Mapping between the procedural input and the register-transfer output is straight-forward | operators to functional units, variables to registers or signals and controlstructures to actions of a controller. The problem is �nding the best mapping, undersome constraints, from the large number of possible mappings (the design space). To�nd this mapping, an extensive search| guided by heuristics, must be performed.Thus the bulk of high-level synthesis is optimization.Using procedural HDL's for input speci�cation makes simulation the obviouschoice for veri�cation method. We can, however, not solve the correctness problemusing simulation. To do this formal veri�cation methods are necessary. There arebasically two approaches to this. We either prove the design steps in the HLSsystem or apply post-design veri�cation (i.e. verify an input-output relation). Wepresent some attempts using the �rst approach in the related work section. For theother approach the general problems of post-design formal veri�cation presented inSection 2.2.3 apply. The problem is that formal veri�cation of HLS results is evenharder than normal formal veri�cation. The increased di�culty is to a large extentdue to the use of HDL's for input speci�cation which makes this task similar to thesoftware veri�cation task.2.2.3 Formal Veri�cationFormal veri�cation has been proposed by many as the solution to the correctnessproblem in digital system design. By formal veri�cation we mean the applicationof mathematically rigorous methods to prove a satisfaction relation between twodesign descriptions. The result of formal veri�cation is a relation between two designdescriptions which is valid for all input sequences. There are many approaches toformal veri�cation, each based on di�erent speci�cation styles, e.g. predicate logic,temporal logic and automata/language theory. For designs described at the booleanlogic level, formal tools such as tautology checkers, model checkers and state-machineequivalence checkers have been successful in the sense that they have gained wide8

acceptance by designers. For designs described at more abstract levels however,formal veri�cation methods have made very little impact on current design methods.In the case of temporal logic and automata/language theory approaches, this ismainly because they run into problems of lack of modularity and abstraction andtherefore su�ers from an explosion of the computational complexity of the algorithmsused [77, section 7].The methods based on predicate logic however handles modularity and abstrac-tion well. Their problem is that the proof process cannot be automated at this leveland that we therefore must perform manual theorem proving on very distinct designdescriptions, a task that has been shown to be di�cult and time consuming for non-trivial problems [40]. In fact, experience has shown that the sheer labour of carryingout formal veri�cation of a design in logic is typically a couple of magnitudes greaterthan the actual task of designing it. The reason for this is twofold:� The semantic gap between the conceptual, high-level at which human designerreasons and the very low level at which the primitive inference rules of thedesign logic are stated. This problem can be alleviated but not solved bysupplying higher-level domain speci�c proof procedures.� The lack of information sharing between the design and the veri�cation tasks.Because of this, the human veri�er has to bridge a semantic gap between thedesign speci�cation and the design implementation. To do this the veri�erhas to reinvent the design decisions taken during the design and communicatethese to the proof system.Apart from the e�ort required, formal veri�cation has a few other properties thatmakes widespread industrial application less likely:� Theorem proving is inherently di�cult and require the user to have a goodbackground in formal methods. Since designers in general do not have that, anew kind of engineers, veri�cation engineers, is necessary.� The formal veri�cation approach is not easily integrated with existing designpractices and CAD-tools. This is because it is a post-design process requiringa di�erent formalism for design descriptions than HDL's that are used for high-level design. Formalisms such as logic are unacceptable to many designers andis also unsuitable for input to CAD-tools such as simulators and synthesisers.This leads to the use of di�erent design descriptions for design and veri�cation,hence making integration di�cult.In an attempt to alleviate the latter problem, much work has been carried out onsupporting the use of HDL's in formal systems. One way to do this is to de�nesemantics for existing HDL's in formal systems (see [8] for a general discussion).Examples of this approach are: ELLA [7, 9, 72], VHDL [5, 81, 94, 95] and the data- ow language Silage [33, 32]. However, experience has shown that most `real'HDL's have a more complicated semantic de�nition than most design logics. Even9

with a well-de�ned HDL such as ELLA, the logical terms representing ELLA expres-sions in HOL gets voluminous and hard to use, thus making reasoning unnecessarydi�cult.The other approach is to de�ne new HDL's with formally de�ned semantics (see[28] for a general discussion). Examples of this approach can be found in [21, 53,56, 58, 70, 80, 84, 89]. Basically, a design logic is also a formal HDL.2.3 Formal Digital System DesignIn this section we introduce and discuss formal system design. We start by relatingit to the concepts of design and formal veri�cation. It is fair to say that formaldigital system design has developed from formal veri�cation, and can be seen as anattempt to solve or alleviate the problems of formal veri�cation that we listed inSection 2.2.3. It does this in the following way:� By providing design transformations that correspond to `natural' design deci-sions, the level of reasoning is natural for a designer. This can be comparedto the high-level proof procedures approach mentioned in Section 2.2.3.� By integrating design and veri�cation we make information sharing betweendesign and veri�cation unavoidable. The information given in the design de-cision is naturally used to prove the justi�cation of it.� By `hiding' proof steps as design steps it makes this approach easier to use fordesigners and avoid the need for veri�cation engineers other than possibly forthe construction of proved design steps that later can be used by designers.� By supplying an integrated design and veri�cation method we avoid the needfor di�erent formalisms. The unwillingness among designers to accept logicas HDL can be alleviated by the embedding existing HDL's or de�ning newformal HDL's in our formal system as explained in Section 2.2.3.Formal digital system design has inherited the idea to design by applying correctness-preserving transformations from an area commonly referred to as transformationaldesign. We de�ne the area of transformational design as non proof based methodsto design by applying correctness-preserving transformations according to a designalgebra. This algebra is in most cases functional. The distinction we make is thatin formal digital system design the transformations are instead proved correct usinga proof system. This extends the set of possible transformations while increasingcon�dence in the correctness of the result. We will look at some transformationaldesign approaches in Section 2.4. Note that this classi�cation of design methodsinto formal and transformational is made by us for presentation purposes and is notgenerally used. 10

2.3.1 The Role of Formal Digital System DesignThe following is an alternative de�nition of formal digital system design to the onegiven on page 1:Formal digital system design is a technique for transforming an expres-sion in a formal language into another expression in the language byapplying rules of the calculus associated with the language. The keyidea is to create a library of transformations that implement these rules,similar to the inference rules of a logic. In this way, a design calculusfor the formal language can be created. This design calculus can thenbe used to construct more complex transformations.From the de�nitions it is obvious that formal digital system design is not a designphase but rather a design method. As such it can be applied at any level of the designhierarchy presented in Section 2.1. However, it has its greatest potential at higher-levels of the hierarchy where there currently is a lack of computational support,and its ability to handle arbitrary abstractions of time and data can be of greatestuse. We illustrate this in Figure 2.2 where we have extended the conventionalAbstra

tc

ion

Symbolic

Reasoning

Optimization

System level

High level

Register Transfer level

Logic level

Technology mapping

Formal Digital System Design

Figure 2.2: The role of formal digital system designdesign hierarchy with three orthogonal dimensions| abstraction, symbolic reasoningand optimization. We have done this because the design hierarchy model does notcontain enough information to use as a base for classi�cation of design supportsystems and techniques.Formal digital system design can perform both system and high-level design inthe design hierarchy, but it cannot perform optimization in the meaning of pruningthe design space for the best design under some constraints. This task is accom-plished well by, for example, high-level synthesis systems. On the other hand, unlikehigh-level synthesis systems, it provides us with safe symbolic reasoning about de-sign objects. Apart from that, it also supports handling of arbitrary abstractionswhich makes it possible to support re�nement of data and time during the designprocess. Hence, formal digital system design is particularly suitable for interactivedesign at early stages of the design process where the support for safe symbolicreasoning and the use of arbitrary abstractions are key features.11

2.3.2 Key PropertiesAn important property of formal digital system design is that it enforces the useof formal speci�cations in the design process. This is important since in order tobe able to write a formal speci�cation, a good understanding of the problem isnecessary. Executable formal speci�cations can be validated through execution ontypical inputs. With formal speci�cations written in, for example, HOL we canformulate properties that must hold for an implementation to be correct and toverify them against the formal speci�cation. One of the most important and atthe same time most di�cult part of formal digital system design is to write correctspeci�cations.All formal digital system design tools are based on a proof system. By enforcingthat all design steps taken in the system are proved correct in the proof systemwe can ensure that designs produced using the tool is correct with respect to itsspeci�cation.All formal digital system design tools have the possibility to document the designprocess in one way or another. The formalization of the design process that thisleads to is valuable for several reasons. First, it makes design derivations reusableobjects. Second, it supports design maintenance and design updates in a controlledmanner.By providing a set of design transformations to the designer we can both supportand control him. We support the designer by supplying a well-tuned set of transfor-mations that corresponds to `natural' design steps. This simpli�es the design taskbut does not constrain the designer in using his skills. The same mechanism can beused to control or restrict the designer. By providing a set of transformations thatcorrespond to e.g. company design rules the designer is forced to conform to theserules.2.4 Related workIn this section we present work that is related to our work. We do not cover thesubject of post-design hardware veri�cation here but point the interested readerto Section 3.10. We separate the presentation of related work into three sections.First, we present other formal design approaches and discuss them in relation toour work. Second, we present work on transformational design that is not basedon proof systems, and compare this approach to the formal (proof based) designapproach. Last, we present some work that does not �t any of the previous groupsbut still should be mentioned.2.4.1 Formal Design ApproachesIn our classi�cation, all formal design systems are based on proof systems. Hence,we present the di�erent approaches in groups according to the underlying proofsystem. 12

Burns et al. have implemented an interactive transformational synthesis systemfor digital signal processing (DSP) design in which the designer can explore thedesign space and generate a functionally correct design [13]. Correctness is guaran-teed by enforcing that all transformations in the system are veri�ed correct in theBoyer-Moore system. Brock and Hunt have used the Boyer-Moore system tobuild correct by proof circuit generators [11].Chin and Gordon have done some work using the HOL proof assistant. Chin [18]has used higher order logic and a functional language to verify design procedureswhich correctly synthesise generic arithmetic circuits. Gordon [33, 32] has used HOLand window inference for transforming Silagedescriptions.The LAMBDA proof assistant is the proof systems most widely used for designpurposes. Fourman et al. have designed the LAMBDA/DIALOG design assistant [63].It is a system similar in scope to ours but it is di�erent in implementation and inits use of a graphical schematic capture style of user-interface. Busch and Venzl usethe LAMBDA system to design digital hardware with a transformational techniquewhere parametrized retiming and constraint re�nement is formalized [14, 15]. Thederived design is parametrizable and thus describes a class of correct implementa-tions. Wang and Stabler have formalized a subset of VHDL that allows them totransform a VHDL design description into a design description in LAMBDA's func-tional speci�cation language via a state-machine model of the design [96]. Havingtranslated the design descriptions they use the LAMBDA/DIALOGsystem to synthe-sise correct implementations.VERITAS+ is a higher-order logic proof system like LAMBDA and HOL butwith a more advanced type system making possible the representation of dependenttypes. Hanna et al. has proposed a method of doing formal synthesis using thissystem [48, 47]. Their approach is based on an explorative manipulation of prooftrees in a divide and conquer style, separating the division of goals into subgoalsfrom the necessary validation for these goal-splitting activities.Constructive type theory (CTT) has also been used for system design. Suk hasdescribed a method to synthesise hardware from logical speci�cations using a CTTimplemented in the ISABELLE logical framework [90]. Basin has done similar workusing the Nuprl proof assistant [4].2.4.1.1 DiscussionOf the di�erent approaches to formal digital system design presented above we havefound the approaches of Fourman et al. and Hanna et al. to be the most relevant toour work.The approach of Hanna et al. is di�erent from ours because of the stronger typesystem of the VERITAS+ proof system. This allows them to model the design processmore directly than we have. The result of a design in their system is a design treeexplaining how the original speci�cation was split into subparts by the applicationof techniques, which are a counterpart of tactics in veri�cation. The design treetherefore work as design documentation. Using the system, proofs and design canbe performed independently of each other. Thus, when a proof of a step has been13

made, the design tree can be annotated with this information, but the designer isnot forced to prove every step as he goes along. This allows the designer the freedomto prune the design space for good solutions.The LAMBDA/DIALOG system is in many ways similar to the system imple-menting our approach. Apart from the fact that LAMBDA/DIALOG has a graphicaluser interface their functionality is similar. It is hard to tell though since the use ofthe graphical interface in published papers on the system tend to make it di�cult tosee how things are implemented. This non detailed account of the system is prob-ably intentional since the LAMBDA/DIALOG system is a commercial product. Animportant di�erence from our work is the way they model design as goal-directedproblem solving. This is not the most natural way to model design and our transfor-mation based approach is more closely corresponding to the actual process of design.Lambda solves this by allowing logical variables in the original goal and then modelsthe design process as the ongoing process of specializing these variables. Anotherdi�erence is that we can write more generic design transforms than is possible inthe LAMBDA/DIALOG system where a design transform is represented as alogicalrule. We only need one transform to introduce any standard device into the de-sign description whereas the LAMBDA/DIALOG system needs an introduction rulefor every device. On the other hand, a design transform in our system is a bitmore complex to write in comparison to rules in the LAMBDA/DIALOG system.Other advantages of our approach is the possibility to partition the design task intosubtasks but still be able to use context information in the subdesign. This is aproperty of the window inference system. The last major di�erence is our use ofdesign annotations to guide the design process and encode heuristics and designrules.2.4.2 Transformational Design ApproachesThe common denominator for the work presented here is that they all transformdesigns according to a correctness preserving algebra and that they are implementedusing special purpose transformation systems (as opposed to general purpose proofsystems). In particular there has been a lot of interest in using functional algebrasas a basis for transformational design.Johnson et al. have presented DDD, a system for mechanized digital designderivation [56]. This is used to investigate the formalization of digital system de-sign using a functional algebra. Johnson and Bose discusses the use of functionals-expressions in the Lisp dialect Scheme as a HDL for reasoning about data pathmanipulation.Another system working with a functional algebra is the TRANSE system [26].In this system Durrieu et al. manipulate a purely applicative description languagenamedCircuit-Lisp de�ned according to Boute's multiple semantics paradigm [10].Sheeran developed a variant of Backus' FP called �FP [84] which she later re�nedto a relational calculus calledRuby [58]. Both these languages are targeted towardsregular structures. There is a de�nition ofRuby in ISABELLE by Rossen [82]. Thereis also a Ruby interpreter available [54].14

Peng developed a high-level synthesis system based on correctness-preservingtransformations in an extended Petri-net formalism [79]. This has later been ex-tended by the addition of a VHDL compiler for behavioural speci�cations [27].2.4.2.1 DiscussionThere are in principle two methods to implement transformational design, eitherwithin a general-purpose formal system or with a special-purpose transformationsystem. All the systems presented above are implemented as rewriting systemswhere the rules are hard coded or given as axioms by the designer. There are severaldrawbacks to this approach and it is therefore better to use a general-purpose formalsystem such as HOL. The reasons for this are as follows:� Since HOL is programmable we can design a set of transformations suitablefor our current needs.� Since HOL guarantees consistency we do not have to worry about introducingnon valid transformations.� Whenever we come across a situation our set of transformations cannot handlewe can do the required proof manually in HOL, thus we do not get stuck aswe might in a system with a �xed set of hard-coded transformations.� Many years of e�ort and experience have already been invested in tools forclassical logic, like the HOL system. The duplication of the security and rea-soning ability of these tools for a special calculus would be a di�cult task.� Special calculus systems cannot take design steps that do not follow directlyfrom the current design description, but are more suitable for mechanizing themundane aspects of design such as structural optimizations. Thus they canonly complement proof-based tools. This is discussed by Johnson et al. in [57].It is noteworthy that the work presented in this section could just as well have beenformalized in, for example,HOL. An example of this is Gordon's work on Silage [33,32]. There he performs optimizing transformations on a purely applicative subsetof the digital signal processing language Silage. This is done in HOL using thewindow inference package.2.4.3 Other ApproachesGreenstreet and Staunstrup's work on synthesising asynchronous circuits from Syn-chronized Transistions descriptions [88] and Martin's work on synthesisingasynchronous circuits from CCS speci�cations [62] are two examples of an alterna-tive approach to formal system design. The idea behind their work is to use a formallanguage to specify the behaviour of a circuit and then compile this speci�cation di-rectly into silicon using a prede�ned library of highly optimized implementations ofthe language primitives. This approach is targeted to a speci�c design style, namely15

self-timed or asynchronous systems. It is therefore not directly comparable to ourapproach since it advocates a shift of design style.McFarland, �nally, advocates the idea of building veri�ed synthesis systems thatproduce guaranteed correct designs [65, 64]. The idea is to verify the algorithms thatimplement design transformations in high-level synthesis systems, thus making alldesigns produced by such systems correct by construction. This is a good idea but ithas some problems associated with it. First, e�cient synthesis systems tend to buildon design transformations that are implemented as very complex algorithms whichtend to be di�cult, if not impossible, to prove correct. Second, even if all designtransformations could be proved correct, the software implementation of them is notnecessarily correct. Thus, to be completely reliable, such a system would have tohave its software veri�ed and since these are often very large software packages thisis probably a research task in itself.

16

Chapter 3HOL and Hardware Veri�cation 1The work presented in this thesis is based on the HOL system [39, 34]. It is amember of the `LCF-family' of proof assistants and can have its ancestry traced backvia Cambridge LCF [78] to Edinburgh LCF [35]. It was designed and implementedby Mike Gordon. The inspiration for this came from Gordon's own experiencesof the LCF LSM system [36] where a specialized language, LSM, was developed tospecify and verify hardware within the LCF system, and from Hanna and Daeche'simplementation of the VERITAS system [46] for higher-order logic. It was originallyintended as a tool for the veri�cation of hardware, but is now used for software andprotocol veri�cation as well as pure mathematics. The acronym HOL will be usedboth for the computer system and for the logic embedded in it. Only if otherwiseambiguous will we call them the `HOL system' and the `HOL logic'.The HOL system consists of ML (an acronym for Meta-Language), a functionalprogramming language featuring strong polymorphic typing [25], in which the logic isembedded (i.e. HOL is the object language). Terms and theorems are ML datatypesand inference rules are ML functions. To prevent theorems from being constructedin ad hoc ways they are encoded as abstract data types whose only constructors arethe primitive inference rules of the logic. By ML programming however, higher levelproof procedures can be encoded as sequences of primitive inferences, thus makingthe proof task a little easier.The HOL logic is a machine-oriented formulation of Church's simple type the-ory [19] with a polymorphic type discipline inherited from LCF and mechanisms forconservative extensions of the logic by de�nitions.In this chapter we describe brie y both the system and the logic as well as itsuse in modelling and reasoning about hardware. These descriptions are accuratebut not complete. Since the subject of this thesis is the application of formal prooftools rather than the tools themselves we try to present the system from a userperspective. The material in this chapter is not new, and has already been coveredin considerably more detail elsewhere (see Section 3.10 for references). Parts of thischapter are adapted from Melham [68].1Draft-version: April 28, 1993. 17

3.1 IntroductionThe main advantage of formal proof is that every single step has a precise jus-ti�cation, thereby drastically reducing the risk of introducing errors into the proofprocess. The main disadvantage is that even proofs of trivial theorems require a largenumber of steps, making the proof process both tedious and error prone. These twostatements may seem contradictory but the essence of them can be expressed likethis. A correct formal proof gives a high degree of con�dence in the result,however, an erroneous proof, wrongly, gives the same level of con�dencein the result.From this we deduce that the success of formal proof is wholly dependent on itsbeing carried out properly. The solution to this problem is computer-assisted formalproof.Computers can cope both with the complexity and the necessary rigour of doinglarge formal proofs. There are di�erent kinds of computer programs to assist aproof:� Proof checker;� Proof assistant;� Automatic theorem prover.A proof checker checks that every step of the proof is correct whereas a proof as-sistant assists in the actual performing of the proof. An automatic theorem prover,as the name suggests, performs the proof itself returning yes or no. The distinctionbetween proof assistants and automatic theorem provers is somewhat blurred by thefact that large parts of proofs, e.g. tautology checking, can be automated in proofassistants and the fact that automatic theorem provers need guidance to be able todeal with complicated proofs.The main bonus of working with a higher-order logic is that speci�cations becomeboth compact and readable while at the same time it is possible to express everythingnecessary to reason formally about hardware at di�erent levels of abstraction. Thedisadvantage is that with increased expressive power, less can be automated. Thus,HOL is a proof assistant, not an automatic theorem prover.Interaction with HOL is through the ML metalanguage in which the logic isembedded. ML has a strong type discipline which helps enforce consistency. The factthat ML is a complete programming language in which the logic is embedded lets theuser write proofs and proof-procedures in a familiar programming-like style. ML isan ancestor of the more widely distributed general purpose programming language,Standard ML [71], primarily lacking the latter's pattern matching capability andsupport for programming in the large. 18

3.2 TermsThere is no syntactic class for formulas. Their role is played by boolean terms.There are only four di�erent kinds of terms in HOL: variables, constants, functionapplications and lambda abstractions. In practice however, this conciseness is hiddenfrom the user by the possibility to de�ne new syntactic constructs from the basicones. HOL also allows us to de�ne special syntactic forms, e.g. in�xes, in orderto make expressions easier to read. Because of these de�nitional capabilities, the`user-level' syntax varies with the number of constructs and special forms de�nedat any one time. The constructs available in the `standard' HOL system can beseen in Table 3.1 where x ; y and z denote arbitrary variables, t ; t1 and t2 arbitraryterms, b a boolean term, and f a lambda abstraction or a function valued constantor variable. The logic uses standard predicate logic notation. For example the termvariables x; y; z; : : :constants T;F;0;1;2; : : :negation :tconjunction t1 ^ t2disjunction t1 _ t2implication t1 ) t2equality t1 � t2universal quanti�cation 8x:texistential quanti�cation 9x:tfunction application f tpair t1; t2lambda expression �x:tepsilon expression "x:tconditional b! t1 j t2let expression let x = t1 in t2Table 3.1: User-level syntax of HOL`P x ' is interpreted as saying that x has property P, and the term `R(x ; y)' meansthat the relation R holds between x and y. The logical connectives, :;^;_;� and), and the logical quanti�ers, 8 and 9, all have their usual meanings. On theother hand, epsilon expressions are not present in most formulations of logic. Theprimitive constant " is a quanti�er like 8 and 9, and is often referred to as `choice'.It is a higher-order version of Hilbert's "-operator2. Informally, if t is a term of type�!: bool, then "x : t x denotes some member of the set whose characteristic functionis t . If the set is empty, then "x : t x denotes an arbitrary member of the set denotedby �.2See Church's original paper [19]. 19

3.3 TypesHigher-order logic is a typed logic, i.e. every term of the logic has an associatedlogical type which represents the kind of value it denotes. A term is considered tobe well-formed only if its type is consistent with the types of its subterms. Typesprevent inconsistencies such as Russell's paradox by ensuring that every properlytyped subterm avoids such paradoxes. There are three kinds of types in HOL:� type constants;� compound types;� type variables.Type constants are identi�ers that denote �xed sets of values. Examples of built-intype constants are:� :bool, the boolean values T;F;� :num, the natural numbers 0;1;2; :::;� :tok, the string tokens, e.g. `a',`ab',`abc',....Compound types are built up from existing types using type constructors. Examplesof built-in type constructors are:� product, ty1 � ty2 ;� function, ty1 ! ty2� list, (ty)listType variables are identi�ers that stands for arbitrary types. Any type which in-volves a type variable is called a polymorphic type. They are written �; �; ; etc. .Terms are represented by the ML type term. HOL requires all variables andconstants in a term to be assigned a type. If type information is omitted, HOLuses a type inference algorithm to infer type information from the context. Forexample, it can infer that the variable b is a boolean value when it appears in theterm :b. When the type of a term is ambiguous, its type can be indicated by atype annotation. The expression b: bool indicates that the variable b is a booleanvariable.Once types have been unambiguously associated with every primitive subterm,the type of the whole term can be derived hierarchically from the types of thesubterms according to type deduction rules associated with each type constructor.This process is called type checking or type deduction and is decidable for the HOLlogic which means that it can be performed automatically by HOL.20

3.4 Theories and De�nitionsA theory in the HOL logic is a set of constants, types and theorems. It is di�erentfrom a mathematical theory in that it includes only the theorems that have beenproved as opposed to all theorems that could be proved in the theory. Theories canbe organized into hierarchies where they inherit de�nitions from their ancestors.There is a basic theory in the HOL logic which incorporates the built-in theories.New theories that are created will have the basic theory as ancestor and will thereforeinherit all de�nitions from the built-in theories. New constants can be introduced ifthey are not present in the theory or in any of its ancestors, thus constants have tobe unique within a hierarchy of theories.The logic can be extended with new constants and types without having topostulate ad hoc axioms in order to give meaning to the new notation. This is doneby giving a de�nitional axiom when the new de�nition is introduced. The restrictedform of a de�nitional axiom guarantees that this is a conservative extension of thelogic. This means that it does not introduce any new inconsistencies into the logic. Atheory containing only de�nitions is called a de�nitional theory. All built-in theoriesin HOL are de�nitional. Syntactically, the most common form of a de�nition is:fx1 : : : xn � tWhere f is declared to be a new constant satisfying the equation and t is a termwhose free variables are included in the set x1 ; : : : ; xn . All type variables on theright-hand side must appear on the left-hand side. We use � to denote a de�nition.The notion of a theory in the HOL system extends the logical notion by func-tioning as a database where theorems derived during a HOL session can be storedfor future use.Apart from a number of built-in theories the HOL system comes equipped with alibrary of assorted theories to be used as required. Examples of built-in theories arebooleans, numbers, lists and pairs. In the library we �nd, among others, theoriesfor sets, strings and tautologies.3.5 Sequents, Theorems and ProofsThe style of proof supported in the HOL logic is natural deduction. Assertions in thelogic are not individual formulas (i.e. boolean terms), but are sequents of the form(�; t), where � is a set of formulas called the assumptions and t a formula called theconclusion. A sequent (�; t) asserts that if all the formulas in � are true, then so ist. A theorem is a sequent that has a proof , i.e. is an axiom or follows from othertheorems by a rule of inference.Rules of inference look much like theorems but are denoted by lines instead ofturnstiles as illustrated by the rule shown below.�1 ` t1 ) t2 �2 ` t1�1 [ �2 ` t2 MODUS PONENS21

This rule states that from the two formulas t1 ) t2 and t1 one can immediatelyinfer the formula t2 by modus ponens. In this formulation of higher-order logic theassumptions under which a rule holds are explicit.A proof is a sequence of such lines where every line is either an axiom or canbe obtained from a previous line by a rule of inference. A proof from hypothesesth1 ; : : : ; thn is a sequence each of whose elements is either an axiom, one of thehypotheses thi , or follows from earlier elements by a rule of inference. For example,a proof of �; t 0 ` t from � ` t can be written:� ` t� ` t 0 ) t t 0 ` t 0�; t 0 ` tWhere the lines represent the following primitive inference rules: Discharging anassumption; Assumption introduction; and Modus ponens.This proof works for any hypothesis of the form � ` t and any boolean term t 0and shows that the result of adding an arbitrary assumption to a theorem is anothertheorem.To guarantee that the only way to get theorems is by proof, the HOL systemdistinguishes sequents from theorems by having a separate ML type thm. There are�ve initial theorems corresponding to the �ve axioms of the HOL logic. The only wayto generate other objects with ML type thm is by using one of the eight primitiveinference rules of the logic. The type discipline of ML ensures that inference rulescan be applied only to theorems.3.6 Security and ExtensibilityWith the HOL system the user has direct control over proof-generation down to thelevel of primitive inference steps. Most often, the user guides proof-generation at amuch higher level using derived rules and transformations. However, when built-inproof support is not enough, the user has a complete programming language, ML, inwhich to implement new proof-procedures. The type discipline of ML ensures thatno matter how ad hoc and complicated the procedure is, it is impossible to prove aninvalid theorem. This means that:� all theorems have proofs;� any user can implement new proof-procedures without danger of compromisingproof security.The fact that HOL is an open system that is programmed in the same language theuser uses to interact with the system, means that new theories and proof-proceduresare made available to the user community by the user community, thus making thesystem grow and mature constantly much in the same way other open systems, suchas EMACS, do. 22

3.7 Proof Styles and ToolsAll proofs in HOL are forward proofs, i.e. they are constructed from the axioms,using the rules of inference, until the desired theorem is deduced. Since interestingtheorems require large numbers of applications of the primitive inference rules fortheir proofs, the HOL system provides tools to help manage such proofs. For sup-porting forward proofs there are derived inference rules. These are ML functionswhich apply sequences of primitive inferences. There are however situations whereforward proofs are not ideal. For this reason two other styles of reasoning have beenincorporated in HOL; goal-directed and transformational.The goal-directed or backward proof style starts with a formula representing thegoal one wants to prove and then reduces this to subgoals, sub-subgoals etc. untilthe problem is decomposed into trivial goals, e.g. instances of axioms. The basictool for supporting goal-directed proof is the subgoal package. It allows proofs to begenerated in a goal-oriented style using tactics.In the transformational proof style we start with an expression which we trans-form into a new expression by applying correct transforms to it. We iterate thisprocess until the expression is on the desired form. A tool that supports this kindof reasoning is the window inference package. In window inference we can transforman expression or, restrict attention to a subexpression and transform it withouta�ecting the rest of the expression.3.7.1 Derived Inference RulesA derived rule is an ML procedure that generates a proof from given hypotheses eachtime it is invoked. The hypotheses are the arguments of the rule. To illustrate thiswe will de�ne the `added assumptions' proof carried out in Section 3.5 as a derivedrule called ADD_ASSUM. In standard notation this would be described as:� ` t�; t 0 ` t ADD_ASSUMThe de�nition of this proof as a derived inference rule could look like this:let ADD_ASSUM t th = MP (DISCH t th) (ASSUME t);;Where MP, DISCH and ASSUME are theML names of the primitive inference rules used,t is the assumption to be added and th is the theorem to which the assumption isadded.The HOL system has all the standard introduction and elimination rules of Pred-icate Calculus prede�ned as derived inference rules. It is these, rather than theprimitive inference rules, that one normally uses.3.7.1.1 Rewriting and Tautology CheckingIn addition to the standard rules there are some special rules that do a limitedamount of automatic theorem proving. 23

One such rule is REWRITE_RULE. It takes a list of conjunctions of equations, i.e. alist of the form: �1 ` (u1 = v1 ) ^ (u2 = v2 ) ^ : : : ^ (un = vn)The other argument is a theorem �2 ` t . REWRITE_RULE repeatedly replaces instancesof ui in t by the corresponding instances of vi until no further change occurs. Theresult is a theorem �1[�2 ` t 0 where t 0 is the result of rewriting t in this way. Thereare many other rewrite rules available in the system as well as facilities for writingcustomized rules.Another example of a special rule is TAUT_RULE, a tautology checker. It takes aboolean term t and returns ` t if t is an instance of a tautology of the propositionalcalculus.As we can see, derived inference rules can be very powerful proof generationtools.3.7.2 Subgoal PackageThe process of veri�cation is most often conducted by goal-oriented or backwardproof. It starts with stating correctness (according to some approach) as a goal,and progresses by rewriting the goal or splitting it into subgoals with tactics. Thisprocess continues until all subgoals are proven at which time the original goal hasbeen proved. A tactic applied to a goal produces either a proof or a number ofsubgoals and a validation function saying how the original goal can be achievedfrom the subgoals.Prooftrees Repeated splitting of goals into subgoals builds a prooftree of thekind depicted in Figure 3.1 where the nodes are goals and the original goal is theroot. As the tree is constructed using tactics we annotate the tree with validations.When all the subgoals of a node are achieved the validation attached to it is usedto achieve the goal. We can see the same prooftree as before after goal D2 has beenachieved in Figure 3.2.There are interactive functions in the subgoal package for creating a goal, ap-plying a tactic to a goal, undoing an application and choosing which subgoal tosolve next. There are also batch-oriented functions for proving theorems in thegoal-oriented style.3.7.2.1 Tactics and TacticalsTactics are speci�ed using the following notation:goalgoal1 goal2 : : : goaln TACTICWhere goal is the initial goal, goali is a subgoal which we have to solve in order tosolve goal and `TACTIC' is the name of the tactic. To give the reader a feeling ofwhat tactics can look like we present a few built-in tactics here:24

C1

D1

C2

D1 = An achived goal

D2 = An outstanding goal

Val = A validation function

A

B1

C3

B2

D2

Val

Val

Val

Figure 3.1: A prooftreeValA

B1 B2Figure 3.2: A collapsed prooftree� CONJ_TAC, splits a conjunctive goal, t1 ^ t2, into two subgoals, t1 and t2;t1 ^ t2t1 t2 CONJ_TAC� EQ_TAC, splits an equational goal between boolean terms, t1 = t2, into twoimplications, t1 ) t2 and t2 ) t1;t1 = t2t1 ) t2 t2 ) t1 EQ_TAC� DISCH_TAC, moves the antecedent of an implicative goal into the assumptions;t1 ) t2ft1gt2 DISCH_TAC25

� GEN_TAC, strips o� one universal quanti�er3;8v:t[v]t[v0] GEN_TAC� INDUCT_TAC, does mathematical induction on the natural numbers.8n:t[n]t[0] ft[n]g t[Sucn] INDUCT_TACWe can build new tactics by combining existing tactics with the help of specialfunctions called tacticals. Examples of tacticals are:� THEN, takes two tactics, T1 and T2, and returns a tactic which �rst applies T1and then applies T2 to all the subgoals of T1;� THENL, takes a tactic, T , and tactic list, [T1; :::;Tn], and returns a tactic which�rst applies T and then applies Ti to the ith subgoal produced by T ;� ORELSE, takes two tactics, T1 and T2, and returns a tactic which applies T1unless that fails, in which case it applies T2;� REPEAT, takes a tactic and repeatedly applies it until it fails.3.7.3 Window InferenceWindow inference is a style of reasoning where the user may transform an expressionor restrict attention to a subexpression and transform it. While restricting attentionto a subexpression the user can transform the subexpression without a�ecting therest of the expression. While transforming a subexpression, the user can makeassumptions based on the context of the subexpression. For example, suppose auser wishes to transform the expression A ^B; this may be done by transforming Aunder the assumption B. It is legitimate to assume B while transforming A, becauseif B is false, the enclosing expression A ^B is false regardless of A.Within a window inference system, reasoning is conducted with a stack of win-dows. Each window has a focus, F , which is the expression to be transformed; a setof formulae �, called the assumptions, which can be assumed in the context of thewindow; and a relation R, that must relate the focus and the expression to which itis transformed. All relations used with the systemmust be preorders4. The notationused for denoting windows will be as follows:! �R ? F3The notation E[e] denotes the substitution of e for some distinguished free occurrence of asubexpression within E.4A preorder is a relation that is both re exive and transitive.26

The focus is not restricted to being an expression of boolean type.Each window holds a theorem which relates the current focus of the window tothe original focus of the window. Examples of these theorems will appear throughoutthe text beside the windows that hold them.3.7.3.1 Creating a Window StackTo begin reasoning with a window inference system the user creates a window stack.Creating a window stack to transform an expression F0 under the assumptions �,while preserving the relation R, results in the stack containing the single windowdepicted below:! �R ? F0 theorem:� ` F0 R F0The window initially holds the theorem that F0 is related to itself.The command used for creating a window stack is BEGIN STACK with the argu-ments: a name, a re�nement relation, R ; an initial focus, F0 ; a list of initialassumptions, � ; and a list of theorems. To kill a stack do END STACK with stackname as the argument.3.7.3.2 Transforming a WindowConsider the window below:! �R ? Fn theorem:� ` Fn R F0A transformation of the focus of a window from Fn to Fn+1 must be justi�ed by atheorem of the following form: � ` Fn+1 R FnWhere � is some subset of the assumptions of the window. We combine this theoremwith the one held by the window, using the fact that R is transitive we can showthat the new focus, Fn+1, is related to the original focus, F0, that the focus can betransformed, and that doing so results in the following window:! �R ? Fn+1 theorem:� ` Fn+1 R F0We may use any of the existing tools in the HOL system to derive the theoremrequired to justify a transformation. Because HOL is programmable users can writefunctions that automate common transformations, like rewriting, and the proofsthat justify them.There are several commands available for transforming the focus of a window.The basic one, taking an implicative theorem, is TRANSFORM WIN. To make life easieradditional commands are provided for transforming the focus of a window in speci�cways, such as repeated rewriting with a list of theorems and automatic tautologychecking. There are also commands available for applying rules and tactics to thefocus of a window. 27

3.7.3.3 SubwindowsThe opening and closing of subwindows is controlled by special inference rules calledwindow rules. Opening a subwindow pushes a new window onto the stack. Thecomponents of the subwindow are extracted from the relevant window rule. Closingthe subwindow pops the top window from the stack and uses the theorem it held toinfer, using the window rule, how to transform the window below it on the stack.To illustrate this, consider that all windows have the following form5.! �R ? F [f ] theorem:� ` F [f ] R F0We choose to open a subwindow on the expression, f . The resulting window, whichis pushed onto the stack, appears below:! �! r ? f theorem: ;� ` f r fWhere is the set of assumptions which, in addition to �, hold in the subwindow andr is the relation preserved by the subwindow. We can now transform the subwindowas shown in Section 3.7.3.2 and using the theorems held by the subwindow and theparent window, an appropriate instance of the window rule, and the transitivity ofR; an inference justifying the closing of the subwindow is built and the subwindowis popped from the stack. The parent window is then transformed to the following:! �R ? F [f 0] theorem:� ` F [f 0] R F0The commands for opening and closing subwindows are OPEN WIN with an argu-ment giving the path to the chosen subexpression and CLOSE WIN.3.8 Hardware Speci�cation and ModelsThe expressive power of higher order logic permits hardware to be speci�ed directlyin logic, thus a specialized notation is not necessary. The de�nitional mechanism de-scribed in Section 3.6 allows special-purpose notation for hardware to be introducedas a conservative extension of the logic, i.e. without endangering consistency. Thismakes it possible to de�ne new hardware models as well as embed other formalismsin the logic [8].3.8.1 Hardware Speci�cationThe approach to hardware speci�cation presented in this section is due to Gor-don [38] and Hanna and Daeche [46]. The basic idea is to specify the behaviour of5The notation E[e] denotes the substitution of e for some distinguished free occurrence of asubexpression within E. 28

a hardware device by stating which combinations of values can be observed on itsexternal variables. Such a speci�cation is expressed formally in logic by a booleanvalued term with free variables that correspond to the external variables. The termimposes a constraint on the values of these free variables.Consider for example the device Dev shown in �g 3.3 with m+n external vari-ables. A speci�cation in logic of the behaviour of this device is a boolean-valued...

...a m

a 3

a 2

a 1 b1

b2

b3

bn

DEV

Figure 3.3: A device Devterm of the form dev [a1 ; : : : ; am ; b1 ; : : : ; bn ]. To re ect the behaviour of the deviceit speci�es, the term must be constructed so that it holds for all values of the freevariables that could occur simultaneously at the variables of the device itself.In this approach a speci�cation treats a device as a black box, i.e. the behaviourof a device is de�ned only in terms of the values that can be observed externally.Furthermore, there is no distinction between inputs and outputs of a device. Thismeans that the constraint imposed on a device by a speci�cation need not be a func-tional one. This in turn means that signals can be bidirectional and speci�cationspartial.A partial speci�cation does not specify the behaviour of a device in full detail.Being able to write such speci�cations is essential if we are to be able to apply formalmethods to large or complex devices. Speci�cations of such devices otherwise tendto become too complex. Another situation in which the ability to write partialspeci�cations is essential is when a device is to be used only in an environment inwhich the combinations of possible input values are restricted. In such cases it isunnecessary to specify the behaviour for all input values.3.8.1.1 Abbreviating Speci�cationsThe possibility of de�ning new constants in HOL provides a formal mechanism forabbreviating hardware speci�cations. As we have seen, a speci�cation is just aboolean-valued term with free variables. An abbreviation for this kind of term canbe introduced by de�ning a constant to name the constraint it imposes on thesevariables.For example, the speci�cation of the device in Figure 3.3 can be abbreviated bythe predicate Dev which is de�ned formally by:` Dev(a1 ; : : : ; am ; b1 ; : : : ; bn) � tm[a1 ; : : : ; am ; b1 ; : : : ; bn ]29

This introduces a new predicate constant Dev into the logic and makes the log-ical term Dev(a1 ; : : : ; am; b1 ; : : : ; bn) an abbreviation for the device speci�cationtm[a1 ; : : : ; am; b1 ; : : : ; bn ]. The constant Dev constitutes a name for a class ofdevices, each of which exhibits the same behaviour as the others but has di�er-ently labelled external variables. An instance of this class of devices is speci�edby applying it to an appropriate (m+n)-tuple of variables. For example, the termDev(x1 ; : : : ; xm ; y1 ; : : : ; yn) speci�es a device with external variables x1 ; : : : ; xm andy1 ; : : : ; yn.An alternative way of abbreviating the term tm[a1 ; : : : ; am ; b1 ; : : : ; bn ] is by in-troducing the de�ning equation:` Dev a1 a2 : : : b(n � 1 ) bn � tm[a1 ; : : : ; am ; b1 ; : : : ; bn ]This makes the constantDev curried , i.e. applicable to one argument at a time. Theadvantage of this is that we can partially instantiate ,or specialize, predicates. Thisis particularly useful for generic devices. Even though Dev strictly speaking is nota predicate we will not make a distinction between curried an uncurried constantsbut refer to both kinds as predicates.3.8.1.2 Combinational BehaviourWhen we specify the purely combinational behaviour of hardware devices we canignore the fact that the behaviour can change over time and use a static model. Anexample is the speci�cation of an exclusive-or gate below.` Xor(i1 ; i2 ; o) � (o = :(i1 = i2 ))Here we use the boolean values T and F to represent the two logic levels `true' and`false', and the variables i1 ; i2 and o to range over these two values.The term Xor(i1 ; i2 ; o) constrains the behaviour so that the output o is trueexactly when either i1 or i2 is true but not both. In this case the output is justa function of the inputs and the full generality of the relational approach is notused. There are however cases where this generality is needed as we shall see inSection 3.8.2.Relational speci�cations can sometimes be ambiguous. If we look at the ex-clusive-or gate de�ned above we see that the purely logical properties of the termXor(i1 ; i2 ; o) allows us to interpret it as a device with inputs i1 and o and output i2 .This is partly because we do not distinguish between inputs and outputs, and partlybecause we lack a causal relationship between inputs and outputs. The problem isthat for describing such a relationship we need a more elaborate model of behaviour.3.8.1.3 Sequential BehaviourA sequential behaviour states current or future observations on each output in termsof current observations on inputs. Signal values may vary over time so we modelthem as functions of time, thus we express the signal value on variable p at time t30

by p t . We have a discrete view of time so we model time with the natural numbers.Using this notation, here is the speci�cation the exclusive-or gate from last section:` Xor(i1 ; i2 ; o) � (8t : o t = :(i1 t = i2 t))Using this speci�cation style we can model sequential devices by simply delaying theincoming signal by the appropriate number of time units. Here is the speci�cationof a unit-delay gate with two external variables:` Del(in; out) � (8t : out(t + 1 ) = in t)This states that for all values of t (0 ; 1 ; 2 ; : : :), the signal value on out at time t + 1equals that on the input at time t. Note that the output of this device is not de�nedat time zero.3.8.1.4 Composite BehaviourSo far our devices have all been single components, but a device can also be compos-ite, i.e. a device consisting of single components connected together. To be able toreason about such devices we must have a way of deducing their composite behaviourfrom the behaviour of each subcomponent. We call this process composition.When we model behaviour as logical terms imposing constraints on the design,we can model composition as conjunction of terms. Thus, we get the constraints onthe design by two composed devices by conjoining their predicates. Connection ismodelled by using identically-labelled variables.For example, suppose that the two devices D1 and D2 are speci�ed by theterms tm1 [a; x ] and tm2 [x ; b] respectively, as shown in Figure 3.4. The two termsD1 xa x bD2Figure 3.4: tm1 [a; x ] and tm2 [x ; b]describe the values that can be observed independently on the external variables ofthe respective devices. If these two devices are connected together by the variable x ,the values that can be observed on the external variables of the resulting compositedevice are just those that can be observed simultaneously on the variables of both itscomponents. A model of the resulting behaviour is given by the conjunction of theterms which specify these components. The result, which can be seen in Figure 3.5,is a term with three free variables that constrains the values on the variables of thecomposite device to be exactly those allowed by the constraints imposed by bothtm1 [a; x ] and tm2 [x ; b].A model constructed by composition may have free variables that are internalto the device. We must be able to somehow separate these internal variables fromthe externally available variables. We call this hiding and we model it in logic byexistentially quantifying the variables that are to be internal.31

D1a bD2xFigure 3.5: tm1 [a; x ] ^ tm2 [x ; b]Consider for example the composite device in Figure 3.5. Suppose that thevariable x is internal to this device. We would model this by existentially quantifyingx and getting the term shown in Figure 3.6. The result is a term where only variables

D1a bD2xFigure 3.6: 9x : tm1 [a; x ] ^ tm2 [x ; b]a and b are free and variable x is bound. This term expresses the fact that two valuesa and b can be observed externally exactly when there exists some value x such thatthe constraints for the components of the device are satis�ed.3.8.2 Two Transistor ModelsA speci�cation constructed by the methods described in Section 3.8.1 is called amodel of the device it describes. For example, in Section 3.8.1 we de�ned twodistinct models of an exclusive-or gate Xor(i1 ; i2 ; o), one combinational and onesequential. Such models are intended to re ect at least some aspects of how thedevice really behaves.A collection of such speci�cations describing the primitive components used in aparticular hardware design style or method can also be called a model. For example,a collection of speci�cations for the primitive components used in building CMOSdevices will be called a CMOS transistor model. Such a model consists of a particularchoice of speci�cations for the primitive components used in all CMOS designs,so that the behaviour of a particular CMOS device can be described by a termconstructed from the primitive components of the CMOS transistor model.We will use the term `model' or `hardware model' to stand for both of the mean-ings de�ned above. Only if otherwise ambiguous will we call the former `devicemodel' and the latter `design model'.Perhaps the most important decision when using formal methods is which hard-ware model to use since this decides how well important aspects of the real designare captured in the formal proof. In order to illustrate the importance of de�ningappropriate models for the task in hand, we will now look more closely at two dis-tinct CMOS transistor models, a simple switch model and a more accurate thresholdmodel. The primitive hardware components in a CMOS transistor model are shown32

l

h

s

d

g

s

d

gFigure 3.7: CMOS componentsin Figure 3.7. Note also that both these models take full advantage of the factthat signals can be bidirectional. The relation between drain d and source s has nodirection of signal ow speci�ed in either case.3.8.2.1 A Switch ModelIn the switch model we represent signal values by a boolean type so that logic levelhigh is represented by T and logic level low by F. We specify the behaviour ofthe primitive components of the model with this type as basis. The result is shownbelow.` Pwr h � (h = T)` Gnd l � (l = F)` Ntran(g; s; d) � (g ) (d = s))` Ptran(g; s; d) � (:g ) (d = s))The speci�cationsPwr h andGnd l model `Power' and `Ground' as constant sourcesof the logic levels high and low respectively. The speci�cations Ntran(i1 ; i2 ; o) andPtran(i1 ; i2 ; o) model N-type and P-type transistors as ideal switches controlledby the boolean value present at their gates.Although this simple model of transistor behaviour can be useful for some pur-poses, it has some important shortcomings in the way it captures many aspects ofthe behaviour of real CMOS devices. One such aspect is the fact that CMOS tran-sistors do not transmit both logic levels equally well. This is however not re ectedin our model. This simpli�cation makes it possible to prove, using the switch model,the correctness of certain CMOS circuits that do not work in practice.3.8.2.2 A Threshold ModelOne of the basic problems with the switch model is that it speci�es the behaviourof transistors using a logical type with only two values. This is a very simple modelwhere the value on every variable of a device must be either high or low . It isnot possible to model other `degraded' logic levels. To be able to do this we needto model signals with a type with more than two values. The simplest solution is33

to de�ne a logical type with exactly three distinct values. We use the de�nitionalpackage of HOL to de�ne such a type : tri shown below.tri ::= Hi j Lo j XOnce the type : tri has been de�ned, we can use it as the basis for a more accuratetransistor model that, at least partly, captures the threshold switching behaviour ofreal CMOS devices. The basic idea of this model is to represent the strongly-drivenlogic levels high and low by the values Hi and Lo, and to represent all degradedlevels with the value X. The formal speci�cation of the threshold switching modelof CMOS transistor behaviour can be seen below.` Pwr h � (h = Hi)` Gnd l � (l = Lo)` Ntran(g; s; d) � ((g = Hi)) ((d = Lo) = (s = Lo)))` Ptran(g; s; d) � ((g = Lo)) ((d = Hi) = (s = Hi)))As in the switch model, the speci�cations Pwr l and Gnd h model `Power' and`Ground' as constant sources of the strongly-driven logic levels high and low . Thespeci�cations Ntran(g; s; d) and Ptran(g; s; d) however have changed. They nowre ect the fact that these devices do not transmit both logic levels equally well. Forexample, it follows from the speci�cation of an N-type transistor that when the gateg has the value Hi and the source s has the value Lo, then the drain d must alsohave the value Lo. This re ects the fact that an N-type transistor transmits thelogic level represented by Lo unchanged. On the other hand when both g and shave the value Hi, then the value on d can be either Hi or X. This re ects the factthat an N-type transistor may degrade the value Hi to X during transmission.3.9 Veri�cationIn this section we will look at the two main parts of doing veri�cation; statingcorrectness and carrying out a proof.3.9.1 Stating CorrectnessIn order to verify something we must �rst de�ne what we mean by correctness.In a formal system, correctness is expressed as a relation between two terms, onerepresenting the speci�ed required behaviour and the other representing the designedbehaviour. This relation tells us in what way the designed behaviour D[v1 ; : : : ; vn ]satis�es the speci�ed behaviour S[v1 ; : : : ; vn ]. The most direct way of formulatingthis satisfaction relationship is by logical equivalence. With this formulation, thecorrectness of a hardware design is asserted by a theorem of the following form:` D[v1 ; : : : ; vn ] = S[v1 ; : : : ; vn ]34

This theorem states that the truth-values denoted by these two terms are the samefor any assignment of values to the free variables v1 ; : : : ; vn . This clearly meansthat the design is correct with respect to its speci�cation, since their respectivebehaviours are identical.Using equivalence as correctness relation is appropriate only for simple hardwaredesigns. For more complex devices, it is impractical to formulate correctness thisway. The problem is that if correctness is formulated by equivalence then the speci�-cation S[v1 ; : : : ; vn ] must denote the same constraint on the free variables v1 ; : : : ; vnas the design D[v1 ; : : : ; vn ] does. This means that if the design to be veri�ed is largeor complex then the speci�cation is likely to be large and complex as well. Thus thecorrectness of the speci�cation may be no more obvious than the correctness of thedesign itself.3.9.1.1 AbstractionFor the speci�cation of a complex device to be intelligible to the designer, it mustgenerally be limited to a more abstract view of its behaviour than is given in thedesign itself. The relationship of satisfaction should therefore be one of abstractionrather than of equivalence.Having an abstraction relationship of satisfaction means that the two behavioursto be related are expressed at di�erent levels of abstraction, where the speci�cationis expressed at a higher, less detailed, level than the design. A more abstract spec-i�cation thus imposes a less restrictive constraint on the free variables than thedesign. This abstraction relationship can be formulated by logical implication. Thecorrectness of a hardware design can then be asserted by a theorem of the followingform: ` D[v1 ; : : : ; vn ]) S[v1 ; : : : ; vn ]This theorem states that any combination of values which satis�es the constraintimposed by the design also satis�es the constraint imposed by the more abstractspeci�cation. By stating correctness this way we say that the implementation mustimpose at least the requirements of the speci�cation. Note that it can also imposeother constraints not required by the speci�cation.3.9.1.2 Problems with AbstractionThere are two problems that can arise when we formulate correctness by implication.The �rst one is under speci�cation. That is when we inadvertently fail to specifysome important aspect of the device's intended behaviour. This is possibly to dosince the speci�cations can be partial.Whenever it is possible to leave something unspeci�ed, it is also possibleto leave something essential unspeci�ed. [Melham in [68]]The other problem is that an inconsistent model trivially satis�es any speci�cation6.An inconsistent model is one which cannot be satis�ed by any assignment of values6This is sometimes referred to as the `false implies anything' problem.35

to the free variables. An example would be a term describing a short-circuit betweenpower and ground, i.e. (F = T)) Spec, which is true since all inconsistent modelssatis�es any speci�cation. This is unsatisfactory, since a formal theorem of this kinddoes not imply functional correctness. In the sequel, we will call this undesirableproperty of implication as satisfaction relation partial correctness.The ideal solution would be to have a hardware model that guaranteed that alldesigns built with it had a consistent model. This could mean though, that thehardware model would have to be very complex and thus, hard to reason with.Another approach is to check the consistency of the design that the proof isbased on. This can be done by proving a consistency theorem of the form:` 9v1 ; : : : ; vn :D[v1 ; : : : ; vn ]Proving this additional theorem ensures that this device does not satisfy a speci�-cation merely because it has an inconsistent model.A third approach, proposed in [97], is to divide the speci�cation into environmen-tal E[v1 ; : : : ; vn ] and behavioural S[v1 ; : : : ; vn ]constraints. The veri�cation conditioncould then be a theorem of the form:` E[v1 ; : : : ; vn ]) (D[v1 ; : : : ; vn ] = S[v1 ; : : : ; vn ])This allows much of the exibility of the correctness by implication approach withoutmany of its drawbacks.Yet another solution, suggested by Fourman [29], would be to only allow directeddevices and use extralogical design rules to ensure the implementation is physicallyrealizable.3.9.2 An Example Correctness ProofIn this section, a very simple proof of correctness is given in order to illustrate theapproach to veri�cation introduced in the last section. The design to be veri�ed isthat of an inverter circuit, designed using the simple switch CMOS transistor modelde�ned in Section 3.8.2.1. The theorem we will prove is the following:` Inv(i ; o) = Not(i ; o)This theorem states that the behaviour of a designed inverter circuit Not(i ; o)is equal to the behaviour of the speci�cation Inv(i ; o) of such a circuit. We uselogical equivalence as our satisfaction relation since the size of the design is suchthat behavioural abstraction is not necessary.The speci�cation of the required combinational behaviour of an inverter is givenby the term Not(i ; o) de�ned below.` Not(i ; o) � (o = :i)This speci�cation states that the boolean value on the output o must be the negationof the value on input i . 36

i

p

g

o` Inv(i ; o) � 9g p:Pwr p ^Gnd g ^Ntran(i ; g; o) ^Ptran(i ; p; o)Figure 3.8: A formal model of a CMOS inverterThe design of the inverter circuit from the primitive components of the switchCMOS transistor model and the two operations of composition and hiding is shownin Figure 3.8. This speci�cation states that the term Inv(i ; o) is satis�ed preciselywhen the values on the input i and the output o satisfy the constraint imposed bythe speci�cations of the parts used in the design, for some values on the internalvariables p and g .3.9.2.1 Outline of the ProofThe proof would normally be carried out using one of the proof tools introduced inSection 3.7. But since even very small proofs like this one require a large numberof steps, we instead go through it manually, just pointing out the essential steps inthe proof.1. Expand the constant Inv with its de�nition:` Inv(i ; o) = 9g p:Pwr p ^Gnd g ^Ntran(i ; g; o) ^Ptran(i ; p; o)2. Expand Pwr;Gnd;Ntran and Ptran in the same way:` Inv(i ; o) = 9g p: (p = T) ^ (g = F) ^ (i ) (o = g)) ^ (:i ) (o = p))3. By the meta-theorem ` (9v : v = tm ^ t [v ]) = t [tm=v ] this is equivalent to:` Inv(i ; o) = (i ) (o = F)) ^ (:i ) (o = T))4. Simplifying using the laws ` (o = F) = :o and ` (o = T) = o gives:` Inv(i ; o) = (i ) :o) ^ (:i ) o)5. Replacing i ) :o by its contrapositive o ) :i yields:` Inv(i ; o) = (o ) :i) ^ (:i ) o)6. By the de�nition of boolean equality, this is equivalent to:` Inv(i ; o) = (o = :i)7. Abbreviating the right hand side with the de�nition of Not gives:37

` Inv(i ; o) = Not(i ; o)This example, although trivial in itself, illustrates some typical procedures that arepresent in many `real' proofs carried out in HOL. Examples are expanding withde�nitions, elimination of existentially quanti�ed variables and rewriting with pre-de�ned logical `laws'.3.10 Further ReadingThe complete guide to HOL is the documentation [85] which is extensive and read-able. Among other things it contains a tutorial introduction with step-by-step in-structions to help users get started. There is also an introductory book on HOLedited by Gordon and Melham [34] and a shorter introduction to the HOL systemby Gordon [39]. More on LCF, goal-oriented reasoning and tactics can be found ina book by Paulson [78]. Staples et al. has written about window inference in gen-eral [86], and Grundy has written about the implementation in higher-order logic [41]and about its use for software re�nement [42]. Gordon has written a good intro-duction to using HOL for hardware veri�cation [38]. Cohn [23, 22] and Graham [40]have given examples of large hardware proofs in HOL. Tutorial introductions to theuse of HOL for di�erent purposes can be found in the proceedings of the HOL con-ferences. Examples from HOL91 are | protocol veri�cation [16], reasoning aboutsoftware [44] and handling temporal complexity [50]. Boulton et al. have written agood summary of the embedding of hardware description languages in HOL [8].There are many other formal systems than HOL that has been used for hardwareveri�cation purposes. If we stick to logic, one early example is Hunt's veri�cation ofa microprocessor using the Boyer-Moore theorem prover [52, 53]. Another earlyreference is Barrow's work on automated hardware veri�cation [3]. Staunstrup hasused the LP theorem prover for proving safety and liveness properties of hardwarewritten in Synchronized Transistions [31, 88]. Before designing HOL, Gordonand others worked with LCF LSM [36, 37, 51]. Narendran and Stillman used termrewriting techniques to verify a image processing chip using the RRL system [76].These were all �rst-order systems. Hanna and Daeche were the �rst to use higher-order logic for hardware description and veri�cation [46]. Larsson implemented asystem for experimenting with automated theorem proving in higher-order logic [59].Another type of logic often used for hardware veri�cation is temporal logic.Clarke et al. veri�ed safety and liveness properties of �nite-state machines (FSM) us-ing a propositional branching time logic called CTL (computation tree logic). Theyused model checking to verify FSM's against formulas in CTL [12]. They also de-�ned a state-machine speci�cation language called SML [21]. Moszkowski developedan interval temporal logic (ITL) [74] for speci�cation and veri�cation of hardware.He also presented a programming language, Tempura [73], based on a subset ofITL. A formalization of ITL in HOL was later used for logic programming [45].Milne developed a process algebra, Circal (Circuit Calculus), especially forhardware applications [70] that has been used for speci�cation, simulation and ver-i�cation of hardware [2]. 38

For more information on these and other approaches to hardware veri�cation wesuggest reading the surveys by Gupta [43] and Yoeli [99].

39

40

Chapter 4A Transformational ApproachIn this chapter we present our approach to formal digital system design togetherwith a method to implement it using the HOL proof system that we presented inChapter 3.The design process can be top-down, bottom-up or sandwich (a bit of both). Ingeneral, there must always be a bottom-up part since at some stage we always mapto something prede�ned, such as a parts library. However, in the thesis we will viewthe design process as being top-down since this is justi�able at the higher levels ofabstraction considered here. That is to say that we view the formalism in whichour design is described as primitive. A schematic view of this top-down processis depicted in Figure 4.1. As we can see this is an iterative process where everyIntermediate design

Specification/

No

Yes

Ready?

Design

Transformation

Figure 4.1: View of the design processiteration brings the design a step closer to completion. In other words we transformthe initial speci�cation into a design by repeatedly applying design decisions to it.Even though the purpose of this work is to assist the process of design we willnot try to formalise what it means to design. Instead we will introduce formalobjects to record and assist design. In Section 4.1 we introduce devices, lines, ports41

and design speci�cations to represent design objects and in Section 4.2 we introduceconcepts like design state, design step, and design process to record and assist thedesign process. Finally, in Section 4.3 we outline how a design system based on ourapproach can be implemented in the HOL proof system using the window inferencepackage as a base.4.1 Design RepresentationThe requirements on the design representation is di�erent for design implementationand design veri�cation. When we implement a design we use heuristics, i.e. informalrules, to guide the process. The heuristics can be seen as a way of encoding whatconstitutes a good (or bad) design. In the sequel we will call this design checking.We also need to be able to query the design about its current properties. Suchqueries can help the designer make decisions in an interactive design process, orserve as input to algorithmic decision procedures in an automatic design process. Inthe sequel we will call this design analysis. In a formal system we need to prove arelation between the initial speci�cation and the implemented design. For this we useformal proofs. Finally, we need to be able to validate the design. By this we meanthe informal process to check if the implemented design ful�ls our intentions. Themost common method for design validation is simulation. In short, the requirementson the design representation for a formal design system are the following:� Support design analysis.� Support design checking.� Support design veri�cation.� Support design validation.No single formalism can incorporate all these properties without becoming complexand hard to use. Instead we conclude that we need a two-level design representation.The �rst level in such a design representation is based on logic and used for formalreasoning. The second level is an annotation of objects at the �rst level, designed tosupport design checking and analysis. There is a total function from objects in thesecond level of the design representation to objects in the �rst level, and a partialmapping in the other direction. The reason the latter mapping is only partial isthat not all design objects are annotated at the second level.By using a two-level design representation we can record information from thedesigner and use this to check and analyse designs. For example, assume the designerdecides to make a connection between two devices. In logic devices are modelledas predicates with free variables and interconnection is modelled by two predicatessharing the name of a variable. So we would implement this design decision byreplacing one variable with the other variable in all subterms. We have now lostinformation. For example, the information that the remaining variable represents aline in the designers view. By documenting this knowledge we make it possible touse it for tasks like design analysis and design checks.42

All this could be done by using a more complex design model but most of ourextensions capture design intentions rather than design correctness and should there-fore be separated from issues of logical correctness.4.1.1 The Logic LevelTo represent designs we need a formalism powerful enough to represent a designfrom the initial speci�cation to the implemented design but at the same time simpleenough to have a well-de�ned meaning for expressions and a calculus for safe sym-bolic manipulation of expressions. We have chosen logic as our design formalismand the logic we use is the HOL logic as de�ned in Chapter 3. We have alreadyseen in Section 3.8 that we can specify devices as predicates, where the relation im-posed by the predicate constrains the device's possible behaviour. This speci�cationmethod extends easily to specifying designs too, where each predicate in the speci-�cation constrains the design in some way. Since our interpretation of a predicateis that it constrains the object it speci�es, we often use the term constraint insteadof predicate.De�nition 1 : A constraint is a predicate.We need a formal object to represent a design so we start by de�ning what a designspeci�cation is.De�nition 2 : A design speci�cation is a boolean term of the formP1 ^ : : : ^ Pn .A design speci�cation can include many kinds of constraints | functional, environ-mental, timing, data, resource, and structural | where, for example, the functionalconstraints gives a behavioral speci�cation and the structural constraints gives apartial structure. Some of the constraints are not meant to be transformed into animplementation but are there to somehow constrain the implemented design. Theenvironmental constraints, for example, will be a part of the implementation as wellas of the speci�cation, indicating in which environment the implemented design willfunction correctly.If we look back at Table 2.1 on page 5, we see a design hierarchy of abstractionlevels in three domains. Each of these abstraction levels usually corresponds todi�erent design models, all of which could be formalized in HOL. Thus, to specify adesign at all levels of the hierarchy we would have to create a design model for everylevel used. However, many of these design models could be related by abstractionfunctions and could in that way be said to represent a single design model at di�erentlevels of abstraction. In the sequel we will assume that the designs we specify andimplement use only one design model and that all abstractions are expressed asabstraction functions.4.1.2 Design AnnotationWe have de�ned three design objects by design annotation|devices, ports, andlines. This means that devices, ports and lines are distinct from other terms of thesame type in the design speci�cation. 43

A device is a design object that denotes a physical object, e.g. a TTL circuit. Itis de�ned as follows.De�nition 3 : A device is a device speci�cation with its input and output variablessubstituted for ports, and annotated with an identi�er.Devices have names so that we can identify and separate di�erent instances of thesame type of device and so that we can generate unique port names for devices.A port is a design object that denotes an interconnection point, e.g. a pin on aTTL circuit. A port is de�ned as follows.De�nition 4 : A port is a variable with an identi�er of the form basesubscript wherebase is the annotation of a device.Ports have direction because devices at the level we consider are unidirectional andby using this fact we can perform basic design checking as we connect devices, andwe allow the implemented design to be checked by execution. Ports have namesgenerated from the name of its device. Using this we can identify the logical termcurrently representing the device.A line is a design object that denotes a physical interconnection, e.g. a wire ona TTL circuit board. A line is de�ned as follows:De�nition 5 : A line is a variable annotated with a set of ports.The reason for introducing lines as design objects instead of just renaming ports tomodel interconnection is that we want to separate constraints from lines so that, forexample, we can do design checking when we introduce lines.Using design annotation we also record the following properties of ports, wherePorts is the set of all ports in the design, Inputs and Outputs are the sets of allinputs and outputs respectively in the design, and Sources and Drains are the setsof all sources and drains in the design.De�nition 6 : An input is a port and Inputs � Ports.De�nition 7 : An output is a port and Outputs � Ports.De�nition 8 : A source is a port and Sources � Ports.De�nition 9 : A drain is a port and Drains � Ports.All ports in a design must be either an input or an output so the following musthold: Ports = Inputs [OutputsAll references to design annotations in the de�nitions above are formalized in thelanguage of design annotations. We de�ne this as follows.De�nition 10 : The design annotation language is speci�ed in Section 4.1.2.1.44

4.1.2.1 Speci�cation of the Design Annotation LanguageWe specify the language of design annotations using a denotational style [83]. Adenotational de�nition of a language consists of three parts|the abstract syntax,the semantic algebras, and the valuation functions.Abstract syntax We specify a language's syntax by listing its syntax domainsand its BNF rules. The abstract syntax for the language of design annotations isde�ned in Figure 4.2.E 2 ExpressionD 2 Dynamic expressionS 2 Static expressionI 2 Identi�erT 2 TermL 2 LineE::= D j SD::= new device I T j new line I L j del line IS::= get device I j list device T j list devices jlist inputsj list outputs jget line I j list lines j list sourcesj list drainsFigure 4.2: Abstract syntax for design annotationsSemantic algebras A semantic algebra consists of a semantic domain plus itsoperations. A semantic domain is a set of elements grouped together because theyshare some common property or use. Accompanying a domain is a set of operations.The operations are functions that need arguments from the domain to produceanswers. Operations are de�ned in two parts. First, the operation's domain andcodomain are given by an expression called the operations functionality. Second, aspeci�cation of the operations mapping is speci�ed.The semantic algebras used for specifying the design annotation are de�ned inFigures 4.3 and 4.4. However, to understand these properly we need to de�ne thebasic domains and operations that we will use to de�ne the semantic algebras of thedesign annotation language. For this purpose we assume two value domains A andB . In the product space A#B we use fst and snd to denote the �rst and the secondcomponent respectively, and (a; b) for domain construction. In the sum space A+ Bwe use inA and inB for domain construction. In the list space A� we use a :: A fordomain construction (cons). In the function space A!B we use �x : e as domainconstructor, and f (a) to denote a member of B . f (a) is sometimes abbreviated (f a)or f a when the meaning is not ambiguous. In addition to this, we assume that wehave access to the following operations: 45

I. Identi�ers, lists and termsDomains i 2 Id = Identi�erj 2 List = Id�t 2 Term = Logical termsOperations mk id: Term!Idmk id = �t [i ]: iin ports: Term!Listin ports = �t :mapmk id (listify(rator(rand t)))out ports: Term!Listout ports = �t :mapmk id (listify(rator t))II. Values and linesDomains v 2 Value = (Term + Line + List + Id)l 2 Line = Id # Id�Operations source: Line!Idsource = �l : fst(l)drains: Line!Listdrains = �l : snd(l)Figure 4.3: Semantic algebras for design annotations� assoc x l denotes the �rst pair of a list l of pairs whose �rst component is equalto x .� assoc2 x l denotes the �rst pair of a list l of pairs whose second component isequal to x .� �lter p l denotes the list of elements of a list l that satisfy p.� at l denotes the list of atomic elements in a list l .� map f l denotes the list obtained by applying f to the elements of l in turn.� listify t denotes the list of the components in the tuple t .� rand t1 t2 denotes the operand t2 from a combination (function application).� rator t1 t2 denotes the operator t1 from a combination (function application).Valuation functions The valuation function maps a language's abstract syntaxto meanings drawn from semantic domains. A valuation function D for a syntaxdomain D is listed as a set of equations, one per option in the corresponding BNFrile for D. The valuation functions for design annotations are de�ned in Figure 4.5.46

III. Annotations, devices and linesDomains a 2 Annotation = (Devices # Lines)d 2 Devices = (Id #Term)�s 2 Lines = (Id # Line)�Operations access dev: Id!Devices!Termaccess dev = �i :�d : snd(assoc(i ; d))update dev: Id!Term!Devices!Devicesupdate dev = �i :�t :�d : (i ; t) :: dlist dev: Term!Devices!Idlist dev = �t :�d : fst(assoc2 (t ; d))list devices: Devices!Listlist devices = �d :map fst daccess lin: Id!Lines!Lineaccess lin = �i :�s: snd(assoc(i ; s))update lin: Id!Line!Lines!Linesupdate lin = �i :�l :�s: (i ; l) :: sdelete lin: Id!Lines!Linesdelete lin = �i :�s: �lter (�(f ; l): i = f ) slist lines: Lines!Listlist lines = �s:map fst sget devices: Annotation!Devicesget devices = �a: fst(a)get lines: Annotation!Linesget lines = �a: snd(a)Figure 4.4: Semantic algebras, continued4.2 Design TransformationIn the previous section we de�ned the representation of static designs. In thissection we will de�ne the representation of the dynamic design process. We start bymodelling the design process in logic.From the de�nition of formal digital system design on page 1 we see that arequirement of the formal design method is that we should produce a correctnessproof of the implemented design with respect to the initial speci�cation as a by-product of the design process. To be able to do this we must keep and maintainthis proof as the design process progresses so that we can produce it when thedesign is completed. This leads to two things. We must decide what it means foran implemented design to be correct with respect to its speci�cation, and we mustdecide in what form we will document the proof.As we saw in Section 3.9 we state correctness as a satisfaction relation betweentwo design speci�cations. This means that instead of formalizing what it means todesign something we de�ne a relation that must hold between all design speci�ca-tions. We have chosen to use logical implication as satisfaction relation. Implicationis a simple, well understood relation, that intuitively �ts the role of a satisfactionrelation for design. There is already much support for proving theorems about im-47

E: Expression !Annotation!(Annotation +Value)E[[D]] = � a: inAnno(D[[D ]]a)E[[S]] = � a: inValue(S[[S]]a)D: Dynamic expression !Annotation!AnnotationD[[new device I T]] = � a: ((update dev I[[I]]T[[T]] (get devices a)),(get lines a))D[[new line I L]] = � a: ((get devices a ),(update lin I[[I]]L[[L]] (get lines a)))D[[del line I]] = � a: ((get devices a ),(delete lin I[[I]] (get lines a)))S: Static expression !Annotation!ValueS[[get device I]] = � a: inTerm(access dev I[[I]] (get devices a))S[[list device T]] = � a: inId(list dev T[[T]] (get devices a ))S[[list devices ]] = � a: inList(list devices (get devices a))S[[get line I]] = � a: inLine(access lin I[[I]] (get lines a))S[[list lines ]] = � a: inList(list lines (get lines a))S[[list in ports ]] = � a: inList( at(map in ports (get devices a)))S[[list out ports ]] = � a: inList( at(map out ports (get devices a )))S[[list sources ]] = � a: inList(map source (get lines a))S[[list drains ]] = � a: inList( at(map drains (get lines a)))I: Identi�er !Id (Omitted)T: Term!Term (Omitted)L: Line !Line (Omitted)Figure 4.5: Valuation functions for design annotationsplication in HOL and other theorem proving systems. Unfortunately though, weonly have partial correctness as our correctness criteria. From this choice it followsthat the following must hold for all n:` speci�cationn+1 ) speci�cationnWe call this a justi�cation theorem and de�ne it as follows.De�nition 11 : A justi�cation theorem is a theorem of the form� `specn+1 R specnwhere specn+1 and specn are successive device speci�cations, and R is a relationstronger than implication.The theorem above is a justi�cation theorem with no assumptions and implicationas relation. This works since every relation is stronger than itself.Using this formalization of design correctness, we can model a transformationaldesign process as follows. We start with the initial speci�cation speci�cation0 andthe assumptions � under which it holds:� ` speci�cation048

Using the justi�cation theorem we transform our initial speci�cation into a re�nedspeci�cation: � ` speci�cation1 ) speci�cation0The design process can then be expressed as a sequence of such transformations.� ` speci�cationn ) � � � ) speci�cation1 ) speci�cation0This design process can, thanks to the transitivity of implication, be collapsed to:� ` speci�cationn ) speci�cation0We will call this a design theorem and we will de�ne it as follows.De�nition 12 : A design theorem is a theorem of the form � ` specn ) spec0where spec0 and specn are device speci�cations.As we can see, every state of the design process described above can be expressedas a design theorem.The design annotation is modi�ed by applying dynamic expressions in the designannotation language to it. We will call such an expression a design annotationupdate.De�nition 13 : A design annotation update is a dynamic expression, di , in thedesign annotation language.The state of the design annotation can be expressed as a sequence of applicationsof design annotation updates.De�nition 14 : A design annotation, an , is the result of (dn � dn�1 � : : : � d1 ) a0 ,where every di is a design annotation update and a0 is the empty design annotation1.Since there is no proof obligation attached to the design annotation this is enoughto represent a particular design annotation.Having de�ned what a design theorem and a design annotation is we can now de�nethe state of the design process.De�nition 15 : A design state is a pair, design theorem # design annotation.This leads to a natural formulation of a design step.De�nition 16 : A design step is a function from design state to design state.This in turn gives the following de�nition of design process.De�nition 17 : A design process is a sequence of design steps.For each design step we thus need a pair consisting of a justi�cation theorem and adesign annotation update to transform the design. We will call such a pair a designtransform.De�nition 18 : A design transform is a pair, thm#di, where thm is a justi�cationtheorem and di is a design annotation update.A sequence of design transforms together with the initial speci�cation thus providesa documentation not only of the implemented design but also of the design decisionsmade to reach the implementation.1� is an in�x function composition de�ned as: (f � g)x = f (g x ).49

We can build libraries of design transforms to support di�erent needs| such asapplications, technologies, design styles, and company rules. In this thesis we will,however, only build a minimal set of very general transforms that could supply thebase of such a library. All in all we de�ne and use 11 transforms in the examplesin Chapters 5 and 6. The fact that this number is enough for small but realisticdesigns indicates that a library of basic transforms need not have an intimidatingsize.4.2.1 Graphical Design State RepresentationAs we have seen, the design state is represented by a pair consisting of a designspeci�cation and a design annotation. To present the design state in a naturalway we will use a graphical representation. In Figure 4.6 we see how devices, inthis case an adder, is represented graphically. Ports are shown as boxes inside thein2

ADDER del

in1 out

add1

output variable in device specification

device specification

device specification name

device identifier

ports

parameter in device specification

input variables in device specificationFigure 4.6: Devicesdevice and their identi�ers can be retrieved by subscribing the device identi�er withthe respective variable in the device speci�cation. For example, for the device inFigure 4.6 the ports are add1in1 ; add1in2 and add1out . Lines are represented as �lled-in lines between ports that are annotated with an identi�er if the name of the lineis not that of its source. Other constraints in the device speci�cation will be shownas boxes with rounded corners if they denote pseudo components or as dashed linesotherwise.4.3 Implementation MethodLooking at the model of the transformational design process in Section 4.2 we seethat there is no concept of goal in this process. Instead we continue to transformthe design speci�cation until it is in a form suitable for our purpose. This is typicalfor all design applications since the �nal result is not known in advance. Thus, thedesign process is not goal-directed and is therefore not suitable for implementationwith the subgoal package. Instead, window inference is a natural method to modela design process. 50

Window inference was originally intended as a general proof tool [86]. It waslater implemented as the window inference package in the HOL system [41], and usedfor software re�nement [42]. We just conjectured that window inference is better fordesign applications than goal-oriented styles of reasoning. Apart from this windowinference has the following strengths:� Window inference supports users who wish to solve problems by concentratingon subproblems. This means that window inference supports partitioning ofthe design task by allowing users to decompose speci�cations and design thecomponents individually. The way this is done is by opening and closingsubwindows (see Section 3.7.3.3 on page 28).� Window inference allows the user to make arbitrarily �ne manipulations ofan expression. This is important when the form of the solution is of as muchimportance as the existence of a solution itself, as is the case when derivingdesigns from their speci�cations.� Window inference allows the user to make use of the information implicit inthe context of a subproblem. For example, when restricting attention to apath through a multiplexer it may be helpful to assume that the select signalof the multiplexer holds a value corresponding to the selected path.� Window inference supports the preservation of arbitrary re exive and transi-tive relations when transforming expressions. This is important for the appli-cation of window inference to formal design where we wish to preserve correct-ness.All these strengths are important for our application apart from the last one whichis overruled by our decision to use implication as satisfaction relation.The window inference package does, however, not support the use of design an-notations. To do this we have to extend the concept of a window in the package. Wedo this in the following way. First, we implement the language of design annotationsas an abstract data type (ADT) in the ML metalanguage. Then we extend the de�-nition of a window with the design annotation ADT and add interface functions foraccessing and updating a windows design annotation component. It is essential thatwe keep design annotations on the stack since we otherwise would have problemskeeping the design state consistent.To begin reasoning with the extended window inference system the user createsa window stack as before. Creating a window stack to transform our speci�cationunder the assumptions �, while preserving implication, now results in the stackcontaining the single window depicted below:! �) ? speci�cation0 theorem: � ` speci�cation0 ) speci�cation0annotation: a0We get a window with the focus showing the speci�cation and holding a theoremsaying the speci�cation achieves itself. But now the window also holds the emptydesign annotation, a0 . This is the starting point of the design process. Applying51

a design step now results in a transformation of the focus of the window whilepreserving implication, and in an update of the design annotation.! �) ? speci�cation1 theorem: � ` speci�cation1 ) speci�cation0annotation: a1After the transformation, the focus of the window holds a new design speci�cation,the window theorem records the proof that achieves the initial speci�cation, and theannotation component of the window records the current design annotation. Aftern applications of design steps we have:! �) ? speci�cationn theorem: � ` speci�cationn ) speci�cation0annotation: anThus we have produced a new design speci�cation from the initial design spec-i�cation and in the process constructed a proof of the new design speci�cationscorrectness with respect to the initial design speci�cation. We can note that this ishow we de�ned a formal digital design system in Chapter 1.4.3.1 Design Annotation FunctionsThe abstract data type that implements design annotations gives us access to thefollowing ML functions for the design annotation updates:new device, new line and del lineApplying these functions is thus the only way we can update the design annotation.We have already de�ned the dynamic subset of the design annotation language asdesign annotation updates. Now we will de�ne the static subset as design annotationqueries.De�nition 19 : A design annotation query is a static expression, si , in the designannotation language.From the design annotation ADT we get the following design annotation queryfunctions:get device, list device, list devices, list inputs, list outputs,get line, list lines, list sources and list drainsWith the help of these functions we can write functions to perform design checksand analysis. We can, for example, write a boolean function to test if a variable isan input port. Such a function could look like this in ML2:let is input name anno = mem name (list inputs anno);;2let is a declaration of ordinary variables and mem x l returns true if some element of l isequal to x , otherwise it returns false. 52

Another example of a useful function would be a boolean function that tests if a listof ports are possible to connect taking into account the rule that two outputs maynot be joined by a line. It could be implemented like this using ML3:let connectable plist anno =letrec conn plist source anno =if (null plist)then trueelse let output = mem (hd plist) (list outputs anno) inif (output & source)then failelse conn (tl plist) (output or source) anno) inconn plist false anno;;An example of a third kind of function on the design annotation would be thefollowing function that extends a line by connecting a port to it. This is designannotation update since it modi�es the design annotation. An ML implementationcould look like this4:let ext line name port anno =let source,drains = get line name anno inlet line = if (is output port)then if (source = `')then port,drainselse failelse if (is input port)then source,(port.drains))else fail inlet anno' = del line name anno innew line name line anno';;This last function combines the design annotation update with design checking.As we can see it �rst checks if the line is possible to extend with the port given asargument before it modi�es the design annotation. We will call functions of thistype design check encapsulations.De�nition 20 : A design check encapsulation is a function where a design annota-tion update is encapsulated by design checks so that the design annotation updateis only carried out if all design checks succeed.3letrec is a declaration of recursive functions, d in e is a local declaration, and & and or arethe conjunction and disjunction operators respectively.4. is the in�x cons operator. 53

4.3.2 Window TransformsWe have de�ned a design step as a function from design state to design state.Since we chose to implement our transformational design approach using the windowinference package, we represent the design state in a window. This means that adesign step will be represented as a function from window to window. This functionmust, just as a design transform, include two components: First, a justi�cationtheorem to justify the derivation of the new design theorem; and second, a designannotation update to modify the design annotation. In addition to this, we willinclude a set of design checks to be carried out by the transform. We will call sucha function a window transform.De�nition 21 : A window transform is a function from window to window thatincludes a justi�cation theorem, a design annotation update, and a set of designchecks.To facilitate the use of our formal design approach we will de�ne a set of windowtransforms that corresponds to, for the designer, natural steps in the design process.This way we can provide the designer with a set of application speci�c transformsor, in other words, a design calculus. To the extent that this is possible, this is a bigimprovement since it means that the window transforms can be expressed using aterminology that is well known for the user. The other extreme would be to expresswindow transforms as proof procedures.The actual derivation of the new design theorem is done with the help of windowtransformation commands.De�nition 22 : A window transformation command is a function that applies ajusti�cation to the design theorem.In the window inference package there is a set of window transformation commandsfor applying di�erent kinds of justi�cations. The justi�cation can be, for example, atheorem from a built-in or loaded theory, the result of applying a built-in or derivedinference rule or a theorem proved by the user for this purpose. For many of thetransformations that we would like to make there are no suitable built-in theorems orinference rules to apply. In such situations we can de�ne our own derived inferencerules to do the job. In this way we can customize the window inference system forour application.To access and update the design annotation there are two design annotationcommands; one to retrieve a copy of the current design annotation (get_annotation),and one to replace the current design annotation with a modi�ed design annotation(update_annotation).4.3.2.1 Constructing a Window TransformThe process of deriving window transforms can be formalized like this:1. Construct a HOL term of the form we need as justi�cation theorem and �ndor design a proof procedure to prove it.54

2. Perform the design checks associated with the window transform and updatea copy of the design annotation.3. Select a window transformation command to apply the generated justi�cationtheorem to the design theorem and derive a new design theorem.4. Replace the current design annotation with the one constructed in step twoabove.To exemplify how a window transform is constructed we will give a more detailedaccount of the procedure for INTRO_TRANS, a transform that allocates a device inthe design. To start with, the designer must give a name, name, of the device to beintroduced, and a device speci�cation, device. We also have access to the currentwindow window.In step one we construct a set of ports from name and using these and device weconstruct a term, device', to represent the device in the design speci�cation. Theform of the justi�cation theorem must be ` device 0 ^ spec ) spec where spec is adesign speci�cation. We construct this by specializing the built-in theorem AND2_THMwith device' and specn . AND2_THM looks like this:` 8 t1 t2: t1 ^ t2 ) t2The resulting theorem after specialization of the universally quanti�ed variables isjust the one we needed and we have thus constructed the justi�cation theorem:` device 0 ^ specn ) specnIn step two we must decide which design annotation update and which designchecks that is appropriate for this window transform. In this case the design an-notation update must be new_device and we only check that name is not a devicealready. We implement this as a design check encapsulation. That is, we encap-sulate the design annotation update, new_device, with the design check, and namethis function intro_device. We construct the new design annotation, anno, withintro_device name device' (get_annotation window).In step three we select a window transformation command to apply the generatedjusti�cation theorem to the design theorem. Since our justi�cation is an implica-tion, we use the window transformation command for justi�cations of this form,transform_window, to apply it. This creates a new window holding a new designtheorem.The last step in the formalization is to update the design annotation with the newdesign annotation anno created in step two. We use the design annotation command,update_annotation to do this.If either the derivation of the design theorem fails due to a logical error, or theupdate of the design annotation fails due to a design check, the window transformfails and the window remains unchanged. This way, the stack of windows is alwayskept consistent. The documentation of the INTRO TRANS transform looks like this:55

INTRO_TRANSINTRO TRANS: (string -> term -> void)SynopsisIntroduces a device in the design.DescriptionINTRO TRANS name Model introduces the device name in the current design speci�-cation, specn. The predicate Model must be an abbreviation for a class of devicespeci�cations in an available library of device speci�cations.A port is created for each free variable of the device speci�cationModel. The iden-ti�ers for these ports | namei1 ; : : : ;namein ;nameo1 ; : : : ;nameom | are generatedfrom name and the names of the free variables, i1 ; : : : ; in ; o1 ; : : : ; om.A device with identi�er name is created by substituting the input and output variablesof the device speci�cation Model with the generated ports:Model (namei1 ; : : : ;namein) (nameo1 ; : : : ;nameom)This term, device for short, speci�es an instance of the class of device speci�cationsabbreviated by Model.Design annotationThe design annotation is updated by new_device name device anno.Checks that name is not a device.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = device ^ specn .The transformation of the design theorem never fails.This should be read as `by typing \INTRO TRANS nameModel" we introduce a new de-vice in the design and derive the new design theorem � ` device ^ specn ) spec0 '.To distinguish the application speci�c window transforms from the window com-mands supplied by the window inference package, we will use the su�x ` TRANS'in their names whereas the window commands end in ` WIN'.From the documentation we can note that the only failure condition is if a devicewith the same name already exists in the design. This is something that we candetect thanks to our extension of the design representation and this error is thereforedetected during the updating of the design annotation. The justi�cation theoremon the other hand, never fails. 56

Chapter 5High-Level SynthesisIn this chapter we demonstrate the use of a system based on the method intro-duced in Chapter 4 to do (formal) high-level synthesis. By high-level synthesis wemean the process of producing a mapping from speci�cations in the behavioural do-main in the form of input/output relations in logic, to implemented designs in thestructural domain in the form of netlists of hardware devices. The tasks performedduring high-level synthesis are primarily scheduling, resource allocation, resourcebinding and module binding. Scheduling is the task of assigning computations totime steps, i.e. deciding when a computation will take place. This decision is re-stricted by factors such as the data- ow in the speci�cation. When we do resourceallocation we decide which hardware resources we will have access to for implement-ing a speci�cation. Resource binding is the process of assigning each computationin the speci�cation to a hardware resource. Apart from computations, we also needto implement interconnection and storage by binding them to resources. Modulebinding is the process of binding a hardware resource to a speci�c implementationof it, i.e. a physical resource as opposed to an abstract resource. Of these tasks weperform all but the last, module binding. This is because we have simpli�ed the taskby assuming that the allocated resources correspond to actual physical resources,thus making a binding from abstract to concrete resources super uous.5.1 Design ModelWe use the approach to hardware speci�cation described in Section 3.8. The onlydi�erence from the notation introduced there is that we have chosen to let devicesbe de�ned in a curried form so that we can apply devices to partial arguments. Thisis something that simpli�es the implementation of the system.We use the sequential model of behaviour as de�ned in Section 3.8, i.e. we modelsignals as functions of time. We have a synchronous view in the model in the sensethat we interpret the passing of time as representing a global clock chopping timeinto time steps of unknown duration. Combinatorial devices are modelled withzero-delay, which means that the rise and fall times of any chain of combinatorialdevices used in our designs is assumed to be shorter than the duration of a time57

step. Devices thus have this form:` Comb i o � (8t : o t = f (i t))` Seq i o � (8t : o (t + �) = f (i t))We organize our set of device models into libraries of similar devices. In the basiclibrary we have a set of polymorphic devices. By polymorphic we mean that theycan be applied to any signal type. Const is a dummy device in the sense that itdoes not necessarily correspond to an actual physical device, but rather representa function or a property of the system being designed. Const (see Figure 5.1)represents the hardwiring of a signal to a constant value. This is often implementedvf

CONST vConst v vf � 8t :vf t = vFigure 5.1: Constant dummy in the basic libraryas wiring to the source or ground in an actual design, something we cannot expressin our design model. Delay and Mux (see Figure 5.2) are interconnection devices.outin

DELAY delDelaydel in out � 8t :out (t + del) = in tin2

outin1sel

MUXMux (sel ; in1 ; in2 ) out � 8t :out t = sel t ! in1 t j in2 tFigure 5.2: Interconnection devices in the basic libraryDelay shifts a signal a number of time steps. The actual number of time steps itwill shift a signal is decided at instantiation. Because of this, we say that Delayis generic. Every instance of Delay thus have a �xed but possibly di�erent delay.Last, Mux is a signal selector, i.e. it connects one of the input signals to the outputsignal according to the select signal at every time step. We can view Delay assharing signals in the time domain andMux as sharing signals in the space domain.The basic library is the only library that is always a part of our design model. As wewill see later, some transforms in the system depend on the library being available.In addition to the basic library, we can de�ne libraries of functional units weneed for the design at hand. For the examples in the thesis we have chosen to58

in2

ADDER del

in1 outAdder del (in1 ; in2 ) out � 8t :out (t + del) = in1 t + in2 tin2in1 out

MULT delMult del (in1 ; in2 ) out � 8t :out (t + del) = in1 t � in2 tFigure 5.3: Devices in the comp libraryde�ne a library, comp, of computational devices (see Figure 5.3). Note that thedevices in the library both delay a signal over multiple time steps. We can viewthis as them having implicit registers. The number of implicit registers is decidedat instantiation. Because of the assumption about implicit (internal) registers weassume that both these devices are pipelineable.5.1.1 Assumptions about Digital SystemsThrough the design model and the formalization of the transformational designprocess we can ensure that designs implemented with the system will always satisfythe speci�cation. This is, however, not enough to ensure that we have produced agood or even an implementable design. For ensuring this we would need a muchmore elaborate model of hardware and in particular of the design process. In theimplemented system some implicit assumptions about hardware are made. Examplesof these are:� Two outputs must not be connected to each other.� A device can only perform one operation in a time step.� Values are available in one time step only.� Lines have zero delay.� Devices, lines and ports all have unique names.As we can see, many of these have been formalized as design checks on the de-sign annotation and can therefore be enforced. Thus, using design annotations canalleviate these problems, but even using these the quality of the implemented de-sign cannot be ensured by the system, but remains the responsibility of the humandesigner guiding the system. 59

5.2 Transformational SynthesisInteraction with the system will be displayed in numbered boxes called session boxes.To see a complete synthesis session, just put all the session boxes together (in as-cending order).A Running Synthesis Example To illustrate formal synthesis with the systemmore clearly, we will use a simple speci�cation as a vehicle to demonstrate thesynthesis ow and the e�ect of the window transforms introduced. We will synthesisean implementation of the data path and a speci�cation of the control path.The speci�cation we are to implement states that the sum of x and y is to beadded to the sum of u and v and the result put in z . In logic this can be expressedlike this1: z = (x + y) + (u + v)The + operator used in the speci�cation has type : num!(num!num) in HOL.From this HOL can determine the types of the variables in the speci�cation to be: num, the natural numbers. We have chosen this speci�cation because it is simpleenough to be understandable, but at the same time complex enough to allow us todemonstrate many important features of our method and system.5.2.1 Getting StartedWe begin by making our speci�cation the focus of a window that preserves partialcorrectness, i.e. we use logical implication as satisfaction relation. We do this usingthe BEGIN STACK window command: 1BEGIN STACK ()) (z = (x + y) + (u + v))) ? z = (x+ y) + (u+ v)Where the �rst line is our input, and the second line is the output from the system.Now the synthesis process can start.5.2.2 Allocating ComputationWe can see that an adder device could implement at least one of the speci�edadditions. We would therefore like to introduce such a device into our design. Todo this we need a window transform for introducing devices.INTRO_TRANSINTRO TRANS: (string -> term -> void)1Note that by stating the speci�cation like this, it is biased towards a particular implementation.60

SynopsisIntroduces a device in the design.DescriptionINTRO TRANS name Model introduces the device name in the current design speci�-cation, specn. The predicate Model must be an abbreviation for a class of devicespeci�cations in an available library of device speci�cations.A port is created for each free variable of the device speci�cationModel. The iden-ti�ers for these ports | namei1 ; : : : ;namein ;nameo1 ; : : : ;nameom | are generatedfrom name and the names of the free variables, i1 ; : : : ; in ; o1 ; : : : ; om.A device with identi�er name is created by substituting the input and output variablesof the device speci�cation Model with the generated ports:Model (namei1 ; : : : ;namein) (nameo1 ; : : : ;nameom)This term, device for short, speci�es an instance of the class of device speci�cationsabbreviated by Model.Design annotationThe design annotation is updated by new_device name device anno.Checks that name is not a device.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = device ^ specn .The transformation of the design theorem never fails.We choose to implement the addition operation with an adder device. Such devicesare generic so we must decide a delay time for the device to be used. Based on theassumption that there is a suitable physical device available with this characteristic,we decide to introduce an adder with two time units delay from input to output.We instantiate an adder speci�cation from the library with the delay parameter 2:2INTRO TRANS add1 Adder2) ?Adder 2 (add1in1 ; add1in2 ) add1out ^z = (x+ y) + (u+ v)As we can see, the port names are generated by indexing the device-name withthe respective variable name of the device speci�cation. This is done in order toguarantee unique port names.We have now introduced a device, or to be more speci�c, a unique instance ofthe speci�cation of the device in the library. However, this device is not yet relatedto our initial speci�cation. The next synthesis step will therefore be to bind thedevice to an operator in the speci�cation. The transform for binding a device to anoperation is: 61

USE_TRANSUSE TRANS: (string -> void)SynopsisBinds a device to an operator in the design.DescriptionUSE TRANS name binds the device name to the outermost operator in the currentdesign speci�cation, specn . It does this by applying a matching algorithm to theterm representing the device in the design theorem and specn . The result of thealgorithm is a list of equivalences between subterms in the two terms that statesthe conditions under which the two terms are equivalent. From this a conjunctionof equivalences, constraints, is generated.Design annotationNo changes.Checks that name is a device.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = constraints.The transformation of the design theorem fails if the matching algorithm fails, or ifthe justi�cation theorem � ` specn+1 ) specn cannot be constructed by the built-inproof procedure.The matching algorithm mentioned in the documentation of USE TRANS works in thefollowing way:1. Creates a new (unique) time variable.2. Specializes the device speci�cation with the new time variable.3. Tries to match the syntax trees of the specialized device speci�cation and thecurrent design speci�cation in the following way. If the corresponding nodesof the syntax trees are both internal they must denote the same operation,otherwise they must have the same type. If this is not true the algorithmwill fail, otherwise it will return a list of matching terms where at least onecomponent of every matching term is a leaf in the syntax tree.62

In this case, we pick the time variable t1 and the speci�cation of the adder is:8t :add1out (t + 2 ) = add1in1 t + add1in2 tSpecializing the speci�cation with t1 yields:add1out (t1 + 2 ) = add1in1 t1 + add1in2 t1As we can see, the second expression in the current design speci�cation (see sessionbox 2) could be matched against this expression. But USE TRANS requires that thisexpression is the only expression in the window and that the device is an assumptionof the window. So before trying to apply USE TRANS we have to open a subwindowon this subexpression.We use boxes to indicate which part of the expression in the design speci�cationwe wish to open a subwindow on. The variable path always refers to the boxedsubexpression in the previous session box. 3OPEN WIN path! Adder 2 (add1in1 ; add1in2 ) add1out) ? z = (x+ y) + (u+ v)Now we have the correct design speci�cation and assumption for applying USE TRANS:4USE TRANS add1! Adder 2 (add1in1 ; add1in2 ) add1out) ? (x + y) = add1in1 t1 ^(u + v) = add1in2 t1 ^z = add1out (t1 + 2)The re�ned speci�cation now says that the device Adder2 (in1 ; in2 ) out imple-ments the original speci�cation if each of the following conditions are true: theinput port add1in1 at some time t1 is the sum of x and y, the input port add1in2 atthe same time t1 is the sum of u and v and the port add1out at time t1 + 2 equalsz . As we have seen, the introduction of a device into our design consists of twosteps: instantiating a device and making it available; and binding the instantiateddevice to an operation in the speci�cation. In the sequel, however, we will performthese in one step using the following transform:INTRO_USE_TRANSINTRO USE TRANS: (string -> term -> void)63

SynopsisIntroduces a device in the design and binds it to an operator.DescriptionINTRO TRANS nameModel introduces the device name in the current design and bindsit to the outermost operator in the current design speci�cation, specn . The predicateModel must be an abbreviation for a class of device speci�cations in an availablelibrary of device speci�cations.A port is created for each free variable of the device speci�cationModel. The iden-ti�ers for these ports | namei1 ; : : : ;namein ;nameo1 ; : : : ;nameom | are generatedfrom name and the names of the free variables, i1 ; : : : ; in ; o1 ; : : : ; om.A device with identi�er name is created by substituting the input and output variablesof the device speci�cation Model with the generated ports:Model (namei1 ; : : : ;namein) (nameo1 ; : : : ;nameom)This term, device for short, speci�es an instance of the class of device speci�cationsabbreviated by Model.It binds the new device to an operator by applying a matching algorithm to theterm device and specn. The result of the algorithm is a list of equivalences betweensubterms in the two terms that states the conditions under which the two terms areequivalent. From this a conjunction of equivalences, constraints, is generated.Design annotationThe design annotation is updated by new_device name device anno.Checks that name is not a device.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = device ^ constraints.The transformation of the design theorem fails if the matching algorithm fails, or ifthe justi�cation theorem � ` specn+1 ) specn cannot be constructed by the built-inproof procedure.Note that if we know that something in the environment will put the sum of xand y on port add1in1 and the sum of u and v on port add1in2 at some time t1then the result would appear at port add1out at t1 + 2 and the speci�cation wouldbe implemented. However, this is not the case here and we must �nd a way toimplement the other two additions as well. We choose arbitrarily to start withthe �rst one and we therefore focus on the the second expression in our designspeci�cation. 64

5OPEN WIN path! Adder 2 (add1in1 ; add1in2 ) add1out! (u + v) = add1in2 t1! z = add1out (t1 + 2)) ? (x + y) = add1in1 t1Now we have to make a design decision. We can choose either to introduce anotheradder or to reuse the one we already have. Here we choose to reuse the existingadder to implement the addition. 6USE TRANS add1! Adder 2 (add1in1 ; add1in2 ) add1out! (u + v) = add1in2 t1! z = add1out (t1 + 2)) ? x = add1in1 t2 ^y = add1in2 t2 ^add1in1 t1 = add1out (t2 + 2)As we can see we get similar constraints, but a di�erent time variable t2 , from whenwe �rst bound the adder. We also get a relation between the two time variablest1 and t2 that we will use later. We now close this subwindow and repeat thisprocedure on the remaining addition in our speci�cation. 7CLOSE WIN () % opened in session box 5 %OPEN WIN pathUSE TRANS add1CLOSE WIN ()CLOSE WIN () % opened in session box 3 %) ?Adder 2 (add1in1 ; add1in2 ) add1out ^x = add1in1 t2 ^y = add1in2 t2 ^add1in1 t1 = add1out (t2 + 2) ^u = add1in1 t3 ^v = add1in2 t3 ^add1in2 t1 = add1out (t3 + 2) ^z = add1out (t1 + 2)Now we have allocated resources for the computational part of the speci�cation butthese are still unrelated to each other in the time domain.5.2.3 Scheduling ComputationWe would like to schedule the operations in a common time frame, i.e. using onecommon time variable. The question is then, how can we do this? Where is theinformation to guide us? 65

If we look at what happens when we bind an operation from the speci�cation toa device in the design, we see that we introduce a new (unique) time variable everytime. We can use this variable to denote the operation bound at that time (we donot have to know which operation that was). By realizing this we can derive a lot ofinformation from the design description. Below we have selected some constraintsfrom session box 7: add1in1 t1 = add1out (t2 + 2) ^add1in2 t1 = add1out (t3 + 2) ^z = add1out (t1 + 2)From these we can see that the output of our (single) computational resource isbound to all time variables t1 ; t2 and t3 . This means that the operations denotedby the time variables share this resource, i.e. they must be distinct (since no devicecan do more than one operation at a time). From the �rst two constraints abovewe also see that there is a relation holding between the time variables, namely:t1 = (t2 + 2) and t1 = (t3 + 2). This in turn means that t1 � t2 and t1 � t3 . Itcan be greater since t1 denotes a time for input and a value can be input later thanit is output (e.g. by being held in a register). These conclusions are illustrated inFigure 5.4. Finding a schedule that ful�ls these constraints is trivial in such a small= Data dependency

t3

t1

t2

t n = Operation

= Operations sharing resources

>n = Bound on dependency>1 >1Figure 5.4: Timing analysis of the design in session box 7design as ours. However, if the design is larger it can be a problem to �nd one, notto mention �nding the best one.We could alleviate this problem for the designer by writing ML functions thatanalyse the design with respect to data dependencies and produces possible sched-ules. There are many algorithms for producing schedules from data- ow graphs(see e.g. [66]). One such scheduling strategy that we could use is `as soon aspossible' (ASAP). The way we would do this would be to de�ne the ML functionASAP_schedule and use that to produce a schedule. We show the ASAP schedule forour design in Figure 5.5. In HOL we formulate the schedule as constraints on thetime variables: t2 = t ^ t3 = t+ 1 ^ t1 = t+ 366

.

.

...

.

t1

.

.

.

t3

.

.

.

t2

.

.

.

t

+ 1

+ 3

+ 5Figure 5.5: Scheduling the design in session box 7To introduce this schedule into our design we must have a transform that can in-stantiate variables in the design speci�cation:INST_TRANSINST TRANS: ((term # term) list -> void)SynopsisInstantiates free variables in the design.DescriptionINSTANTIATE TRANS (t1 ; x1 ); : : : ; (tn; xn ) substitutes arbitrary terms t1 ; : : : ; tn for freevariables x1 ; : : : ; xn in the current design speci�cation, specn .Design annotationNo changes.Checks that no xi in x1 ; : : : ; xn is a port or a line.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = specn [t1 ; : : : ; tn=x1 ; : : : ; xn ] rewritten with the basic simpli�cation theo-rems to eliminate terms of the form t = t that are often a consequence of variableinstantiation.The transformation of the design theorem will fail if a variable being instantiatedx1 ; : : : ; xn is free in the assumptions � or in the initial speci�cation spec0 .Having de�ned INSTANTIATE TRANS we use it to apply our pre-calculated schedule tothe design: 67

8INSTANTIATE TRANS [(t ; t2); (t + 1; t3 ); (t + 3; t1 )]) ?Adder 2 (add1in1 ; add1in2 ) add1out ^x = add1in1 t ^y = add1in2 t ^add1in1 (t + 3) = add1out (t + 2) ^u = add1in1 (t + 1) ^v = add1in2 (t + 1) ^add1in2 (t + 3) = add1out (t + 3) ^z = add1out (t + 5)Now we have synthesised and scheduled the computational part of the speci�cation,but the interconnection part still only exists in the form of constraints on the en-vironment. This is illustrated in Figure 5.6 where these constraints are shown asdashed lines. We can, however, not start to connect the device yet. If we look morein2in1 out

add1ADDER 2

z{x,u}{y,v}Figure 5.6: The design after session box 8closely at our present design we see that we have many con icting constraints. Be-fore we can start to interconnect the ports of the device we have somehow to resolvethese constraints.

68

5.2.4 Resolving ConstraintsWe de�ned earlier a constraint as a predicate. A port constraint is thus a predicateon a port.De�nition 23 : A port constraint is a predicate, P(t1 ; : : : ; tn), where at least oneti is a port.Port constraints can be of two types, spatial or temporal. A spatial port constraintmeans that two or more processes need to share a point in space, e.g. an input port.De�nition 24 : A spatial port constraint is a term of the form i t = e where i isan input port, t is a numerical variable, and e is an arbitrary term.A temporal port constraint is typically when two (or more) processes will share avalue but at di�erent time steps.De�nition 25 : A temporal port constraint is a term of the form i (t + x ) = p (t + y)where i is an input port, t is a numerical variable, p is a port, and x and y are nu-merical terms.We will illustrate con icts involving both kinds of constraints and how we resolvethem below.5.2.4.1 Spatial Port Con ictsIf we extract all constraints on the port add1in1 from our design we get:x = add1in1 t ^add1in1 (t + 3) = add1out (t + 2) ^u = add1in1 (t + 1)We can see that add1in1 will get values from three di�erent sources, each at di�erenttimes. In other words, the constraints are con icting2 and the port must be shared.De�nition 26 : A spatial port con ict occurs when an input port is constrainedby more than one output.To implement sharing (in space) we use multiplexers since a multiplexer can selectwhich value to output at what time.The method we use for introducing a multiplexer is to pick one con icting con-straint at a time and decide through which path in the multiplexer the constraint willbe connected3. Binding means here to associate a constraint with a path throughthe multiplexer. To do this the user must provide the binder with this information.We do this by giving, as argument, the required signal value on the select input.The transform is de�ned like this:2We regard the variables x and y as signal sources3The constraint is of course not connected, but rather transferred to one of the input ports ofthe multiplexer 69

INTRO_USE_MUX_TRANSINTRO USE MUX TRANS: (string -> term -> void)SynopsisIntroduces a multiplexer device in the design and binds it to a port constraint.DescriptionINTRO USE MUX TRANS name Cond introduces a multiplexer device name in the designand binds it to the current design speci�cation, specn. Cond must be a booleanconstant.The ports namesel ;namein1 ;namein2 and nameout are created. The identi�ers ofthese ports are built from name and the names of the free variables | sel ; in1 ; in2and out | of the multiplexer speci�cation Mux.A device with identi�er name is created by substituting the input and output variablesof the device speci�cation Mux with the generated ports:Mux (namesel ;namein1 ;namein2 ) (nameout )This term, mux for short, speci�es an instance of the class of multiplexer devices.The multiplexer is bound to specn by imposing constraints on its ports. The idea isthat the device together with the generated constraints `implements' the port con-straint in specn. The current design speci�cation must be a spatial port constraint.From this and the de�nition of the multiplexer, an algorithm creates a conjunctionof equivalences, constraints, that represents the generated port constraints:(namesel t = Cond) ^ (e = nameinX t) ^ (i t = nameout t)Where nameinX is the input port associated with the value of Cond.Design annotationThe design annotation is updated by new_device namemux anno.Checks that name is not a device.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = mux ^ constraints.The transformation of the design theorem fails if specn is not of the required form,or if the or if the justi�cation theorem � ` specn+1 ) specn cannot be constructedby the built-in proof procedure.The next step is to focus on each of the constraints, one at a time. One way to dothat would be to manually identify each of the constraints in the design and open70

a subwindow on them. This works �ne for small examples like this one, but if wehave a design with hundreds of conjunctions we cannot rely on being able to scanthe design description manually. We will therefore choose a di�erent technique toillustrate how we can write ML functions that simplify our task.We write an ML function that will �nd all constraints on a given port and callthis find_constraint. If we assume that we have a function focus that returns thecurrent design speci�cation, a function conjuncts that splits a conjunctive term intoa list of conjuncts and a function is_constraint that recognises a constraint on aport when it sees one, we could de�ne find_constraint like this:let find constraint p =filter4(is constraint p) (conjuncts focus);;Applying find_constraint to add1in1 yields the following list of constraints:[ (x = add1in1 t) ; (add1in1 (t + 3) = add1out (t + 2)) ; (u = add1in1 (t + 1)) ]With the help of this new function we do not have to scan the complete designdescription manually, but we can do even better than that. By de�ning a newwindow command OPEN ON WIN that opens a subwindow on a group of conjunctsfrom the design speci�cation instead of on a single conjunct. We de�ne it like this:let OPEN ON WIN clist =GROUP WIN5clist; OPEN WIN[RATOR6];;Using find_constraint with OPEN ON WIN we get a subwindow on the constraints ofadd1in1 : 9OPEN ON WIN [find_constraint(add1in1 : num� > num)]! Adder 2 (add1in1 ; add1in2 ) add1out! y = add1in2 t! v = add1in2 (t + 1)! add1in2 (t + 3) = add1out (t + 3)! z = add1out (t + 5)) ? add1in1 t = x ^add1in1 (t + 1) = u ^add1in1 (t + 3) = add1out (t + 2)Now we must pick one of the constraints so that we can bind it. We arbitrarilychoose to start with the last one (see session box 9).4Maps a predicate over a list returning those elements of the list for which the predicate wastrue.5Rearranges the design speci�cation so that the conjuncts in the argument are the �rst in thedesign speci�cation.6Denotes the �rst conjunct in the design speci�cation.71

10OPEN WIN path! Adder 2 (add1in1 ; add1in2 ) add1out! y = add1in2 t! v = add1in2 (t + 1)! add1in2 (t + 3) = add1out (t + 3)! z = add1out (t + 5)! add1in1 t = x! add1in1 (t + 1) = u) ? add1in1 (t + 3) = add1out (t + 2)Now we have focused on one of the constraints on add1in1 , and we can bind itto a path through a multiplexer. First, however, we need to introduce a mul-tiplexer into our design. We choose to introduce and bind it in one step usingINTRO USE MUX TRANS. 11INTRO USE MUX TRANS mux1 T! Adder 2 (add1in1 ; add1in2 ) add1out! y = add1in2 t! v = add1in2 (t + 1)! add1in2 (t + 3) = add1out (t + 3)! z = add1out (t + 5)! add1in1 t = x! add1in1 (t + 1) = u) ?Mux(mux1sel ;mux1in1 ;mux1in2 )mux1out ^mux1sel (t + 3) = T ^add1out (t + 2) = mux1in1 (t + 3) ^add1in1 (t + 3) = mux1out (t + 3) 12CLOSE WIN () % opened in session box 10 %! Adder 2 (add1in1 ; add1in2 ) add1out! y = add1in2 t! v = add1in2 (t + 1)! add1in2 (t + 3) = add1out (t + 3)! z = add1out (t + 5)) ? add1in1 t = x ^add1in1 (t + 1) = u ^Mux(mux1sel ;mux1in1 ;mux1in2 )mux1out ^mux1sel (t + 3) = T ^add1out (t + 2) = mux1in1 (t + 3) ^add1in1 (t + 3) = mux1out (t + 3)As we have seen several times already, the command sequence: open a subwindow,transform the design speci�cation and close the subwindow is very common. Toavoid unnecessary typing we therefore de�ne a new window transformation com-mand: 72

let OPEN TRANSFORM WIN path trans =OPEN WIN path; trans; CLOSE WIN ();;Using this new command we can bind the second constraint on add1in1 to the `false'input of the multiplexer with: 13OPEN TRANSFORM WIN path (USE MUX TRANS mux1 F)! Adder 2 (add1in1 ; add1in2 ) add1out! y = add1in2 t! v = add1in2 (t + 1)! add1in2 (t + 3) = add1out (t + 3)! z = add1out (t + 5)) ? add1in1 t = x ^mux1sel (t + 1) = F ^u = mux1in2 (t + 1) ^add1in1 (t + 1) = mux1out (t + 1) ^Mux(mux1sel ;mux1in1 ;mux1in2 )mux1out ^mux1sel (t + 3) = T ^add1out (t + 2) = mux1in1 (t + 3) ^add1in1 (t + 3) = mux1out (t + 3)In the same way as before we bind the constraint at time t to the same input: 14OPEN TRANSFORM WIN path (USE MUX TRANS mux1 F)! Adder 2 (add1in1 ; add1in2 ) add1out! y = add1in2 t! v = add1in2 (t + 1)! add1in2 (t + 3) = add1out (t + 3)! z = add1out (t + 5)) ?mux1sel t = F ^x = mux1in2 t ^add1in1 t = mux1out t ^mux1sel (t + 1) = F ^u = mux1in2 (t + 1) ^add1in1 (t + 1) = mux1out (t + 1) ^Mux(mux1sel ;mux1in1 ;mux1in2 )mux1out ^mux1sel (t + 3) = T ^add1out (t + 2) = mux1in1 (t + 3) ^add1in1 (t + 3) = mux1out (t + 3)We have now solved the spatial constraints on add1in1 and we can close the subwin-dow: 73

15CLOSE WIN () % Opened in session box 9 %) ?mux1sel t = F ^x = mux1in2 t ^add1in1 t = mux1out t ^mux1sel (t + 1) = F ^u = mux1in2 (t + 1) ^add1in1 (t + 1) = mux1out (t + 1) ^Mux(mux1sel ;mux1in1 ;mux1in2 )mux1out ^mux1sel (t + 3) = T ^add1out (t + 2) = mux1in1 (t + 3) ^add1in1 (t + 3) = mux1out (t + 3) ^Adder 2 (add1in1 ; add1in2 ) add1out ^y = add1in2 t ^v = add1in2 (t + 1) ^add1in2 (t + 3) = add1out (t + 3) ^z = add1out (t + 5)As we can see in Figure 5.7, the result of the actions taken in session box 9 to 15 isthat we have introduced a device Mux instantiated with new control port mux1seland new data ports mux1in1 ;mux1in2 and mux1out together with a set of restrictionson the control port. We can see that the constraints for add1in2 is symmetric to thein2in1 out

add1ADDER 2

in2out

in1sel

MUXmux1

{T,F}

{x,u}

{y,v}zFigure 5.7: The design after session box 15constraints for add1in1 that we just multiplexed. We therefore repeat this procedureon the add1in2 port without showing intermediate designs:

74

16OPEN ON WIN [find_constraint(add1in2 : num!num)]OPEN TRANSFORM WIN path (INTRO USE MUX TRANS mux2 T)OPEN TRANSFORM WIN path (INTRO USE MUX TRANS mux2 F)OPEN TRANSFORM WIN path (INTRO USE MUX TRANS mux2 F)CLOSE WIN ()) ?mux2sel t = F ^y = mux2in2 t ^add1in2 t = mux2out t ^mux2sel (t + 1) = F ^v = mux2in2 (t + 1) ^add1in2 (t + 1) = mux2out (t + 1) ^Mux(mux2sel ;mux2in1 ;mux2in2 )mux2out ^mux2sel (t + 3) = T ^add1out (t + 3) = mux2in1 (t + 3) ^add1in2 (t + 3) = mux2out (t + 3) ^mux1sel t = F ^x = mux1in2 t ^add1in1 t = mux1out t ^mux1sel (t + 1) = F ^u = mux1in2 (t + 1) ^add1in1 (t + 1) = mux1out (t + 1) ^Mux(mux1sel ;mux1in1 ;mux1in2 )mux1out ^mux1sel (t + 3) = T ^add1out (t + 2) = mux1in1 (t + 3) ^add1in1 (t + 3) = mux1out (t + 3) ^Adder 2 (add1in1 ; add1in2 ) add1out ^z = add1out (t + 5)Applying these transforms results in an additional control port mux2sel , two addi-tional data ports mux2in1 ;mux2in2 and mux2out and an additional deviceMux. Wein2in1 out

add1ADDER 2

in2out

in1sel

MUXmux1

{T,F}

{x,u}

{y,v}

{T,F}

in2out

in1sel

MUXmux2

zFigure 5.8: The design after session box 16have now resolved all spatial port con icts, i.e. no input port is constrained by morethan one output. The next step will then be to turn our attention to joining portsin time. 75

5.2.4.2 Temporal Port Con ictsDe�nition 27 : A temporal port con ict is a temporal port constraint of the formi (t + x ) = o (t + y) where i is an input port, t is a numerical variable, o is anoutput port, x and y are numerical terms, and x > y .When we scan the design description for temporal port con icts, we only �nd thefollowing: add1out (t + 2) = mux1in1 (t + 3)From this we see that the ports add1out and mux1in1 must have the same value butthey will have this (common) value at di�erent time steps. This means that theycannot be connected with a line since lines do not have delay and outputs do nothold there values. As with sharing in space, we implement sharing in time with adevice. For this we use a generic n-length delay since such a device can delay thevalue for the required number of time steps. The transform for introducing andbinding a delay is:INTRO_USE_DELAY_TRANSINTRO USE DELAY TRANS: (string -> void)SynopsisIntroduces a delay device in the design and binds it to a temporal port constraint.DescriptionINTRO USE DELAY TRANS name introduces a delay device name in the design and bindsit to the current design speci�cation, specn.The ports namein and nameout are created. The identi�ers of these ports are builtfrom name and the names of the free variables, in and out , of the speci�cation of thedelay device Delay.A device with identi�er name is created by substituting the input and output variablesof the device speci�cation Delay with the generated ports:Delay del namein nameoutThis term, delay for short, speci�es an instance of the class of delay devices.The delay device is bound to specn by imposing constraints on its ports. Theidea is that the device together with the generated constraints `implements' theport constraint in specn. The current design speci�cation must be a temporal portcon ict. The delay time, del , is calculated as y � x . From this and the speci�cationof the delay device, an algorithm creates a conjunction of equivalences, constraints,that represents the generated port constraints:(p (t + x ) = namein (t + x )) ^ (i (t + y) = nameout (t + y))76

Design annotationThe design annotation is updated by new_device name delay anno.Checks: that name is not a device; that i and p are not both out ports; and thatdel � 0.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = delay ^ constraints.The transformation of the design theorem fails if specn is not of the required form,or if the or if the justi�cation theorem � ` specn+1 ) specn cannot be constructedby the built-in proof procedure.As in the spatial case, we could de�ne a function find_temporal to help us �ndall temporal constraints or just constraints on a given port. We can then useOPEN ON WIN to focus on the temporal constraints. In this case however, there isonly one temporal constraint so we open a subwindow on that by giving the pathto it: 17OPEN WIN path! mux2sel t = F... ...! z = add1out (t + 5)) ? add1out (t + 2) = mux1in1 (t + 3)INTRO USE DELAY TRANS introduces an n-length delay: 18INTRO USE DELAY TRANS del1! mux2sel t = F... ...! z = add1out (t + 5)) ?Delay 1 del1in del1out ^add1out (t + 2) = del1in (t + 2) ^mux1in1 (t + 3) = del1out (t + 3)Since there are no other temporal constraints in the design we close this subwindow.77

19CLOSE WIN ()) ?Delay 1 del1in del1out ^add1out (t + 2) = del1in (t + 2) ^mux1in1 (t + 3) = del1out (t + 3) ^mux2sel t = F ^y = mux2in2 t ^add1in2 t = mux2out t ^mux2sel (t + 1) = F ^v = mux2in2 (t + 1) ^add1in2 (t + 1) = mux2out (t + 1) ^Mux(mux2sel ;mux2in1 ;mux2in2 )mux2out ^mux2sel (t + 3) = T ^add1out (t + 3) = mux2in1 (t + 3) ^add1in2 (t + 3) = mux2out (t + 3) ^mux1sel t = F ^x = mux1in2 t ^add1in1 t = mux1out t ^mux1sel (t + 1) = F ^u = mux1in2 (t + 1) ^add1in1 (t + 1) = mux1out (t + 1) ^Mux(mux1sel ;mux1in1 ;mux1in2 )mux1out ^mux1sel (t + 3) = T ^add1in1 (t + 3) = mux1out (t + 3) ^Adder 2 (add1in1 ; add1in2 ) add1out ^z = add1out (t + 5)In Figure 5.9 we can see the current design state. Since we have resolved all con-straints in the design we can move on to interconnecting the ports.in2in1 out

add1ADDER 2

in2out

in1sel

MUXmux1

{T,F}

{x,u}

{y,v}

{T,F}

in2out

in1sel

MUXmux2

del1DELAY

out in1

zFigure 5.9: The design after session box 1978

5.2.5 Synthesising InterconnectionBy introducing a line between two ports, p1 and p2 , we state that the signal valueon these ports will be equal at all times. In logic this can be expressed as:8t : p1 t = p2 tWe could use this equation to rewrite7 our design description. If we did this, one ofthe ports would be replaced by the other port and disappear from our descriptionof the design. This would be a loss of information in several ways. We would, forexample, lose the property of uniqueness, i.e. two devices connected to the sameports would be indistinguishable from each other.Instead we document every introduction of a line using design annotations. Thisway we can keep track of every line, which port outputs to it (the source) and whichport inputs from it (the drains). This allows us to check and enforce design rulessuch as `two outputs must not be connected together'. To perform the introductionof lines and the rule checking we de�ne a new transform:INTRO_LINE_TRANSINTRO LINE TRANS: (string -> term list -> void)SynopsisIntroduces a line in the design.DescriptionINTRO LINE TRANS name x1 ; : : : ; xn connects the ports x1 ; : : : ; xn to form a line. If theempty string is given as name, the source of the line will name it. This is a convenientway to avoid having to invent names for all lines. A line, name, is created.Design annotationThe design annotation is updated by new_line name x1 ; : : : ; xn anno.Checks: that name is not an existing line; that x1 ; : : : ; xn are all ports; that no portx1 ; : : : ; xn is part of a line; that there are less than 2 out ports in x1 ; : : : ; xn ; thatthere are more than 2 ports in x1 ; : : : ; xn ; and, that a name is given to lines withouta source.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = specn [name; : : : ;name=x1 ; : : : ; xn ] rewritten with the basic simpli�cation7Rewriting is a basic technique in HOL, see Section 3.7.1.1 for an explanation. In the windowinference package there is a set of window transformation commands that rewrites the currentdesign speci�cation using di�erent lists of theorems. The most common one is REWRITE_WIN thatuses a set of standard rewrites and a list of theorems given as argument.79

theorems to eliminate terms of the form t = t that are often a consequence of variableinstantiation.The transformation of the design theorem will fail if a port being instantiatedx1 ; : : : ; xn is free in the assumptions � or in the initial speci�cation spec0 .If we look at Figure 5.9 we see that there are constraints between several ports thatwe can make permanent by turning into lines. We begin by connecting mux1out withadd1in1 . We have underlined the conjuncts in our design speci�cation in session box19 that are a�ected | we give the name line1 to the line: 20INTRO LINE TRANS line1 [add1in1 : num!num;mux1out : num!num]) ?Delay 1 del1in del1out ^add1out (t + 2) = del1in (t + 2) ^mux1in1 (t + 3) = del1out (t + 3) ^mux2sel t = F ^y = mux2in2 t ^add1in2 t = mux2out t ^mux2sel (t + 1) = F ^v = mux2in2 (t + 1) ^add1in2 (t + 1) = mux2out (t + 1) ^Mux(mux2sel ;mux2in1 ;mux2in2 )mux2out ^mux2sel (t + 3) = T ^add1out (t + 3) = mux2in1 (t + 3) ^add1in2 (t + 3) = mux2out (t + 3) ^mux1sel t = F ^x = mux1in2 t ^mux1sel (t + 1) = F ^u = mux1in2 (t + 1) ^Mux(mux1sel ;mux1in1 ;mux1in2 ) line1 ^mux1sel (t + 3) = T ^Adder 2 (line1 ; add1in2 ) add1out ^z = add1out (t + 5)In Figure 5.10 we show the design after the introduction of line1 . As we can seea line has been introduced into the design annotation. This is illustrated by thecontinuous line between add1in1 and mux1out . We then connect the output of mux2with the other input of add1 and call the new line line2:80

in2in1 out

add1ADDER 2

in2out

in1sel

MUXmux1

{T,F}

{x,u}

{y,v}

{T,F}

in2out

in1sel

MUXmux2

del1DELAY

out in1

z

line1

Figure 5.10: The design after session box 20 21INTRO LINE TRANS line2 [add1in2 : num!num;mux2out : num!num]) ?Delay 1 del1in del1out ^add1out (t + 2) = del1in (t + 2) ^mux1in1 (t + 3) = del1out (t + 3) ^mux2sel t = F ^y = mux2in2 t ^mux2sel (t + 1) = F ^v = mux2in2 (t + 1) ^Mux(mux2sel ;mux2in1 ;mux2in2 ) line2 ^mux2sel (t + 3) = T ^add1out (t + 3) = mux2in1 (t + 3) ^mux1sel t = F ^x = mux1in2 t ^mux1sel (t + 1) = F ^u = mux1in2 (t + 1) ^Mux(mux1sel ;mux1in1 ;mux1in2 ) line1 ^mux1sel (t + 3) = T ^Adder 2 (line1 ; line2 ) add1out ^z = add1out (t + 5)Next we connect add1out with mux2in1 . Here we do not give a name to the new line(we do this by giving the empty string as argument). Instead the name of the linewill be that of the output port that is the source of it:81

22INTRO LINE TRANS `' [add1out : num!num;mux2in1 : num!num]) ?Delay 1 del1in del1out ^add1out (t + 2) = del1in (t + 2) ^mux1in1 (t + 3) = del1out (t + 3) ^mux2sel t = F ^y = mux2in2 t ^mux2sel (t + 1) = F ^v = mux2in2 (t + 1) ^Mux(mux2sel ; add1out ;mux2in2 ) line2 ^mux2sel (t + 3) = T ^mux1sel t = F ^x = mux1in2 t ^mux1sel (t + 1) = F ^u = mux1in2 (t + 1) ^Mux(mux1sel ;mux1in1 ;mux1in2 ) line1 ^mux1sel (t + 3) = T ^Adder 2 (line1 ; line2 ) add1out ^z = add1out (t + 5)The design resulting from this design step can be seen in Figure 5.11. Now we wouldin2in1 out

add1ADDER 2

in2out

in1sel

MUXmux1

{T,F}

{x,u}

{y,v}

{T,F}

in2out

in1sel

MUXmux2

del1DELAY

out in1

add1out

z

line2

line1

Figure 5.11: The design after session box 22like to connect the port del1in with the existing line add1out . For this we need a newtransform to connect ports with existing lines:CONNECT_LINE_TRANSCONNECT LINE TRANS: (string -> term -> void)SynopsisConnects a port with an existing line. 82

DescriptionCONNECT LINE TRANS name x connects the port x to the line name.Design annotationThe design annotation is updated by ext_line name x anno.Checks: that name is an existing line; that x is a port; that x is not already connectedto a line; and, that line name has no source if x is an out port.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = specn [name=x ] rewritten with the basic simpli�cation theorems to elimi-nate terms of the form t = t that are often a consequence of variable instantiation.The transformation of the design theorem will fail if x is free in the assumptions �or in the initial speci�cation spec0 .We apply the CONNECT LINE TRANS transform: 23CONNECT LINE TRANS add1out del1in : num!num) ?Delay 1 add1out del1out ^mux1in1 (t + 3) = del1out (t + 3) ^mux2sel t = F ^y = mux2in2 t ^mux2sel (t + 1) = F ^v = mux2in2 (t + 1) ^Mux(mux2sel ; add1out ;mux2in2 ) line2 ^mux2sel (t + 3) = T ^mux1sel t = F ^x = mux1in2 t ^mux1sel (t + 1) = F ^u = mux1in2 (t + 1) ^Mux(mux1sel ;mux1in1 ;mux1in2 ) line1 ^mux1sel (t + 3) = T ^Adder 2 (line1 ; line2 ) add1out ^z = add1out (t + 5)The result of applying CONNECT LINE TRANS can be seen in Figure 5.12. Next wemake a connection from del1out to mux1in1 :83

in2in1 out

add1ADDER 2

in2out

in1sel

MUXmux1

{T,F}

{x,u}

{y,v}

{T,F}

in2out

in1sel

MUXmux2

del1DELAY

out in1

add1out

z

line2

line1

Figure 5.12: The design after session box 23 24INTRO LINE TRANS `' [del1out : num!num;mux1in1 : num!num]) ?Delay 1 add1out del1out ^mux2sel t = F ^y = mux2in2 t ^mux2sel (t + 1) = F ^v = mux2in2 (t + 1) ^Mux(mux2sel ; add1out ;mux2in2 ) line2 ^mux2sel (t + 3) = T ^mux1sel t = F ^x = mux1in2 t ^mux1sel (t + 1) = F ^u = mux1in2 (t + 1) ^Mux(mux1sel ; del1out ;mux1in2 ) line1 ^mux1sel (t + 3) = T ^Adder 2 (line1 ; line2 ) add1out ^z = add1out (t + 5)Looking at the design in Figure 5.13 now, we see that it is complete in the sensethat all computations in the initial speci�cation have been allocated a computationalresource, and interconnections have been allocated. There is, however, one possibleoptimization still to make. The constraints on control port mux1sel and mux2sel areequal so one common constraint would su�ce for both.We do this by connecting mux1sel and mux2sel with a new line, muxsel , andexpress the constraint on the line instead of on the individual ports. We do the latterby grouping all constraints on one of the ports to be connected before introducingthe line. When the line has been introduced, we open a subwindow so that we getthe constraints we grouped earlier in the assumptions, and use them and the basicrewrites to rewrite the rest of the design. This removes one set of constraints on thenew line: 84

in2in1 out

add1ADDER 2

in2out

in1sel

MUXmux1

{T,F}

{x,u}

{y,v}

{T,F}

in2out

in1sel

MUXmux2

del1DELAY

out in1

add1out

outdel1

z

line2

line1

Figure 5.13: The design after session box 24 25GROUP WIN �nd constraint(mux1sel : num!bool)INTRO LINE TRANS muxsel [(mux1sel : num!bool) (mux2sel : num!bool)]OPEN TRANSFORM WIN RAND (BASIC ASM REWRITE WIN[ ])) ?Delay 1 add1out del1out ^y = mux2in2 t ^v = mux2in2 (t + 1) ^Mux(muxsel ; add1out ;mux2in2 ) line2 ^muxsel t = F ^x = mux1in2 t ^muxsel (t + 1) = F ^u = mux1in2 (t + 1) ^Mux(muxsel ; del1out ;mux1in2 ) line1 ^muxsel (t + 3) = T ^Adder 2 (line1 ; line2 ) add1out ^z = add1out (t + 5)With this, the design process is �nished. The result can be seen in Figure 5.14. Byreordering and grouping the conjuncts we get a structural description of the syn-thesised device, a set of control constraints and (optionally) a set of interconnectionconstraints. The interconnection constraints we get here are the result of our use ofconstants in the original speci�cation.Below we can see the theorem that is the output from our design e�ort.` ((Delay1add1out del1out ^Mux(mux2sel ; add1out ;mux2in2 ) line2 ^Mux(mux1sel ; del1out ;mux1in2 ) line1 ^Adder2 (line1 ; line2 ) add1out ) ^(muxsel t = F ^ muxsel (t + 1 ) = F ^ muxsel (t + 3 ) = T) ^(y = mux2in2 t ^ v = mux2in2 (t + 1 ) ^x = mux1in2 t ^ u = mux1in2 (t + 1 ) ^ z = add1out (t + 5 )))) (z = (x + y) + (u + v)) 85

in2in1 out

add1ADDER 2

in2out

in1sel

MUXmux1

{x,u}

{y,v} in2out

in1sel

MUXmux2

del1DELAY

out in1

add1out

outdel1

mux sel

z

line2

line1

{T,F}

Figure 5.14: The design after session box 25To improve readability, the theorem has been reordered on the form:` (synthesized device ^ control constraints ^ connect constraints)) speci�cationThe control and interconnection constraints provide us with a control-path spec-i�cation. Hence, we can reformulate our current state of design in the followingway:` data-path implementation ^ control-path speci�cation ) speci�cationThus we see that we have partitioned the original speci�cation into a data-pathimplementation and a control-path speci�cation and that in order to achieve a com-plete implementation we would need to synthesise the control-path next. In thisexample it would not be di�cult to synthesise a controller to implement the speci�-cation, but for more complex designs we might have to use an optimizing tool to docontrol synthesis. In such cases, the resulting speci�cation could be used as inputto such a tool. The fact that we get a data-path implementation together with acontrol-path speci�cation as a result of the design process is a major feature of theapproach.86

Chapter 6Design by Re�nementAbstraction is a powerful technique that is used frequently in formal veri�cationto relate design descriptions expressed at di�erent levels of detail. This subject isthoroughly treated by Melham in his thesis [67] where both abstraction within amodel and abstraction between models is discussed. In our work we are primarilyinterested in abstraction within a model, which Melham separates into behaviouralabstraction, data abstraction and temporal abstraction.That abstractions are important for designing at higher levels is con�rmed bythe wide acceptance of multi-level HDL's such as VHDL [55, 61] among designers.In VHDL the designer can write speci�cations in a procedural or data- ow form andmodel data using a exible data-type mechanism. Unfortunately, current designtools have very limited support for the use of abstractions in speci�cations. Onlyrestricted forms of behavioural abstraction are supported. Most high-level synthesissystems only support a �xed set of data types such as 8, 16, and 32 bit words.Furthermore, high-level design languages such as VHDL do not support safe symbolicreasoning about objects speci�ed in the language. This means that the re�nementof a speci�cation with abstraction into a more `concrete' speci�cation is performedwithout the security of tool support.In formal system design we can support arbitrary abstractions of behaviour, dataand time in speci�cations; as well as the re�nement of such abstractions to moreconcrete representations by safe symbolic reasoning. We use the terms abstractionand re�nement as de�ned in Section 2.1 to mean a function from the detailed to theabstract, and a function from the abstract to the detailed.6.1 Formal Re�nementThe speci�cation of the required behaviour of a device to be designed can be ex-pressed in a more abstract form than the implementation of the device. Below wediscuss three such forms of abstraction and how we can design by re�nement fromthem. A fourth type of abstraction, structural abstraction, mean the mapping fromthe (abstract) behavioural domain in the form of operators to the (concrete) struc-tural domain in the form of net-lists of hardware devices. The process of producingthis mapping is however not referred to as structural re�nement but as synthesis87

and was discussed in Chapter 5.Common to all forms of abstraction is that a satisfaction relation must expressa relationship between a strong constraint (the concrete model) and a weaker con-straint (the abstract model). We can formalize this type of satisfaction relation inlogic as implication. This is a weaker satisfaction relation than equality, giving usonly partial correctness as opposed to total correctness (see Section 3.9.1 for a moreextensive discussion on this), but it does on the other hand allow us to performdesign re�nement as we demonstrate in the rest of this chapter.6.1.1 Behavioural Re�nementA speci�cation is often partial (see Section 3.8.1), i.e. it only gives a speci�cation ofparts of the behaviour of the device to be designed. Such a speci�cation typicallystipulates how a device is expected to behave only when used in certain environ-ments. In all other environments, the behaviour of the device is left unspeci�ed.In our hardware model, the behaviour of a device is speci�ed for arbitrary envi-ronments. In this case the partial speci�cation contains less information about theactual behaviour of the device than the implemented design does | thus the formalrelation between them is one of behavioural abstraction. Another case of partialspeci�cations is when some functionality present in the implemented design is miss-ing in the speci�cation. An example of this is an adder device having an over ow ag not required by its speci�cation.If D[v1 ; : : : ; vn ] represents an implemented design and S[v1 ; : : : ; vn ] representsa partial speci�cation, then we can express the formal correctness relation in thetheorem: `D[v1; : : : ; vn]) S[v1; : : : ; vn]The behavioural re�nement task, i.e. the task of deriving a behaviourally more de-tailed design from a behaviourally less detailed speci�cation, is implicit in formaldigital system design. In fact we have performed it already in the multiple additionexample in Chapter 5 without explicitly mentioning it. When we, for example, jointwo ports by introducing a line, we perform a behavioural re�nement by de�ning thevalue on the two ports to be equal at all times and not just at the time speci�ed bythe constraint relating the two ports (unless of course the constraint is de�ned forall times). In the example of adding functionality, we can do this by adding devicesto the design as long as these additions ful�ll the satisfaction relation and retain thevalidity of the design description. In short we de�ne behavioural re�nement as `tointroduce something that does not follow directly from the speci�cation'.6.1.2 Data Re�nementA speci�cation can be expressed in terms of operations on abstract values. The freevariables in such a speci�cation do not denote the concrete values appearing on theports of the implemented device. A satisfaction relation based on data abstractionmust therefore relate concrete and abstract values. An example of data abstraction88

is the use of numerals in the speci�cation of a device which will be implementedusing n-bit words.Suppose D[c1 ; : : : ; cn ] and S[a1 ; : : : ; an] are two logical terms representing animplemented design and a speci�cation of it. The free variables c1 ; : : : ; cn are ports(functions from time to values) of a concrete type and a1 ; : : : ; an are variables ofan abstract type. To formulate a correctness statement that relates the two termswe must de�ne an abstraction function from values of the concrete type into valuesof the abstract type. Given such a function f : ctype!atype, we can express theformal correctness relation in the theorem:`D[c1; : : : ; cn]) S[f � c1; : : : ; f � cn]The data re�nement task, i.e. the task of deriving a design constraining data of aconcrete type from a speci�cation constraining data of an abstract type, can beperformed by introducing abstraction predicates into the speci�cation. Such anabstraction predicate can be expressed like this:DataRefine f abs ref � abs = f refUsing the abstraction predicate we can establish a relation between abstract andconcrete values, thus `implementing' data re�nement. An example of an abstractionfunction can be a function from n-bit words to numerals.6.1.3 Temporal Re�nementA speci�cation of a device can give a less detailed speci�cation of the device's be-haviour over time than an actual implementation of the device will. The speci�cationcan, for example, be de�ned only for certain interesting time points but leave un-speci�ed the behaviour between these time points. A satisfaction relation basedon temporal abstraction must therefore relate two di�erent representations of time,one concrete and one abstract. An example of a temporal abstraction is the speci-�cation of a microprogrammed computer with time de�ned in terms of instructionsteps, i.e. one instruction is performed in every time unit. An implementation ofsuch a computer would require every instruction to take a number of microprogramsteps (which in turn corresponds to a number of clock cycles).Temporal abstraction functions can be either partial or total . A partial timefunction only relates some concrete time points to abstract time points, whereas atotal time function relates all concrete time points to abstract time points by relatingintervals of concrete time points to abstract time points. We only discuss partialtime functions here, but Melham discusses total time functions in his thesis [67].Suppose D[c1 ; : : : ; cn ] and S[a1 ; : : : ; an] are two logical terms representing animplemented design and a speci�cation of it. The free variables c1 ; : : : ; cn are portsof a concrete type and a1 ; : : : ; an are variables of an abstract type. To formulatea correctness statement that relates the two terms we must de�ne a temporal ab-straction function (a time mapping) from concrete to abstract time. Given sucha function f : ctime!atime, we can express the formal correctness relation in thetheorem: 89

`D[c1; : : : ; cn]) S[c1 � f; : : : ; cn � f ]The temporal re�nement task is the task of deriving a design de�ned at concrete timepoints from a speci�cation de�ned at abstract time points. Just as data re�nement,it can be performed by introducing abstraction predicates into the speci�cation. Wewill see an example of a temporal abstraction function in the next section.6.2 An IIR-�lter ExampleWe have chosen as an example an in�nite input response �lter, whose output attime t is 0 if t = 0, and is equal to a constant multiple of the input at time t addedto another constant multiple of the output at time t -1 otherwise. We express thisformally in HOL by de�ning the function IIR:` IIR input a b 0 � 0 ^IIR input a b (Suc t) � (a � (input t)) + (b � (IIR input a b t))There are several reasons for choosing this example. For one, it uses recursion whichis di�cult to synthesise using algorithmic tools. Another reason is that it has beensynthesised using the LAMBDA/DIALOG system (see [29]) and can therefore beused to compare the two systems. We formulate the speci�cation of the �lter as` (8t: output (t+m) = IIR inputab t)where m is the latency of the system which will be generated during the synthesisand a and b are constants we instantiate the speci�cation with. The latency tellsus how many time units we have to wait for the �rst output to appear whereas thedelay tells us with which frequency we will generate new results after the initiallatency. In this example, the delay of the speci�cation is �xed to 1 time unit by theuse of Suc in the speci�cation of the �lter. The number of time units it takes for aninput to have an e�ect on the output is thus determined by the sum of the latencyand the delay.We (arbitrarily) choose to implement the IIR using adders and multipliers with2 and 4 time units delay respectively. We get the de�nitions of these devices byinstantiation of the generic adder and multiplier in the library of computationaldevices (see Figure 5.3 on page 59).`Adder 2 (in1 ; in2 ) out � 8t :out (t + 2) = in1 t + in2 t`Mult 4 (in1 ; in2 ) out � 8t :out (t + 4) = in1 t � in2 tSince we speci�ed the delay of the �lter to be 1 time unit and the devices we willuse to implement the �lter have delays of 2 and 4 time units we realize that the(macro) time unit used in the speci�cation and the (micro) time unit used in theimplementation can not be the same. Thus we have used a more abstract notion oftime when we de�ned the �lter than what we did when we speci�ed the behaviourof the adder and the multiplier. The use of abstract notions of time is a convenient90

method to specify the temporal ordering of events in situations where the timebetween events is not important (see Section 6.1.3 for more on this). In the case ofthe �lter we have speci�ed that the current output of the �lter will depend on theprevious input and the previous output with out saying anything about how long agoprevious was. To be able to design by re�nement from such abstract speci�cationswe need a method to relate two notions of time. We propose to do that with thehelp of abstraction predicates as we will demonstrate in Section 6.2.2.6.2.1 Pre-ProcessingBefore starting to work with the window inference package we need to `massage' ourspeci�cation somewhat to get it into a form that is better suited for the package.We start by proving the following lemma using induction in the subgoal-package1and de�ne it as the uniqueness lemma.` ((outputm = 0) ^(8t: output (Suc(t+m)) = a � (input t) + b � (output (t+m)))) �(8t: output (t+m) = IIR inputab t)From the uniqueness lemma it is not hard to prove the following:(8t: output (t+m) = IIR inputab t)` (outputm = 0) ^(output (Suc(t+m)) = a � (input t) + b � (output (t+m)))From the conclusion of the theorem above we get the form of the speci�cation thatwe will use in the window transformation:(outputm = 0) ^(output (Suc(t+m)) = a � (input t) + b � (output (t+m)))6.2.2 Window TransformationWe begin the transformation process by putting the speci�cation of the IIR-�lter,on the form resulting from the pre-processing, on the window stack. 1BEGIN STACK ()) ((output m = 0 ) ^(output (Suc(t +m)) = (a � (input t)) + (b � output(t +m))))) ? (outputm = 0) ^(output (Suc(t+m)) = (a � (input t)) + (b � output(t +m)))1These kind of proofs are more conveniently carried out using goal-oriented reasoning thanusing window inference. 91

6.2.2.1 Temporal Re�nementThe time scales used in the IIR speci�cation and in the de�nitions of the deviceswe will use to implement the speci�cation are not the same. This means that wehave to relate them somehow. We will do this by de�ning an abstraction predicateRefine that is de�ned like this:`Refinen abs ref = (abs = �t : ref (n � t))This predicate relates two functions of time (representing ports in this case) with avariable n . By introducing this predicate into our design with one argument boundto a port and the other argument bound to a new variable of the same type as theport, we can use the de�nition of the predicate to rewrite the speci�cation to beexpressed in terms of concrete time. To introduce Refine we need a transform forintroducing an arbitrary predicate into our design.INTRO_PRED_TRANSINTRO PRED TRANS: (term -> void)SynopsisIntroduces a predicate in the design.DescriptionINTRO PRED TRANS Pred introduces the predicate Pred in the design.Design annotationNo changes.No checks.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = Pred ^ specn.The transformation of the design theorem never fails.We introduce aRefine predicate into our design using the INTRO PRED TRANS windowtransform, and instantiate it so that it relates output to the new variable out . 2INTRO PRED TRANS Refine n output out) ?Refine n output out ^(outputm = 0) ^(output (Suc(t+m)) = (a � (input t)) + (b � output(t +m)))92

To be able to use the Refine predicate to rewrite with, we need to expand it usingits de�nition into the form: output = �t 0:out(n � t 0)We will do this in a more elaborate way than by simply expanding the instancein the current design speci�cation. Instead we use the possibility in the windowinference package to derive theorems from the context of a window. This way wecan derive the above statement from the Refine predicate by rewriting with itsde�nition and add it as a lemma. The advantage of this method is that we do nothave to expand predicates that represents real or pseudo devices and thereby losethe structure of the design.For this purpose we de�ne a window command that generates a lemma fromthe �rst assumption of the window by rewriting with a list of theorems given asargument to the command:let FIRST ASSUM LEMMA WIN thml =OPEN CONTEXT (hd (disp hypotheses(TOP WIN())))2[ ];REWRITE WIN thml;CLOSE WIN ();;Having the FIRST ASSUM LEMMA WIN window command we put our Refine predicate�rst in the assumptions of the window by opening a subwindow on the rest of the ex-pression, apply the FIRST ASSUM LEMMA WIN transform with the de�nition of Refineas argument to create a lemma of the desired form and then perform basic rewritingwith the assumptions (now including our lemma) before closing the subwindow. 3OPEN WIN[RAND]FIRST ASSUM LEMMA WIN[REFINE_DEF]BASIC ASM REWRITE WIN[ ]CLOSE WIN) ?Refine n output out ^((�t0: out (n � t0))m = 0) ^((�t0: out (n � t0)) (Suc(t+m)) =(a � (input t)) + (b � (�t0: out(n � t0))(t+m)))Since we will use the sequence of commands in session box 3 again, we make thede�nition:let LEMMA REWRITE WIN tm thml =FRONT TERM WIN3tm;OPEN WIN[RAND];FIRST ASSUM LEMMA WIN thml;BASIC REWRITE WIN[ ];CLOSE WIN();;2This expression returns the �rst assumption in the current window.93

Note that this constitutes a slightly more intelligent transform than the sequence insession box 3 since we can use any term in the design speci�cation rather than justthe �rst one. We need to re�ne the input as well as the output stream. We do thisin the same way as before but now using LEMMA REWRITE WIN: 4INTRO PRED TRANS Refine n input inLEMMA REWRITE WIN Refine n input in [REFINE_DEF]) ?Refine n input in ^Refine n output out ^((�t0: out (n � t0))m = 0) ^((�t0: out (n � t0)) (Suc(t+m)) =(a � ((�t0: in(n � t0)) t)) + (b � (�t0: out(n � t0))(t+m)))The last step in the temporal re�nement phase is to apply beta-conversion to allsubterms of the current design speci�cation (the �rst line below) and expand thesuccessor function Suc (the second line below): 5CONVERT WIN(TOP_DEPTH_CONV(BETA_CONV))REWRITE WIN[ADD1]) ?Refine n input in ^Refine n output out ^(out (n �m) = 0) ^(out (n � ((t+m) + 1)) =(a � (in(n � t))) + (b � (out(n � (t+m)))))As we can see we have re�ned the (macro) time scale in the original IIR-�lterspeci�cation to a (micro) time scale that is sampled n times more frequently.6.2.2.2 InitializationIf we look at the design description in session box 5 we see that the output is de�nedby two conjuncts that together form a conditional statement on the value of the timevariable. This is easier to see if we state it in the following way:out (n � (t+m)) = ((t = 0)! 0 j (a � (n � (t� 1))) + (out(n � ((t� 1) +m))))We have chosen to de�ne one possible implementation, using a Mux device, as adesign transform:INIT_MUX_TRANSINIT MUX TRANS: (string -> void)3Rearranges the current design speci�cation so that the term in the argument is the �rstconjunct. 94

SynopsisIntroduces a multiplexer device in the design and binds it to a special form ofconstraint.DescriptionINIT MUX TRANS name introduces a multiplexer device name in the design and binds itto the current design speci�cation, specn .The ports namesel ;namein1 ;namein2 and nameout are created. The identi�ers ofthese ports are built from name and the names of the free variables, sel ; in1 ; in2 andout , of the multiplexer speci�cation Mux.A device with identi�er name is created by substituting the input and output variablesof the device speci�cation Mux with the generated ports:Mux (namesel ;namein1 ;namein2 ) (nameout )This term, mux for short, speci�es an instance of the class of multiplexer devices.The multiplexer device is bound to specn by imposing constraints on its ports. Theidea is that the multiplexer together with the generated constraints `implements'the port constraint in specn if specn is of the form:p 0 = x ^ p (t + 1) = y[p(t)]Where p is a port, t is a variable denoting time, and y is a term. From specn and thespeci�cation of the multiplexer, an algorithm creates a conjunction of equivalences,constraints, that represents the generated port constraints:namesel 0 = T ^ namesel (t + 1) = F ^namein1 0 = x ^ namein2 (t + 1) = y[p(t)] ^p 0 = nameout 0 ^ p (t + 1) = nameout (t + 1) [ ^ p t = nameout t ]Design annotationThe design annotation is updated by new_device namemux anno.Checks that name is not a device.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = mux ^ constraints.The transformation of the design theorem fails if specn is not of the required form,or if the or if the justi�cation theorem � ` specn+1 ) specn cannot be constructedby the built-in proof procedure.We use the OPEN TRANSFORM WIN command to apply the INIT MUX TRANS transform tothe correct design speci�cation: 95

6OPEN TRANSFORM WIN [RAND;RAND] (INIT MUX TRANS mux)) ?Refine n input in ^Refine n output out ^Mux (muxsel ;muxin1 ;muxin2 )muxout ^muxsel (n �m) = T ^muxsel (n � ((t +m) + 1)) = F ^muxin1 (n �m) = 0 ^muxin2 (n � ((t +m) + 1)) = (a � (in(n � t))) + (b � (out(n � (t +m)))) ^out (n �m) = muxout (n �m) ^out (n � ((t+m) + 1)) = muxout (n � ((t +m) + 1)) ^out (n � (t+m)) = muxout (n � (t +m))Now we see that we can eliminate the variable out by replacing it with the portmuxout since they will be equal for all possible values on t . We implement this stepby instantiating out to muxout using the INSTANTIATE TRANS window transform: 7INSTANTIATE TRANS [muxout : num!num;out : num!num]) ?Refine n input in ^Refine n output muxout ^Mux (muxsel ;muxin1 ;muxin2 )muxout ^muxsel (n �m) = T ^muxsel (n � ((t +m) + 1)) = F ^muxin1 (n �m) = 0 ^muxin2 (n � ((t +m) + 1)) = (a � (in(n � t))) + (b � (muxout(n � (t +m))))We have now completed the initialization phase of the design. The current designstate can be seen in Figure 6.1.in2

outin1sel

MUXmux

RefinenRefine

n

0

{T,F}

inputoutputinFigure 6.1: The design after session box 76.2.2.3 Data-path SynthesisThe next design phase will be to synthesise the data path speci�ed by the last con-junct in the current design speci�cation. We start by opening a subwindow on thatconjunct, and proceed to allocate computational resources just as in the multipleaddition example in Chapter 5. Since we can identify the outermost operator in theconjunct to be an addition we �rst introduce an adder device with a 2 (micro) timesteps delay4:4We assume there is a library component with this delay.96

8OPEN WIN pathINTRO USE TRANS add Add2! Refine n input in! Refine n output muxout! Mux (muxsel ;muxin1 ;muxin2 )muxout! muxsel (n �m) = T! muxsel (n � ((t +m) + 1)) = F! muxin1 (n �m) = 0j input = �t 0:in(n � t 0)j 8t 0:muxout t 0 = (muxsel t 0 ! muxin1 t 0 j muxin2 t 0)) ?Add2 (addin1 ; addin2 ) addout ^muxin2 (n � ((t +m) + 1)) = addout (t2 + 2 ) ^a � (in(n � t)) = addin1 t2 ^b � (muxout(n � (t+m))) = addin2 t2Then we allocate two multipliers with a delay of 4 (micro) time steps before closingthe subwindow. 9OPEN TRANSFORM WIN path1 (INTRO USE TRANS mul1 Mul4)OPEN TRANSFORM WIN path2 (INTRO USE TRANS mul2 Mul4)CLOSE WIN) ?Refine n input in ^Refine n output muxout ^Mux (muxsel ;muxin1 ;muxin2 )muxout ^muxsel (n �m) = T ^muxsel (n � ((t +m) + 1)) = F ^muxin1 (n �m) = 0 ^Add2 (addin1 ; addin2 ) addout ^muxin2 (n � ((t +m) + 1)) = addout (t2 + 2) ^Mul4 (mul1in1 ;mul1in2 )mul1out ^addin1 t2 = mul1out (t3 + 4) ^a = mul1in1 t3 ^in(n � t) = mul1in2 t3 ^Mul4 (mul2in1 ;mul2in2 )mul2out ^addin2 t2 = mul2out (t4 + 4) ^b = mul2in1 t4 ^muxout (n � (t +m)) = mul2in2 t4We have now allocated a computational resource for every operator in the speci�ca-tion, and the data-path synthesis phase is thereby concluded. The design after thedata-path synthesis can be seen in Figure 6.2.97

in2in1 out

ADDER 2

in2in1 out

MULT 4mul1

in2in1 out

MULT 4mul2

in2out

in1sel

MUXmux

add

{T,F}

0Refinen

B

A

Refinen

outputinput Figure 6.2: The completed design after session box 96.2.2.4 SchedulingFrom our design description we can extract the following constraints on the timevariables5: n � ((t+m) + 1) � t2 + 2t2 � t3 + 4n � t � t3t2 � t4 + 4n � (t+m) � t4From this we decide on the following schedule:(t2 = (n � (t+m)) + 4) ^ (t3 = n � (t+m)) ^ (t4 = n � (t+m))We introduce this schedule with the INSTANTIATE TRANS window transform: 10INSTANTIATE TRANS [((n � (t +m)); t3 ); ((n � (t +m)); t4 ); ((n � ((t +m) + 1) + 4); t2 )]) ?Refine n input in ^Refine n output muxout ^Mux (muxsel ;muxin1 ;muxin2 )muxout ^muxsel (n �m) = T ^muxsel (n � ((t +m) + 1)) = F ^muxin1 (n �m) = 0 ^Add2 (addin1 ; addin2 ) addout ^muxin2 (n � ((t +m) + 1)) = addout ((n � (t +m)) + 6) ^Mul4 (mul1in1 ;mul1in2 )mul1out ^addin1 ((n � (t +m)) + 4) = mul1out ((n � (t +m)) + 4) ^a = mul1in1 (n � (t +m)) ^in(n � t) = mul1in2 (n � (t +m)) ^Mul4 (mul2in1 ;mul2in2 )mul2out ^addin2 ((n � (t +m)) + 4) = mul2out ((n � (t +m)) + 4) ^b = mul2in1 (n � (t +m)) ^muxout (n � (t +m)) = mul2in2 (n � (t +m))5The use of � and � instead of = re ects the possibility to delay the use of a value98

Having scheduled all computations, the retiming variable n and the latency variablem can be �xed. From the current design description we can extract the followingconstraints on these variables:n � ((t+m) + 1) = (n � (t+m)) + 6n � t = n � (t+m)The solution to the above equations is the binding of n to 6 and m to 0. Due tothe fact that the latency variable is used in the speci�cation we cannot instanti-ate it using INSTANTIATE TRANS. Instead we can bind it to a new value using theINTRO PRED TRANS window transform.We �rst instantiate n to 6 and then bind m to 0. To propagate this bindingto the rest of the design we use the OPEN TRANSFORM WIN command to focus on thedesign except the binding predicate, and rewrite the restricted design speci�cationwith the assumptions (the binding predicate in this case); the basic rewrites; and aset of arithmetic theorems. 11INSTANTIATE TRANS [(6; n)]INTRO PRED TRANS (m = 0)OPEN TRANSFORM WIN RAND (BASIC ASM REWRITE WIN [ADD_CLAUSES;MULT_CLAUSES])) ? m = 0 ^Refine 6 input in ^Refine 6 output muxout ^Mux (muxsel ;muxin1 ;muxin2 )muxout ^muxsel 0 = T ^muxsel (6 � (t + 1)) = F ^muxin1 0 = 0 ^Add2 (addin1 ; addin2 ) addout ^muxin2 (6 � (t + 1)) = addout ((6 � t) + 6) ^Mul4 (mul1in1 ;mul1in2 )mul1out ^addin1 ((6 � t) + 4) = mul1out ((6 � t) + 4) ^a = mul1in1 (6 � t) ^in(6 � t) = mul1in2 (6 � t) ^Mul4 (mul2in1 ;mul2in2 )mul2out ^addin2 ((6 � t) + 4) = mul2out ((6 � t) + 4) ^b = mul2in1 (6 � t) ^muxout (6 � t) = mul2in2 (6 � t)Browsing through the current design description in session box 11 we see that allconstraints have timing components on equal form but one (boxed). We �x thisby opening a subwindow on the constraint and perform some simple arithmeticrewriting on it6:6LEFT_ADD_DISTRIB� ` 8mnp: p � (m + n) = (p �m) + (p � n) andMUL_CONV 6 � 1 � ` 6 � 1 = 6 99

12OPEN TRANSFORM WIN path REWRITE WIN [LEFT_ADD_DISTRIB;(MUL_CONV 6 � 1 )]) ? m = 0Refine 6 input in ^Refine 6 output muxout ^Mux (muxsel ;muxin1 ;muxin2 )muxout ^muxsel 0 = T ^muxsel (6 � (t + 1)) = F ^muxin1 0 = 0 ^Add2 (addin1 ; addin2 ) addout ^muxin2 ((6 � t) + (6)) = addout ((6 � t) + 6) ^Mul4 (mul1in1 ;mul1in2 )mul1out ^addin1 ((6 � t) + 4) = mul1out ((6 � t) + 4) ^a = mul1in1 (6 � t) ^in(6 � t) = mul1in2 (6 � t) ^Mul4 (mul2in1 ;mul2in2 )mul2out ^addin2 ((6 � t) + 4) = mul2out ((6 � t) + 4) ^b = mul2in1 (6 � t) ^muxout (6 � t) = mul2in2 (6 � t)All computations are now scheduled and all constraints are in a form making inter-connection possible. But there is one more thing we can do here, we can remove thevariable in and replace it with the port mul1in2 since, according to the underlinedconjunct in session box 12, they will have the same value for all values of t . We usethe INSTANTIATE TRANS transform to do this: 13INSTANTIATE TRANS [mul1in2 : num!num;in: num!num]) ? m = 0Refine 6 input mul1in2 ^Refine 6 output muxout ^Mux (muxsel ;muxin1 ;muxin2 )muxout ^muxsel 0 = T ^muxsel (6 � (t + 1)) = F ^muxin1 0 = 0 ^Add2 (addin1 ; addin2 ) addout ^muxin2 ((6 � t) + (6)) = addout ((6 � t) + 6) ^Mul4 (mul1in1 ;mul1in2 )mul1out ^addin1 ((6 � t) + 4) = mul1out ((6 � t) + 4) ^a = mul1in1 (6 � t) ^Mul4 (mul2in1 ;mul2in2 )mul2out ^addin2 ((6 � t) + 4) = mul2out ((6 � t) + 4) ^b = mul2in1 (6 � t) ^muxout (6 � t) = mul2in2 (6 � t)6.2.2.5 Introducing Lines and ConstantsWe connect ports together by introducing lines into our design. We do this usingthe INTRO LINE TRANS transform: 100

14INTRO LINE TRANS `' [muxin2 : num!num;addout : num!num]INTRO LINE TRANS `' [addin1 : num!num;mul1out : num!num]INTRO LINE TRANS `' [addin2 : num!num;mul2out : num!num]INTRO LINE TRANS `' [muxout : num!num;mul2in2 : num!num]) ? m = 0 ^Refine 6 input mul1in2 ^Refine 6 output muxout ^Mux (muxsel ;muxin1 ; addout)muxout ^muxsel 0 = T ^muxsel (6 � (t + 1)) = F ^muxin1 0 = 0 ^Add2 (mul1out ;mul2out) addout ^Mul4 (mul1in1 ;mul1in2 )mul1out ^a = mul1in1 (6 � t) ^Mul4 (mul2in1 ;muxout)mul2out ^b = mul2in1 (6 � t)We replace the constants in the design description with constant devices using thefollowing transform:INTRO_CONST_TRANSINTRO CONST TRANS: (string -> term -> void)SynopsisIntroduces a device that generates a constant value in the design.DescriptionINTRO CONST TRANS name Val introduces a constant device name in the design. Aport namevf is created and a device with identi�er name is created by substitutingthe output variable of the device speci�cation Const with the generated port:Const Val namevfThis term, const for short, speci�es an instance of the class of constant devices.Design annotationThe design annotation is updated by new_device name const anno.Checks that name is not a device.Design theoremThe design theorem � ` specn ) spec0 is modi�ed to � ` specn+1 ) spec0 wherespecn+1 = const ^ constraints. 101

The transformation of the design theorem never fails.We introduce a constant device, connect it and rewrite the current design speci�ca-tion with the instantiated de�nition of the constant device: 15INTRO CONST TRANS const1 aINTRO LINE TRANS `' [mul1in1 : num!num;const1vf : num!num]LEMMA REWRITE WIN Consta const1vf [CONST_DEF]) ?Constaconst1vf ^m = 0 ^Refine 6 input mul1in2 ^Refine 6 output muxout ^Mux (muxsel ;muxin1 ; addout)muxout ^muxsel 0 = T ^muxsel (6 � (t + 1)) = F ^muxin1 0 = 0 ^Add2 (mul1out ;mul2out) addout ^Mul4 (const1vf ;mul1in2 )mul1out ^Mul4 (mul2in1 ;muxout)mul2out ^b = mul2in1 (6 � t)We repeat this procedure for the constants a and b: 16INTRO CONST TRANS const2 bINTRO LINE TRANS `' [mul2in1 : num!num;const2vf : num!num]LEMMA REWRITE WIN Constb const2vf [CONST_DEF]INTRO CONST TRANS const3 0INTRO LINE TRANS `' [muxin1 : num!num;const3vf : num!num]LEMMA REWRITE WIN Const0 const3vf [CONST_DEF]) ?Const 0const3vf ^Const bconst2vf ^Constaconst1vf ^m = 0 ^Refine 6 input mul1in2 ^Refine 6 output muxout ^Mux (muxsel ; const3vf ; addout)muxout ^muxsel 0 = T ^muxsel (6 � (t + 1)) = F ^Add2 (mul1out ;mul2out) addout ^Mul4 (const1vf ;mul1in2 )mul1out ^Mul4 (const2vf ;muxout)mul2outThe design is now completed and can be seen in Figure 6.3. The resulting theoremheld by the window is: 102

in2in1 out

ADDER 2

in2in1 out

MULT 4mul1

vfCONST 0const3

in2in1 out

MULT 4mul2

in2out

in1sel

MUXmux

Refine6

Refine6

vf

const1CONST A

vf

const2CONST B

add

{T,F}

outputinput Figure 6.3: The completed design after session box 16` Const0 const3vf ^ Constb const2vf ^ Consta const1vf ^m = 0 ^ Refine6 input mul1in2 ^ Refine6output muxout ^Mux (muxsel ; const3vf ; addout)muxout ^muxsel 0 = T ^ muxsel (6 � (t + 1)) = F ^Add2 (mul1out ;mul2out ) addout ^Mul4 (const1vf ;mul1in2 )mul1out ^Mul4 (const2vf ;muxout)mul2out) ((outputm = 0) ^(output (Suc(t+m)) = a � (input t) + b � (output (t+m))))6.2.3 Post-ProcessingWe can process the theorem generated by the window transformation to get in aform of our choice. We can for example move the binding of the latency into theassumptions:m = 0`Const0 const3vf ^ Constb const2vf ^ Consta const1vf ^Refine6 inputmul1in2 ^ Refine6output muxout ^Mux (muxsel ; const3vf ; addout)muxout ^muxsel 0 = T ^ muxsel (6 � (t + 1)) = F ^Add2 (mul1out ;mul2out) addout ^Mul4 (const1vf ;mul1in2 )mul1out ^Mul4 (const2vf ;muxout )mul2out) ((outputm = 0) ^(output (Suc(t+m)) = a � (input t) + b � (output (t+m))))Another possibility is to universally quantify time:

103

m = 0` 8t: (Const0 const3vf ^ Constb const2vf ^ Consta const1vf ^Refine6 inputmul1in2 ^ Refine6output muxout ^Mux (muxsel ; const3vf ; addout)muxout ^muxsel 0 = T ^ muxsel(6 � (t + 1)) = F ^Add2 (mul1out ;mul2out) addout ^Mul4 (const1vf ;mul1in2 )mul1out ^Mul4 (const2vf ;muxout )mul2out )) ((outputm = 0) ^(output (Suc(t+m)) = a � (input t) + b � (output (t+m))))6.3 Behavioural TransformationA behavioural transformation of an expression performs a restructuring of the ex-pression, i.e. it changes its form rather than its meaning. These transformations canplay a very important part in formal system design since the form of the speci�ca-tion is of the utmost importance for both the quality of the �nal design and the easewith which we arrive at such a design.A simple example of behavioural transformation can be achieved by unfolding arecursive function. Consider for example the �lter de�nition in Section 6.2:` IIR input a b 0 � 0 ^IIR input a b (Suc t) �(a � (input t))+(b � (IIR input ab t))We derived an implementation from it with a zero latency and a clock ratio of 6.One way to achieve a faster design would be to unfold the de�nition once to get aspeci�cation of the following form:` IIR input a b 0 � 0 ^IIR input a b 1 � a � (input 0) ^IIR input a b (t + 2) �(a � (input(t + 1)))+(b � ((a � (input t)) + (b � (IIR input ab t))))By transforming this speci�cation we could generate a design with some latencybut with a smaller clock ratio, i.e. a design that after some latency starts producingoutput at a higher speed than our original design. An example of the kind ofpossible transformations would be to use the fact that addition and multiplication isassociative and distributive, and rebracket the above speci�cation into the following:` IIR input a b 0 � 0 ^IIR input a b 1 � a � (input 0) ^IIR input a b (t + 2) �(a � (input(t + 1)))+(b � a) � (input t) + (b � b) � (IIR input ab t)104

This way the multiplication of the constants can be done statically, and a speed-upcan be achieved.

105

106

Chapter 7Summary and Future WorkIn this thesis we have presented an approach to formal digital system design. Wesummarise the distinguishing features of the approach with the following list:� Using HOL as implementation platform.� Using window inference to model the design process.� Extending the design logic with design annotations.We will elaborate a little on each of the items in the next section before discussingfuture work.7.1 SummaryTreating designs and speci�cations as predicates is an established method for formalreasoning about digital systems [3, 38, 46, 52, 59]. The main advantages of thisapproach are:� As predicates, design objects are terms in our logic. This means that we mayreason about them more directly than if we had to reason about them viasome other semantics.� Existing proof systems like HOL may be easily customized for doing safe sym-bolic reasoning about digital designs.� We can use logical implication as satisfaction relation. Implication is a simple,well understood relation, that intuitively �ts the role of a satisfaction rela-tion for design. There is already much support for proving theorems aboutimplication in HOL and other theorem proving systems.In design applications the �nal result is always unknown. For this reason we conjec-ture that transformational styles of reasoning, such as window inference, is betterfor design applications than goal-oriented styles of reasoning. In addition, windowinference has the following strengths: 107

� Window inference supports users who wish to solve problems by concentratingon subproblems. This means that window inference supports partitioning ofthe design task by allowing users to decompose speci�cations and design thecomponents individually.� Window inference allows the user to make arbitrarily �ne manipulations ofan expression. This is important when the form of the solution is of as muchimportance as the existence of a solution itself, as is the case when derivingdesigns from their speci�cations.� Window inference allows the user to make use of the information implicit inthe context of a subproblem. For example, when restricting attention to apath through a multiplexer it may be helpful to assume that the select signalof the multiplexer holds a value corresponding to the selected path.� Window inference supports the preservation of arbitrary re exive and transi-tive relations when transforming expressions. This is important for the appli-cation of window inference to formal design where we wish to preserve correct-ness.To be able to support the process of designing digital systems in a formal envi-ronment, we need to do more than just model the design process, we also need tosupport it. For this we need a more elaborate representation of designs than iscommonly used in formal systems today. However, we need not make our formaldesign descriptions more elaborate and thereby make proofs more complex. Insteadwe can add a level of interpretation to the design logic to capture other aspects ofthe design. This works well since the information necessary for making design deci-sions is not the same as the information necessary to verify designs formally. Hence,they can be distinct. This additional level of interpretation should thus capture theaspects of the design that are important for the application at hand. To supporthigh-level synthesis, for example, it should be in a form more like the internal designrepresentations used today in such systems. In the thesis we have demonstrated thefeasibility of this approach by adding a small number of design annotations to ourdesign logic.7.2 Future workThe initial work proposed in this thesis could be continued and extended in manyways. In this section we discuss a selection of issues that we believe to be importantand worthy of further investigation.7.2.1 Interfacing to CAD-toolsSomewhere along the design process we have to interface to other CAD-tools, bethey high-level synthesis, logic synthesis, or layout tools. Consider, for example,that we would like to compile our design to silicon using the Solo silicon compiler.108

We would then have to provide as input a description of the design in the structuralhardware description language Model [75]. One way of doing this would be to de-�ne a library of components closely resembling the constructs available in Modeland a set of structural combinators to describe interconnection inModel. We couldthen transform our design until it consisted solely of components from this libraryinterconnected by the combinators. A simple translator would then make the trans-lation. Another possibility would be to embedModel in HOL [8] and to re�ne intothis subset of HOL. The problem with both these approaches is that our semanticsfor Model might be di�erent from the operational semantics implicit in the com-piler, which is the only way the semantics is de�ned for most commercially availableHDL's today. This interface between formal systems and the informal environmentwill always be the weakest part of the formal design chain. Even if the entire designprocess is formalized in one or more formal systems, it will always be necessary toinformally validate the formal speci�cation against the intended behaviour (spec-i�cation validation) to see if the speci�cation speci�es what we intended, and tovalidate the design model(s) against `the real world' (model validation) to see if theabstractions are correct.7.2.2 AutomationThe issue of automation will always be important. In this thesis we have presentedtwo examples of formal digital system design, high-level synthesis and design byre�nement. Automation will always be limited for the latter kind of designs wherearbitrary abstractions are used and the design task can be considered to be anintellectual task requiring the designer to make many design decisions. It is onlynatural that such a process cannot be fully automated. However, high-level synthesisis di�erent since the design task is relatively �xed, we basically need to map aset of operations to a set of resources in an e�cient way. This makes the high-level synthesis task easier to automate and indeed, most existing computationalsupport systems for high-level synthesis are automatic. Unfortunately, the designrepresentations used in most formal digital design systems today are not elaborateenough to support automatic design and not well suited for design space pruning.Using an annotated design logic as we have proposed in the thesis would alleviatethese problems but issues such as speed and e�ciency would still be limiting factors.Formal methods are important also for automatic high-level synthesis but the designveri�cation task in high-level synthesis should be separate from the design derivationtask.7.2.3 Design ValidityA problem in the work presented here is the lack of validity checks on the evolvingdesigns. That is, we may introduce, for example, variable bindings that will make aconstraint in the speci�cation invalid, without the system detecting this. The onlyway we can think of to avoid this problem would be to prove a consistency theorem onthe entire design, every time the design was transformed. We see several di�culties109

with such a method. How would we, for example, formulate such a theorem andhow would we write a proof procedure to check it automatically for every possibledesign.7.2.4 Design DocumentationIn this thesis we have only brie y mentioned the advantages of being able to docu-ment the complete design process including the initial speci�cation and every designdecision taken to create a design implementation. Having such a complete documen-tation will make many tasks that today are either error prone or time consumingeasier. Perhaps the most important aspect is the reusability of designs. We could,for example, build libraries of completed designs for well-de�ned subtasks in largerdesigns and just incorporate these into the solution of the main task. This wouldbe possible since the result of a design is a theorem of correctness that we can applyto a subtask in another design as a single design step. Other possibilities includethe use of previous versions of a design as a base for a new version, just editing theparts the need to be updated. Since our system allows us to partition the designtask into subtasks, we need only redesign the modi�ed parts to create a new design.The ability of the window system to use contextual information will also help keepthe complete design consistent.7.2.5 Window InferenceAfter having worked with the window inference system during this project, we havecome to realize that we have not taken advantage of all possibilities of the system.The window inference method is uniquely well suited for this kind of applications andthere are many di�erent techniques for formal digital system design that could beimplemented using window inference. We have, for example, to a very little extentused features such as: The possibility to use context information, the possibilityto keep and use theorems on the stack, and the possibility to de�ne satisfactionrelations.7.2.6 User InterfaceAll systems that do extensive interaction with a user need a good user interface.In this thesis we have presented all examples in a purely textual way, but theredo exists a window based interface to the window inference system that is writtenusing the Centaur system [91, 92]. With this interface, interaction is simpli�ed.We can, for example, choose which subexpressions to focus on using the mouse;we can have multiple stacks in di�erent windows, thus making it easier to derivesubdesigns in parallel; and we can choose to present information about the designprocess in di�erent windows. 110

7.2.7 Hardware/Software CodesignSince the window inference package in HOL was originally developed for softwarere�nement, hardware/software codesign should be possible using it.7.2.8 Speci�cation LanguageAn important aspect of formal digital system design is the way we write speci�-cations and how we get feedback from analysing them. One way is to execute thespeci�cation so that we can study its dynamic behaviour on some well chosen inputsand convince ourselves it handles these correctly. Another way is to prove the spec-i�cation has some properties vital for its correctness. Since we wish to allow partialspeci�cations, execution is not possible. However, we can de�ne a set of speci�cationpredicates and theorems about them to use for proofs about speci�cations. An e�ortalong these lines has been made by Carre~no [17]. He has de�ned a special class ofpredicates called transition assertions targeted towards specifying, validating, andverifying, systems.

111

112

Bibliography[1] ACM. Proceedings of the 1991 International Workshop on Formal Methods inVLSI Design, Miami, United States, Jan. 1991.[2] A. Bailey, G. McCaskill, J. McIntosh, and G. Milne. The Description andAutomatic Veri�cation of Digital Circuits in Circal. Technical Report HDV-15-91, Department of Computer Science, University of Strathclyde, 26 RichmondStreet, Glasgow G1 1XH, Scotland, May 1991.[3] H. G. Barrow. Proving the Correctness of Digital Hardware Designs. VLSISystems Design, pages 64{77, July 1984.[4] D. A. Basin. Extracting Circuits From Constructive Proofs. In [1].[5] D. Borrione, L. Pierre, and A. Salem. Formal Veri�cation of VHDL descrip-tions in Boyer-Moore: �rst results. In Proceedings Euro-VHDL'90 Conference,Marseille, France, Sep 5{8 1990.[6] D. Borrione and R. Waxman, editors. Proceedings of the 10th InternationalConference on Computer Hardware Design Languages, Marseille, France, 1991.IFIP, North Holland.[7] R. Boulton. A HOL Semantics for a Subset of ELLA. Technical Report 254,University of Cambridge, Computer Laboratory, New Museums Site, PembrokeStreet, Cambridge CB2 3QG, England, Apr. 1992.[8] R. J. Boulton, A. D. Gordon, M. J. C. Gordon, J. R. Harrison, J. M. J. Her-bert, and J. P. van Tassel. Experience with embedding hardware descriptionlanguages in HOL. In R. Boute, T. Melham, and V. Stavridou, editors, Pro-ceedings of the Conference on Theorem Provers in Circuit Design: Theory,Practice and Experience, The University of Nijmegen, The Netherlands, June1992. IFIP, North Holland.[9] R. J. Boulton, M. J. C. Gordon, J. M. J. Herbert, and J. P. van Tassel. TheHOL Veri�cation of ELLA Designs. In [1].[10] R. T. Boute. System Semantics: Principles, Applications and Implementation.ACM Transactions on Programming Languages and Systems, 10(1):118{155,Jan. 1988. 113

[11] B. C. Brock and J. Warren A. Hunt. A Formal Introduction to a Simple HDL.In [87], chapter 7, pages 285{329.[12] M. C. Browne, E. M. Clarke, D. L. Dill, and B. Mishra. Automatic Veri�-cation of Sequential Circuits Using Temporal Logic. IEEE Transactions onComputers, C-35(12):1035{1044, Dec. 1986.[13] F. Burns, D. Kinniment, and A. Koelmans. Correct Interactive Transforma-tional Synthesis of DSP Hardware. Technical Report 321, Computing Labora-tory, University of Newcastle upon Tyne, Claremont Tower, Claremont Road,Newcastle upon Tyne NE1 7RU, England, 1991.[14] H. Busch. Proof-based transformation of formal hardware models. In G. Jonesand M. Sheeran, editors, Proceedings of the Workshop on Designing CorrectCircuits, Workshops in Computing, pages 271{296, Oxford, England, 1990.Springer-Verlag.[15] H. Busch and G. Venzl. Proof-aided design of veri�ed hardware. In Proceed-ings of the 28th Design Automation Conference, pages 391{396, San Fransisco,California, United States, Jun 17{21, 1991. IEEE Computer Society Press.[16] R. Cardell-Oliver. On the use of the HOL system for Protocol Veri�cation. In[98], pages 59{62.[17] V. Carre~no. The Transition Assertions Speci�cation Method. Unpublishedmaterial.[18] S.-K. Chin. Combining engineering vigor with mathematical rigor. In M. Leeserand G. M. Brown, editors, Proceedings of Workshop on Hardware Speci�cation,Veri�cation and Synthesis: Mathematical Aspects, Cornell University, Ithaca,New York, United States, 1989. Springer-Verlag.[19] A. Church. A Formulation of the Simple Theory of Types. Journal of SymbolicLogic, 5:56{68, 1940.[20] L. J. M. Claesen, editor. Proceedings of the IMEC-IFIP International Workshopon Applied Formal Methods for Correct VLSI Design, Leuven, Belgium, 1989.IFIP, Elsevier.[21] E. M. Clarke, D. E. Long, and K. L. McMillan. A Language for CompositionalSpeci�cation and Veri�cation of Finite State Hardware Controllers. In J. A.Darringer and F. J. Rammig, editors, Proceedings of the 9th International Con-ference on Computer Hardware Design Languages, pages 281{295. IFIP, NorthHolland, June 1989.[22] A. Cohn. Correctness properties of the VIPER block model. Technical Re-port 134, University of Cambridge, Computer Laboratory, New Museums Site,Pembroke Street, Cambridge CB2 3QG, England, May 1988.114

[23] A. Cohn. A proof of correctness of the VIPER microprocessor: the �rst level.In G. Birtwistle and P. A. Subrahmanyam, editors, VLSI Speci�cation, Veri�-cation and Synthesis. Kluwer Academic Publishers, 1988.[24] Computer General Electronic Design, U.K. The ELLA Language ReferenceManual, issue 4.0 edition, 1989.[25] G. Cousineau, G. Huet, and L. Paulson. The ML Handbook. Technical report,INRIA, 1986.[26] G. Durrieu, K. Kessaci, and M. Lemaitre. Transe: An Experimental Transfor-mation Assistant for Digital Circuit Design. In J. Staunstrup and R. Sharp,editors, Proceedings of the 2nd Workshop on Designing Correct Circuits, Lyn-gby, Denmark, 1992.[27] P. Eles, K. Kuchcinski, Z. Peng, and M. Minea. Compiling VHDL into a High-Level Synthesis Design Representation. In Proceedings of the European DesignAutomation Conference, pages 604{609, Hamburg, Germany, Sept. 1992. IEEEComputer Society Press.[28] H. Eveking. Experience in Designing Formally Veri�able HDL's. In [6], pages321{334.[29] M. P. Fourman. Formal System Design. In [87], chapter 5, pages 191{236.[30] D. D. Gajski, N. D. Dutt, A. C.-H. Wu, and S. Y.-L. Lin. High-Level Synthesis:Introduction to Chip and System Design. Kluwer Academic Publishers, Norwell,Massachusetts, United States, 1992.[31] S. Garland, J. Guttag, and J. Staunstrup. Veri�cation of VLSI circuits usingLP. In G. J. Milne, editor, Proceedings of the IFIP WG 10.2 Conference onthe Fusion of Hardware Design and Veri�cation, pages 325{341. North Holland,July 1988.[32] A. D. Gordon. A mechanised de�nition of Silage in HOL. Technical Report 287,University of Cambridge, Computer Laboratory, New Museums Site, PembrokeStreet, Cambridge CB2 3QG, England, Feb. 1993. ESPRIT BRA 3215.[33] A. D. Gordon. The formal de�nition of a synchronous hardware-descriptionlanguage in higher order logic. In Proceedings of the International Conference onComputer Design, pages 531{534. IEEE Computer Society Press, Cambridge,Mass, United States, Oct 11{14, 1992.[34] M. Gordon and T. Melham, editors. Introduction to HOL. Cambridge Univer-sity Press, Cambridge, England, Mar. 1993.[35] M. Gordon, R. Milner, and C. Wadsworth. Edinburgh LCF: A Mechanised Logicof Computation, volume 78 of Lecture Notes in Computer Science. Springer-Verlag, Berlin, Germany, 1979. 115

[36] M. J. C. Gordon. LCF-LSM. Technical Report 41, University of Cam-bridge, Computer Laboratory, NewMuseums Site, Pembroke Street, CambridgeCB2 3QG, England, Sept. 1983.[37] M. J. C. Gordon. Proving a computer correct. Technical Report 42, Universityof Cambridge, Computer Laboratory, New Museums Site, Pembroke Street,Cambridge CB2 3QG, England, Sept. 1983.[38] M. J. C. Gordon. Why Higher-Order Logic is a Good Formalism for Specifyingand Verifying Hardware. In G. J. Milne and P. A. Subrahmanyam, editors,Formal Aspects of VLSI Design: Proceedings of the Edinburgh Workshop onVLSI, pages 153{177, Edinburgh, Scotland, 1985. North Holland.[39] M. J. C. Gordon. A proof generating system for Higher Order Logic. TechnicalReport 103, University of Cambridge, Computer Laboratory, New MuseumsSite, Pembroke Street, Cambridge CB2 3QG, England, Jan. 1987.[40] B. T. Graham. The SECD Microprocessor: A Veri�cation Case Study. KluwerAcademic Publishers, Norwell, Massachusetts, United States, 1992.[41] J. Grundy. Window Inference in the HOL System. In [98], pages 177{189.[42] J. Grundy. A Window Inference Tool for Re�nement. In C. B. Jones, B. T.Denvir, and R. C. Shaw, editors, Proceedings of the 5th Re�nement Workshop,Workshops in Computing, pages 230{254, Lloyd's Register, London, England,Jan. 1992. BCS-FACS, Springer-Verlag.[43] A. Gupta. Formal Hardware Veri�cation Methods: A Survey. Research Re-port CMU-CS-91-193, School of Computer Science, Carnegie-Mellon University,Pittsburgh, PA 15213, United States, Oct. 1991.[44] R. Hale. Reasoning about software. In [98], pages 52{58.[45] R. W. S. Hale. Programming in Temporal Logic. PhD thesis, University of Cam-bridge, Computer Laboratory, NewMuseums Site, Pembroke Street, CambridgeCB2 3QG, England, July 1989. Technical Report No.173.[46] F. K. Hanna and N. Daeche. Speci�cation and Veri�cation Using Higher-Order Logic. In C.-J. Koomen and T. Moto-oka, editors, Proceedings of the7th International Conference on Computer Hardware Design Languages, pages418{433, Tokyo, Japan, Aug. 1985. IFIP, North Holland.[47] F. K. Hanna and N. Daeche. Dependent types and formal synthesis. Philosoph-ical Transactions of the Royal Society of London | Series A: Mathematical andPhysical Sciences, 1992.[48] F. K. Hanna, M. Longley, and N. Daeche. Formal Synthesis of Digital Systems.In [20]. 116

[49] R. W. Hartenstein, editor. Hardware Description Languages, volume 7 of Ad-vances in CAD for VLSI. North Holland, Amsterdam, The Netherlands, 1987.[50] J. Herbert. Dealing With Temporal Complexity in Hardware Veri�cation. In[98], pages 13{21.[51] J. Herbert. The application of formal speci�cation and veri�cation to a hard-ware design. In C.-J. Koomen and T. Moto-oka, editors, Proceedings of the7th International Conference on Computer Hardware Design Languages, pages434{445, Tokyo, Japan, 1985. North Holland.[52] W. A. Hunt Jr. The Mechanical Veri�cation of a Microprocessor Design. InProceedings of the IFIP WG 10.2 Conference on From HDL Descriptions toGuaranteed Correct Circuit Designs, Grenoble, France, 1986. IFIP, North Hol-land.[53] W. A. Hunt Jr and B. C. Brock. A formal HDL and its use in the FM9001 veri-�cation. Philosophical Transactions of the Royal Society of London | Series A:Mathematical and Physical Sciences, 1992.[54] G. Hutton. The Ruby Interpreter. Chalmers University of Technology,G�oteborg, Sweden, Mar. 1993.[55] IEEE, IEEE Computer Society Press. IEEE Standard VHDL Language Refer-ence Manual, 1988.[56] S. D. Johnson and B. Bose. DDD | A System for Mechanized Digital SystemDesign Derivation. In [1].[57] S. D. Johnson, R. M. Wehrmeister, and B. Bose. On the Interplay of Synthesisand Veri�cation | Experiments with the FM8501 Processor Description. In[20].[58] G. Jones and M. Sheeran. Circuit Design in Ruby. In [87], chapter 1, pages13{70.[59] T. Larsson. A Formal Hardware Description and Veri�cation Method. PhD the-sis, Department of Computer and Information Science, University of Link�oping,S-581 83 Link�oping, Sweden, Oct. 1989.[60] U. Lauther. Introduction to Synthesis. In [69], chapter 1, pages 1{14.[61] R. Lipsett, C. Schaefer, and C. Ussery. VHDL: Hardware Description andDesign. Kluwer Academic Publishers, Norwell, Massachusetts, United States,1989.[62] A. J. Martin. Synthesis of Asynchronous VLSI Circuits. In [87], chapter 6,pages 237{284. 117

[63] E. M. Mayger and M. P. Fourman. Integration of Formal Methods with SystemDesign. In A. Halaas and P. Denyer, editors, VLSI91, Edinburgh, Scotland,1991. Elsevier.[64] M. McFarland. A practical application of veri�cation to high-level synthesis.In [1].[65] M. C. McFarland and A. C. Parker. An Abstract Model of Behavior for Hard-ware descriptions. IEEE Transactions on Computers, C-32(7):621{637, July1983.[66] M. C. McFarland, A. C. Parker, and R. Camposano. The High-Level Synthesisof Digital Systems. IEEE, 78(2):301{318, Feb. 1990.[67] T. F. Melham. Abstraction Mechanisms for Hardware Veri�cation. InG. Birtwistle and P. A. Subrahmanyam, editors, VLSI Speci�cation, Veri�-cation and Synthesis, pages 267{291, Norwell, Massachusetts, United States,1988. Kluwer Academic Publishers.[68] T. F. Melham. Formalizing Abstraction Mechanisms for Hardware Veri�cationin Higher Order Logic. PhD thesis, University of Cambridge, Computer Labo-ratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England,Aug. 1990. Technical report no.201.[69] P. Michel, U. Lauther, and P. Duzy, editors. The Synthesis Approach to DigitalDesign. Kluwer International Series in Engineering and Computer Science.Kluwer Academic Publishers, Norwell, Massachusetts, United States, 1992.[70] G. J. Milne. CIRCAL and the Representation of Communication, Concur-rency and Time. ACM Transactions on Programming Languages and Systems,7(2):270{298, Apr. 1985.[71] R. Milner, M. Tofte, and R. Harper. The De�nition of Standard ML. MITPress, Cambridge, Massachusetts, United States, 1990.[72] J. Morison and M. Hill. A formal de�nition of the static semantics of ella's core.Technical Report 91024, Royal Signals and Radar Establishment, St AndrewsRoad, Great Malvern, Worcstershire WR14 3PS, England, Aug. 1991.[73] B. Moszkowski. Executing Temporal Logic Programs. Technical Report 71,University of Cambridge, Computer Laboratory, New Museums Site, PembrokeStreet, Cambridge CB2 3QG, England, Aug. 1985. full version.[74] B. Moszkowski. A Temporal Logic for Multilevel Reasoning about Hardware.IEEE Computer, pages 10{19, Feb. 1985.[75] P. Naish and P. Bishop. Designing Asics. Ellis Horwood Series in Electricaland Electronic Engineering. Ellis Horwwod, Chichester, England, 1988.118

[76] P. Narendran and J. Stillman. Formal Veri�cation of the Sobel Image Pro-cessing Chip. In Proceedings of the 25th Design Automation Conference, pages211{217, Anaheim, CA, United States, June 12{15, 1989 1988.[77] J. Ostro�. Real-time temporal logic decision procedures. In Proceedings of the10th IEEE Real-time Systems Symposium, pages 92{101. IEEE, IEEE Com-puter Society Press, Dec. 1989.[78] L. C. Paulson. Logic and Computation: Interactive Proof with Cambridge LCF,volume 2 of Cambridge Tracts in Theoretical Computer Science. CambridgeUniversity Press, Cambridge, England, 1987.[79] Z. Peng. A Formal Methodology for Automated Synthesis of VLSI Systems.PhD thesis, Department of Computer and Information Science, University ofLink�oping, S-581 83 Link�oping, Sweden, Dec. 1987.[80] L. Pierre. From a HDL Description to Formal Proof Systems: Principles andmechanization. In [6], pages 1{21.[81] S. Rajgopal, K. Hedlund, and D. Reeves. Integrating Hardware Veri�cationwith CHDLs. In [6], pages 133{143.[82] L. Rossen. Formal Ruby. In [87], chapter 4, pages 179{190.[83] D. A. Schmidt. Denotational Semantics A Methodology for Language Develop-ment. Wm. C. Brown Publishers, Dubuque, Iowa, United States, 1988.[84] M. Sheeran. �FP, an algebraic VLSI design language. In Proceedings of theACM Symposium on LISP and Functional Programming, 1984.[85] SRI International, Cambridge Research Center, Millers Yard, Mill Lane, Cam-bridge CB2 1RQ, England. The HOL System, 2nd edition, 1991.[86] J. Staples and P. J. Robinson. Formalising a hierarchical structure of practicalmathematical reasoning. Journal of Logic and Computation, to appear.[87] J. Staunstrup, editor. Formal Methods for VLSI Design. IFIP WG 10.5 LectureNotes. North Holland, Amsterdam, The Netherlands, 1990.[88] J. Staunstrup and M. R. Greenstreet. Synchronized transitions. In [87], chap-ter 2, pages 71{128.[89] V. Stavridou, S. M. Eker, and S. Aloneftis. FUNNEL: A CHDL with Formal Se-mantics. In Proceedings of the Advanced workshop on Correct Hardware DesignMethodologies, Berlin, Germany, 1989. CHARME, Springer-Verlag.[90] D. Suk. Hardware synthesis in constructive type theory. In G. Jones andM. Sheeran, editors, Proceedings of the Workshop on Designing Correct Cir-cuits, Workshops in Computing, pages 29{49, Oxford, England, 1990. Springer-Verlag. 119

[91] L. Th�ery. Real Theorem Provers Need Real Interfaces. In The �fth ACMconference on Software Development Environments, Washington D.C., UnitedStates, Dec. 1992. ACM.[92] L. Th�ery. An X-window interface for the window inference system. Unpublishedmaterial, 1992.[93] D. E. Thomas and P. Moorby. The Verilog Hardware Description Language.Kluwer Academic Publishers, Norwell, Massachusetts, United States, 1991.[94] G. Umbreit. Providing a VHDL-Interface for Proof Systems. In Proceedings ofthe European Design Automation Conference, pages 698{703, Hamburg, Ger-many, 1992. IEEE Computer Society Press.[95] J. P. Van Tassel. A Formalization of the VHDL Simulation Cycle. TechnicalReport 249, University of Cambridge, Computer Laboratory, New MuseumsSite, Pembroke Street, Cambridge CB2 3QG, England, Mar. 1992.[96] X. Wang and E. P. Stabler. Formalization of VHDL Synthesis Procedure inHigher-Order Logic. In [98], pages 106{120.[97] D. Weise. Constraints, Abstraction and Veri�cation. In M. Leeser and G. M.Brown, editors, Proceedings of Workshop on Hardware Speci�cation, Veri�-cation and Synthesis: Mathematical Aspects, Cornell University, Ithaca, NewYork, United States, 1989. Springer-Verlag.[98] P. J. Windley, M. Archer, K. N. Levitt, and J. J. Joyce, editors. The Proceed-ings of the International Tutorial and Workshop on the HOL Theorem ProvingSystem and its Applications, University of California at Davis, United States,Aug. 1991. ACM/IEEE, IEEE Computer Society Press.[99] M. Yoeli. Formal Veri�cation of Hardware Design. IEEE Computer SocietyPress, Los Alamitos, California, United States, 1990.120

Index�Fp, 14Boyer-Moore, 38Ccs, 15Circal, 38Circuit-Lisp, 14CONNECT LINE TRANS, 80constraint, def., 41Ctl, 38Ddd, 14design annotation, def., 42, 47design annotation query, def., 50design annotation update, def., 47design check encapsulation, def., 51design process, def., 47design speci�cation, def., 41design state, def., 47design step, def., 47design theorem, def., 47design transform, def., 47device, def., 42drain, def., 42Ella, 7, 9Hol, i, 2{4, 9, 12, 13, 15, 17{23, 27,29, 33, 37{41, 49, 52, 58, 64,77, 88, 105, 107, 109INIT MUX TRANS, 92input, def., 42INST TRANS, 65INTRO CONST TRANS, 99INTRO LINE TRANS, 77INTRO PRED TRANS, 90INTRO TRANS, 54, 58INTRO USE DELAY TRANS, 74INTRO USE MUX TRANS, 68

INTRO USE TRANS, 61Isabelle, 13, 14Itl, 38justi�cation theorem, def., 46Lambda, 13Lambda/Dialog, 13, 14, 88Lcf, 17, 38Lcf-Lsm, 17, 38line, def., 42Lp, 38Ml, 2, 3, 17, 18, 20, 22, 23, 49{51, 64,69Nuprl, 13output, def., 42port, def., 42port constraint, def., 67Rrl, 38Ruby, 14Silage, 9, 13, 15Sml, 38source, def., 42spatial port con ict, def., 67spatial port constraint, def., 67Synchronized Transistions, 15, 38temporal port con ict, def., 74temporal port constraint, def., 67Tempura, 38Transe, 14USE TRANS, 60Verilog, 7121

Veritas, 13, 17Vhdl, 7, 9, 13, 14, 85window transform, def., 52window transformation command, def.,52

122