Towards Automatic Formal Verification of Generic Combinational Circuits using HOL

Transcription

1 Towards Automatic Formal Verification of Generic Combinational Circuits using HOL By Sumayya Shiraz 2011-NUST-MS-EE(S)-12 Supervisor Dr. Osman Hasan Department of Electrical Engineering A thesis submitted in partial fulfillment of the requirements for the degree of Masters in Electrical Engineering (MS EE) In School of Electrical Engineering and Computer Science, National University of Sciences and Technology (NUST), Islamabad, Pakistan. (September 2014)

2 Approval It is certified that the contents and form of the thesis entitled Towards Automatic Formal Verification of Generic Combinational Circuits using HOL submitted by Sumayya Shiraz have been found satisfactory for the requirement of the degree. Advisor: Dr. Osman Hasan Signature: Date: Committee Member 1: Dr. Muhammad Murtaza Khan Signature: Date: Committee Member 2: Dr. Rehan Hafiz Signature: Date: Committee Member 3: Dr. Amir Ali Khan Signature: Date: i

3 Dedication To My Husband Parents Brothers and Parents-in-law ii

4 Certificate of Originality I hereby declare that this submission is my own work and to the best of my knowledge it contains no materials previously published or written by another person, nor material which to a substantial extent has been accepted for the award of any degree or diploma at NUST SEECS or at any other educational institute, except where due acknowledgement has been made in the thesis. Any contribution made to the research by others, with whom I have worked at NUST SEECS or elsewhere, is explicitly acknowledged in the thesis. I also declare that the intellectual content of this thesis is the product of my own work, except for the assistance from others in the project s design and conception or in style, presentation and linguistics which has been acknowledged. Author Name: Sumayya Shiraz Signature: iii

5 Acknowledgment First and foremost, I would like to thank almighty ALLAH, the most merciful and beneficent. I would like to express my gratitude to my supervisor Dr. Osman Hasan, for his guidance, support and encouragement throughout my thesis. He is always been helpful and approachable. His knowledge about formal methods and research have helped me a lot in my thesis. I would also like to acknowledge the help of my lab fellows especially Muhammad Ahmad and Hira Taqdees. I also wish to express my gratitude to Ayesha Jamil for helping me in creating a graphical user interface for my research work. Most importantly, i would like to thanks my husband for encouraging me throughout my thesis and for believing in me. Finally, i wish to thanks my parents, brothers and parents-in-law for their prayers and support. iv

6 Abstract Efficient verification of digital designs is of utmost importance due to their extensive use in many safety-critical applications. In this respect, formal verification has been widely acknowledged to be far better, accurate and efficient as compared to the traditional simulation approach. However, automatic theorem provers and model checking techniques cannot tackle large circuits due to the associated high computational requirements. Interactive theorem provers, using higher-order logic, can overcome these limitations by verifying generic circuits and universally quantified properties but they require explicit user guidance, which makes them quite uninteresting for industry usage. As a first step to overcome these issues, this thesis presents a methodology for the automatic formal verification of arbitrary combinational circuits. The main idea of our methodology is to develop a library of formally verified generic circuits for all the commonly used hardware modules using the HOL theorem prover. This library can then be used to automatically verify the structural view of any combinational circuit against its behavior. Based on the proposed methodology, the user provides the RTL structural view of the given circuit in Verilog along with its desired behavior in simple C language and, in case of their equivalence, automatically gets the corresponding formally verified gate level Verilog code. For illustration purpose, the proposed methodology has been used for the verification of many combinational circuits, including a v

7 vi 24-bit adder/subtractor, the 8-bit shifter module of benchmark circuit c3540, the 17-bit EqualZ W module of benchmark circuit c2670, a 16:1 Multiplexer circuit using a 4:16 Decoder and a 512-bit Multiplier circuit.

8 Table of Contents 1 Introduction Motivation Literature Review Assertions Computer Algebra Combinational Equivalence Checking Model Checking Automated Theorem Proving Interactive Theorem Proving Hybrid Techniques Problem Statement Proposed Methodology Thesis Contributions Organization of Thesis Preliminaries Theorem Proving HOL Theorem Prover Terms Types vii

9 TABLE OF CONTENTS viii Inference Rules Theorems Theories Proofs in HOL HOL Notations Formalization of Generic Library Logic Gates Multiplexer Decoder Demultiplexer Encoder Ripple Carry Adder Carry Select Adder Multiplier Graphical User Interface AFVGCC Interface Starting a New Project Path Selection Implementation of the design Desired behavior or specification of the design Steps for Verification Manual Steps for Verification Automatic Steps for Verification Final Output of the Tool Saving a theorem Saving a code

10 TABLE OF CONTENTS ix Interactive Environment Translators Implementation Translator Specification Translator Case Studies bit Adder/Subtractor bit Shifter Module of Benchmark Circuit c bit EqualZ W Module of Benchmark Circuit c :1 Multiplexer bit Multiplier Conclusion and Future Work Conclusion Future Work

11 List of Figures 1.1 Proposed Methodology Recursive Implementation of n:1 Mux Implementation of 2:1 MUX Recursive Implementation of n:2 n Decoder Implementation of 1:n Demultiplexer Recursive Implementation of 2 n :n Encoder Implementation of encod 2to Recursive Implementation of n-bit Adder Implementation of 1-bit Ripple Carry Adder Implementation of 1-bit Carry Select Adder Recursive Implementation of n-bit Multiplier Implementation of 1-bit Multiplier Graphical User Interface GUI combox-box GUI Interface for Entering Specification GUI Interactive Environment Implementation of 24-bit Adder/Subtractor Implementation of the 8-bit Shifter Module of c x

12 LIST OF FIGURES xi 5.3 Implementation of the 17-bit EqualZ W Module of c Implementation of a 16:1 Multiplexer Implementation of a 512-bit Multiplier

13 Chapter 1 Introduction 1.1 Motivation Verification of digital designs is of utmost importance due to the heavy costs of undetected bugs and their extensive usage in many safety-critical domains, such as health and transportation. Various examples of huge loss, including the loss of precious life, caused by undetected bugs in digital designs includes software bug in the cancer therapy machine Therac, that led to three severe cases of injuries and three deaths between 1985 and 1987, the famous Pentium bug [6], which resulted in the financial loss of about 500 million US$ to Intel due to system recalls in 1994 and loss of about 370 million US$ dollars, which has resulted due to engines shut down prior to landing of Mars Polar Lander in Keeping in view all the above mentioned losses, digital designs are need to be thoroughly tested and verified before deployment. Traditionally, digital designs are verified using simulation, which ascertains the correctness of the design by observing the behavior of the circuit under a subset of all possible inputs. But due to the inability to perform exhaustive simulation for large circuits and scalability issues, it cannot guar- 1

14 CHAPTER 1. INTRODUCTION 2 antee accurate analysis [13] and hence is not suitable for the efficient and accurate verification of digital designs. Formal verification [22] is an accurate alternative to simulation that overcomes its limitations by proving or disproving the correctness of the given design against its desired properties mathematically. The main principle behind formal analysis of a digital circuit is to construct a computer based mathematical model of the given circuit and formally verify, within a computer, that this model meets rigorous specifications of intended behavior. Thus, the engineer working with a formal methods based verification tool has to develop a formal model of the given circuit and the formal specification of the desired properties. Moreover, she may be involved in the verification task as well. There are some formal verification tools, mainly based on model checking [10] and automated theorem proving techniques [15], that accept Verilog models and automatically translate them to the corresponding formal models and also automatically verify the relationship between the formal model and its corresponding specification. Thus, the verification engineer has to be involved in the formal specification of the properties only. These kind of tools, such as FormalPro by Mentor Graphics, Conformal by Cadence and Formality by Synopsys, are quite well-suited for the industrial setting and are thus widely accepted by the industry as well. However, they have a somewhat limited scope and scalability issues. For example, model checking is generally limited to sequential circuits and also suffers from the well-known state-space explosion problem. Similarly, automated theorem provers cannot cope with the verification problems of large designs as well, due to an exponential increase in computations with an increase in the number of variables and intermediate nodes. Interactive theorem provers [15], using the expressive higher-order-logic, can overcome these

15 CHAPTER 1. INTRODUCTION 3 short comings but at the cost of explicit user involvement. The verification engineer needs to manually construct a logical model of the system and then verify the desired properties while guiding the theorem proving tool. This could be a very rigorous process and the user needs to be an expert in both system design and theorem proving skills. This drawback limits the usage of higher-order-logic theorem proving in the mainstream hardware industry where the engineers prefer to have push-button type tools. The main scope of this thesis is to facilitate the usage of an interactive theorem prover for the verification of combinational circuits by minimizing the user involvement. In this regard, we propose a methodology that calls for developing a library of formally verified generic circuits of commonly used components, such as various implementations of n-bit Adders, n:1 Multiplexers, 1:n Demultiplexers, n:2 n Decoders, 2 n :n Encoders and n-bit logic gates. This verification would be done interactively but would be transparent to the user of our methodology. The user would provide the structure of the given circuit in terms of its sub-components in the Verilog language along with the desired property, in simple C language. Both of these two descriptions are then automatically translated to the language supported by the HOL theorem prover with the help of translators developed in C#. After this translation, the relationship between the structural view and the behavior of the given circuit can be verified using the library of formally verified generic circuits automatically. Moreover, our methodology also provides the flexibility to automatically generate the complete gate-level Verilog code for the desired circuit, similar to the concept of formal synthesis [34]. Thus, the user of our methodology can leverage upon the strengths of interactive theorem proving without being involved in the manual translation and verification tasks. We have used the HOL theorem prover [16] as our proof assistant due

16 CHAPTER 1. INTRODUCTION 4 to its long term relationship with hardware verification [13]. 1.2 Literature Review There is a plethora of research available in the formal verification of hardware designs in the last two decades and the area primarily got a huge interest due to the infamous intel pentium s bug [6] in mid 1990s. We have classified these in terms of the formal verification techniques Assertions In assertion based verification, assertions are used in conjunctions with simulation to formally express and verify the required behavior of the hardware [1]. This approach has been found to be way faster than the regular simulation and has been used to develop a language HDVL for both designing and verifying a system using assertions [21]. Assertions have been found to be very helpful for debugging industrial level FPGA designs [24]. But due to the simulation based verification, the results cannot guaranteed to be complete and there is always a risk of missing the test case that reveals the bug Computer Algebra Computer algebraic algorithms have also been used to verify many combinational circuits - Galois Field arithmetic circuits [18], arithmetic datapaths [29], arithmetic circuits [47] and Galois Field multipliers [17]. The good thing about these algorithms is the fact that the analysis is done symbolically and thus there is no risk of missing test cases. However, the simplification algorithms themselves may contain bugs and thus the results cannot be termed as 100% reliable.

17 CHAPTER 1. INTRODUCTION Combinational Equivalence Checking Combinational equivalence checking using various automatic techniques - SAT solver [3,9], FSM traversal and random simulation [3], BDD and boolean satisfiability [37] and model checking [41] - has been extensively used to check if two circuits produce the same output or not. But our scope is checking the circuit against its required specification, which is quite different than the equivalence checking Model Checking The main strength of model checking is to automatically and exhaustively verify temporal properties for finite state machines and hence is mainly used to verify sequential circuits and communication protocols. The SMV model checker is used to verify IEEE double precision floating point adders of the Aurora III chip [48]. A very scalable system-level hardware verification methodology is described in [26] and the main idea is to reduce the verification goal of a large systems into a finite number of subgoals, which are then discharged using the SMV model checker. Multi-agent systems are verified using model checking via Ordered Binary Decision Diagrams [11]. A generic model checking based tool is developed for the verification of protocols and reactive systems written in C, C++, Java, Verilog and VHDL [7]. The bounded model checking technique allows to somewhat cater for the inherent state-space explosion problem [10] of model checking. Thus, large digital designs, such as C and Verilog programs [8], Alpha microprocessor [30] and an implementation of an Asynchronous Transfer Mode (ATM) network switching module [46] have been verified using the NuSMV tool. Despite the successes of model checking in hardware verification, its scope is limited to

18 CHAPTER 1. INTRODUCTION 6 sequential circuits only due to its inherent nature. The scope of the thesis is to use higher-order-logic theorem proving to overcome this problem and thus the proposed methodology can work in conjunction with model checking to accurately verify complete hardware designs, including both combinational and sequential components Automated Theorem Proving In theorem proving or automated reasoning [15], the system that needs to be analyzed is mathematically modeled in an appropriate logic and the properties of interest are verified using computer based formal tools. The core of theorem provers usually consists of some well-known axioms and primitive inference rules. Soundness is assured as every new theorem must be created from these basic axioms and primitive inference rules or any other already proven theorems. The first-order-logic theorem prover ACL2 has been widely used to verify digital circuits. Due to the underlying first-order logic, ACL2 cannot be used to reason about higher-order-logic terms and thus is limited in terms of expressiveness. In order to alleviate this problem, ACL2 has been used in conjunction with symbolic simulation for verifying hardware [12] and VIA nano microprocessor components [44]. However, using symbolic simulation compromises the completeness of the analysis and thus accuracy. Similarly, ACL2 has also been used with IBMs SixthSense model checker [19, 20] to develop a hybrid verification framework for digital hardware. But the scalability of this technique is a major concern since the state transition checks grow exponentially for large circuits and thus the automatic verification capability is compromised.

19 CHAPTER 1. INTRODUCTION Interactive Theorem Proving Interactive theorem provers, using higher-order logic, can overcome the limited expressiveness problem of ACL2. Thus, PVS has been used for the verification of some large designs, including some FPGA designs [14] and the floating point unit used in the VAMP processor [4], which supports addition, subtraction, multiplication, division, comparison, and conversions. Similarly, a hardware verification tool, called PROVERIFIC [32], allows PSL assertions to be used with PVS. All the above-mentioned works require the hardware circuit description to be translated to PVS syntax manually and also explicit user guidance in the proof process. Moreover, these works are dedicated towards a particular circuit and are thus not generic. The Coq theorem prover is based on the Calculus of (Co)Inductive Constructions (CiC) and features dependent types, which are quite helpful in creating reliable circuit models as errors can be caught earlier by type checking [40]. However, automatic proof generation by Coq is quiet limited as powerful logics are harder to use and require a lot of expertise. Braibant [40] has created a library in Coq to facilitate modeling and verifying hardware circuits. Although dependent types, available in this library, are helpful in creating reliable definitions, the library is not helpful in automation and still requires the user to guide the proof tools, which somewhat limits the scope of this work for industrial usage. A step-by-step procedure for the formal verification of a multiplier in CiC is given in [5]. But this work also lacks automation and is specific for one example only. The HOL theorem prover has been used for the verification of the SPW Data-strobe (DS) encoding [23] and multiway decision graphs (MDG) components library [31]. Both of these works are application specific. Also the conversion of Verilog to formal language is done manually in the DS encoding

20 CHAPTER 1. INTRODUCTION 8 verification [23] Hybrid Techniques Many hybrid techniques, based on the idea of exploiting the strengths of interactive theorem proving and automatic verification tools, have been developed as well. The HOL theorem prover has been integrated with MDG for hardware verification [36, 42]. Similarly, the Pipelined Double-Precision IEEE Floating-Point Multiplier is verified by the Voss hardware verification system using a combination of theorem proving and model checking [27]. The Floating point divider unit of an Intel IA-32 microprocessor has been formally verified using the Forte framework, which uses ThmTac theorem-prover and the symbolic trajectory model checker [33]. The COSPAN model-checker and the TLP theorem prover are used to verify a multiplier of 64-bits and beyond [35], but in this work the translation between the languages of TLP and COSPAN is done manually, which makes the verification process quite cumbersome. All the above works are focused on one or a subset of combinational circuits. Similarly, due to their hybrid nature they are not completely automatic and also suffer from the state-space explosion problems. One of the main focuses of our work is to automatically translate hardware description languages (HDLs) to a formal language without any user involvement. At Centaur Technology, automatic translation of RTL Verilog code is done to EMOD, which is then formally verified using the ACL2 theorem prover [45]. Another translator [43], converts a HDL to the input format of the ACL2 theorem prover. Another commonly used automatic translator from Verilog to a formal model is also provided in [2]. This work utilizes the ACL2 theorem prover along with some special-purpose tools (SAT, BDD and ABC) outside ACL2 for verification. However, all the above mentioned

21 CHAPTER 1. INTRODUCTION 9 works are limited to circuits that can be described in first-order logic and the verification support is specific for one or a very small subset of combinational circuits. A VHDL to HOL translator and verifier, V-HOLT Verifier [28], has been developed based on the VHDL to XML converter tool VSYML. The tool has been used to automatically translate and verify some basic gate-level circuits but it cannot cater for translating and verifying large RTL circuits. 1.3 Problem Statement Concluding all previous research, to the best of our knowledge, there is no technique or tool available that can automatically and formally verify wide range of generic combinational circuits. Hence, the main goal of our work is to provide a generic methodology that does not require manual Verilog to formal model translation and user-guided verification and can handle a wide range of combinational circuits. To the best of our knowledge, these features are not available in any one of the available hardware verification frameworks. 1.4 Proposed Methodology The proposed methodology, shown in Fig. 1.1, requires two inputs: (i) The Verilog code, depicting the structural connections of various components of the circuit that is needed to be verified and (ii) the specification or the required behavior of the given circuit using the C language syntax. The final output of our methodology, indicated by the purple colored box, is the formally verified Verilog code of the given circuit with full behavioral and structural details. It is important to note here that the main objective of our

22 CHAPTER 1. INTRODUCTION 10 Figure 1.1: Proposed Methodology methodology is to obtain this code in a completely automatic manner or with very minimal user interaction. The grey shaded boxes in the figure depict the core components that facilitate the automatic and generic characteristics of our methodology. We have developed a library of formal definitions and formally verified theorems corresponding to most of the commonly used combinational logic blocks that includes all logic gates, n-bit Ripple Carry Adder, n-bit Carry Select Adder, n-bit Multiplier, n:2 n Decoder, 2 n :n Encoder, n:1 Multiplexer and 1:n Demultiplexer by building upon the Boolean, Arithmetic and List theories of the HOL theorem prover. All these definitions and theorems are generic and hence can be used for the formal verification of any type of the circuit irrespective of its size and complexity. It is important to note here that the verification of these generic circuits required explicit user guidance. But once verified, the corresponding formally verified theorems facilitate the automatic verification of most of the combinational

23 CHAPTER 1. INTRODUCTION 11 circuits that can be constructed in terms of these formally verified modules. Moreover, it must also be highlighted here that this library can be extended by the library vendors to include more foundational components and their area/performance efficient implementations to broaden the verification scope of our methodology. This idea is kind of inherited from the concept of standard cell based ASIC designs, where the various standard cells are developed by the library vendors and the ASIC designers can then use the standard cells to construct their ASIC designs. The first step of the proposed methodology is to automatically translate the given Verilog structural code to its corresponding formal description in the HOL syntax. In a similar way, the circuit behavior, specified in C syntax, is also translated automatically to the formal specification of the circuit in HOL. The translators, developed in C#, are used for this purpose. The second step is to formally verify that the given circuit implies the specification given by the user. In order to facilitate the automatic verification based on the formally verified library of generic circuit models, we have also developed some tactics and reasoning methods. Thus, in most of the cases, the verification is done in an automatic, push-button, style. The exceptions happen when the specification is given as a complex arithmetic expression, which does not have a very straightforward relationship with the structure. In these cases, the user is prompted with the ongoing proof steps and the problem can be resolved either by updating the specification and proceeding with the automatic proof or by guiding the tool for the proof in the traditional interactive theorem proving style. However, these cases seldom arise and the approach concludes with the automatic verification in most of the cases, as will be illustrated by the case studies performed as part of this work. Finally, upon the successful verification, the user gets two outputs from our

24 CHAPTER 1. INTRODUCTION 12 system (i) the formal proof of system properties that specify that given circuits code implies the specification given by the user and (ii) the formally verified Verilog code of the given circuit. The main difference between this Verilog code and the input Verilog code of the circuit, given by the user, is the inclusion of the gate-level behaviors of all the components of the circuit in the former. This behavior information is obtained from the generic Verilog codes of all the formally verified components, which is also a component of the proposed methodology, indicated by the orange colored box in Fig The distinguishing features of the proposed methodology include its acceptance and generation of Verilog codes and automatic formal verification, using a sound higher-order-logic theorem prover. The translators and a library of formally verified generic combinational circuits, described in the next sections, hold the key role in achieving these goals. 1.5 Thesis Contributions The main contributions of this research work is to create a methodology for the automatic verification of generic combinational circuits. The proposed methodology have the capability to accurately verify any combinational circuit irrespective of its size and complexity. The contributions are summed as follows: Formally verified library of generic combinational circuits is developed. This library allows to formally specify and verify higher-order logic theorems corresponding to various properties of any combinational circuits. Automatic translation of HDLs to formal language is provided by our methodology which saves the user from a lot of manual effort.

25 CHAPTER 1. INTRODUCTION 13 Some helping tactics have also been formalized to help in automation of verification of combinational circuits. Our methodology allows user to use any module of verified combinational circuits without describing its behaviour details which is automatically generated in the end on successful verification. User friendly GUI is created so that user having no prior knowledge of formal methods can verify any circuits easily. The utilization and effectiveness of the proposed methodology is illustrated by automatically verifying a number of real-world combinational circuits like a 24-bit adder/subtractor, the 8-bit shifter module of benchmark circuit c3540, the 17-bit EqualZ W module of benchmark circuit c2670, a 16:1 Multiplexer circuit using a 4:16 Decoder and a 512-bit Multiplier circuit. 1.6 Organization of Thesis The rest of the thesis is organized as follows. In Chapter 2, a brief introduction to the HOL theorem prover is given. Chapter 3 describes the formal verification of most commonly used generic combinational circuits in HOL. The structure and working of graphical-user-interface for the proposed methodology along with the translators developed for automatic conversion of inputs to HOL language are explained in Chapter 4. In order to demonstrate the practical usefulness of the proposed methodology, five case studies namely 24-bit adder/subtractor, the 8-bit shifter module of benchmark circuit c3540, the 17-bit EqualZ W module of benchmark circuit c2670, a 16:1 Multiplexer circuit using a 4:16 Decoder and a 512-bit Multiplier have been

26 CHAPTER 1. INTRODUCTION 14 presented in Chapter 5. Lastly, Chapter 6 concludes the thesis and points out some future research areas.

27 Chapter 2 Preliminaries This chapter provides with a basic overview of the HOL theorem prover. The aim is to introduce the basic working knowledge of the notations and terms in HOL which are used in the theories. 2.1 Theorem Proving Theorem proving is a formal hardware verification technique which is used to construct and verify mathematical theorems using computer program. Depending upon the requirements of expressibility, the mathematical theories can be build upon various types of logic, such as, first-order logic, propositional logic, or higher-order logic. Keeping in view the increase in complexity of designs now-a-days, it is always better to use higher-order logic as it provides more quantifiers and is more expressive as compared to others. This expressive nature of higher-order logic helps in describing any complex design easily which is not possible using first-order or propositional logics. Every theorem prover core constitutes of some well axioms and inference rules. Soundness is assured by theorem provers as every new theorem must be cre- 15

28 CHAPTER 2. PRELIMINARIES 16 ated from the basic axioms and primitive inference rules or any other already proven theorems and already proven inference rules. Theorem proving can further be subdivided into two types i.e., automated theorem proving and interactive theorem proving as described in Chapter 1. Automated theorem provers automatically translate Verilog models to the formal models and then verify them against the desired specification while interactive theorem provers are used to manually construct formal model which are then verified with user interaction. Some well known automatic theorem provers are MetiTarski, ACL2 and Otter [?]. Interactive theorem prover includes HOL, HOL-Light, Isabelle, Coq, PVS and MIZAR [?]. This thesis make use of HOL theorem prover to formalize and verify generic combinational circuits. We have selected HOL theorem prover as it is equipped with rich mathematical theories, provides high degree of programmability and expressiveness and have a long term relationship with hardware verification [13]. 2.2 HOL Theorem Prover HOL theorem prover [16] is a widely-used computer program that provides an interactive environment for the construction and verification of mathematical proofs in higher-order logic. It provides high degree of programmability through the programming language ML-Meta language [?]. It was developed by Mike Gordon at Cambridge University, in 1980s. It utilizes the Church s simple type theory [?] and Hindley-Milner polymorphism [?] to implement higher-order logic. The first version of HOL is called HOL88 and other versions of HOL are HOL90 and HOL98. HOL4 is the latest version of HOL family, which uses Moscow ML which is an implementation of Standard ML

29 CHAPTER 2. PRELIMINARIES 17 (SML). The HOL core consists of only 5 basic axioms and 8 primitive inference rules. HOL theorem prover has been widely used for the hardware verification [13] Terms HOL theorem prover provides us with four types of terms i.e., constants, variables, lambda-terms and function applications. Variables are denoted by using a sequence of digits or letters beginning with a letter for e.g. a, spec 1, make F. The variables are needed to be bounded by the quantifiers depending upon which theory they belong to. Constant are denoted similar to that of variable with the difference that they are not bounded by quantifiers. Function applications are used for computing any function f at any argument x. λ-terms also known as lambda abstractions are used for representing functions. λx.f(x) is representing a function which has an argument x and will return f(x) Types Every term defined in HOL must have a type. This type can be one of the basic types or it can be the outcome of applying a type constructor to the already defined types. Type must be defined for every constant or variable used. Two variables with same name but different type can also be used. In this case both will be considered as two different variables. Type checking algorithm of HOL infer a type whenever any term is entered. Type of the term can be inferred explicitly, if HOL is not able to deduce it automatically e.g (x : real) or (x : complex).

30 CHAPTER 2. PRELIMINARIES Inference Rules Inference rules are represented as ML functions and they are used for deriving new theorems. HOL provides with a set of eight primitive inference rules, which are then used to derive any new theorem. These inference rules are Reflexivity, Assumption introduction, Substitution, Abstraction, Beta-conversion, Type instantiation, Modus Ponens and Discharging an assumption Theorems A theorem is a formal statement that can be an axiom or it follows from theorems by an inference rule. A theorem consists of a finite set of boolean terms Ω called assumptions and a boolean term S called the conclusion. Then theorem created from this assumption and conclusion is written in HOL as Ω S. Any new theorem must be build upon the already proved theorems thus satisfying the inference rules presented above Theories A HOL theory comprises of a set of type, type operators, constants, definitions, axioms and proved theorems. Each theory consists of verified theorems which are verified using already proven theorems or inference rules. This is how soundness is assured by theorem prover. User can benefit from the available definitions and theorems by loading the theories. This helps in eradicating the duplication of the work already done and hence saves user time and effort. In this thesis HOL theories of Boolean, Arithmetic and List are utilized. In fact, one of the reason to select HOL theorem prover was to make use of these already formalized theories.

31 CHAPTER 2. PRELIMINARIES Proofs in HOL In order to verify any proof in HOL, two approaches can be followed: forward and backward approach. In the forward approach, user starts from the inference rules and reach the desired goal building upon them using already proved theorems and inference rules. It is not an easy approach since it requires an extensive knowledge of the theories in advance. In the backward or reverse approach user starts from the goal and simplifies it by splitting it into smaller subgoals using already proved theorems and primitive inference rules. By proving all subgoals, main goal is verified. There are many automatic tactics provided by HOL which helps in simplifying the goal while other proof steps can be verified through user interaction HOL Notations The Table 2.1 provides the mathematical interpretation of some HOL functions and symbols used in the thesis. These notations will be used in the formalization to come in the later chapters. The purpose to mention them here is to get the reader handsomely equipped with the terminologies to come in the thesis.

32 CHAPTER 2. PRELIMINARIES 20 Table 2.1: HOL Symbols and Functions HOL Symbol Standard Symbol Meaning /\ and Logical and \/ or Logical or not Logical negation ==> Implication <==> = Equality!x.t x.t for all x : t?x.t x.t for some x : ɛx.t an x such that : t λx.t λx.t Function that maps x to t(x) SUC n (n + 1) Successor of natural number EXP x e x Exponential function

33 Chapter 3 Formalization of Generic Library This Chapter explains the grey shaded blocks of the proposed methodology, given in Fig Each one of these boxes except the logic gates corresponds to four components: 1. a formal recursive definition in HOL to cater for any number of inputs 2. a formal specification of the behavior of the given module 3. the proof goal statement relating the definitions, obtained from the first two components, along with the required assumptions (if any) 4. the formal proof of the above goal using the HOL theorem prover. 3.1 Logic Gates In this section, we describe the formal definitions for all of the primitive logic gates. All definitions, except the inverter, are generic and thus they can be used to model the respective gate of any number of inputs. 21

34 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 22 Definition 1: NOT gate a out. not a out = (out = a) the function not accepts two boolean variables as input and returns a T rue if the two are linked with the inverter behavior. Definition 2: n-bit AND gate AND [] = T h t. AND (h::t) = (h (AND t)) a out. and n a out = (out = AND a) The first function, AND recursively performs the logical and between all the elements of a boolean list. The second function and n describes the behavior of the n-bit and gate in the predicate form. In the above definitions, h::t refers to a list with h as its head and t as its tail. The NAND gate can now be formalized using the negation of the AND gate as: Definition 3: n-bit NAND gate a out. nand n a out = (out = AND a) Just like the AND and NAND gates, OR and NOR gate can also be defined as shown below: Definition 4: n-bit OR gate or [] = F h t. or (h::t) = (h (or t)) h t out. or n (h::t) out = (out = or (h::t))

35 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 23 The first function, or recursively performs the logical disjunction between all the elements of a boolean list. The second function or n describes the behavior of the n-bit or gate in the predicate form. The NOR gate can be formalized by taking complement of OR gate as given below: Definition 5: h t out. n-bit NOR gate nor n (h::t) out = (out = or (h::t)) XOR gate generates an even party and is defined recursively as follows: Definition 6: n-bit XOR gate xor [] = F h t. xor (h::t) = ( (h = xor t)) h t out. xor n (h::t) out = (out = xor (h::t)) The XNOR gate generates an odd party and thus can easily be defined by taking the complement of the final outcome of the XOR gate as: Definition 7: h t out. n-bit XNOR gate xnor n (h::t) out= (out = xor (h::t)) 3.2 Multiplexer The n:1 Multiplexer (Mux) [25] passes the signal of any one of the n input data lines to the one bit output line depending upon the log 2 n input select lines. Fig. 3.1 is depicting the recursive implementation of a generic n:1 Mux, where n is the width of data input lines a, k is the width of select input lines s and b is a boolean output signal. The relation between the width of select and data input lines can be specified by the equation k = log 2 n, or in other

36 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 24 Figure 3.1: Recursive Implementation of n:1 Mux Figure 3.2: Implementation of 2:1 MUX

37 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 25 words n = 2 k. The primitive 2:1 Mux can be implemented using basic logic gates, as shown in Fig. 3.2 and is formally defined in HOL as follows: Definition 8: Implementation of 2:1 Mux in1 in2 sel out. mux imp in1 in2 sel out = p q r. nand n [in1;p] q nand n [sel;in2] r nand n [q;r] out not sel p Definition 9: Implementation of n:1 Mux a b. mux imp n a [] b = (b = HD a) a h t b. mux imp a (h::t) b = p q. mux imp q p h b mux imp n (DROP (HALF a) a) t q mux imp n (TAKE (HALF a) a) t p where the HOL function HD returns the head of the input list, the HOL expression HALF a returns half of the length of the given list a, i.e., (LENGTH a) DIV 2, the HOL expression (TAKE n a) picks the top n elements from the list a, the HOL expression (DROP n a) drops the top n elements from the list a and recursion is done on the input select lines h::t. The next step is to define the behavior (specification) of the 2:1 and n:1 Mux. Definition 10: Specification of 2:1 Mux in1 in2 sel out. mux spec in1 in2 sel out = if sel then (out = in2) else (out = in1) Definition 11: Specification of n:1 Mux a s b. mux spec n a s b = (b = (EL (LENGTH a BV n s) a))

38 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 26 where the HOL expression (EL n a) returns the n th element of its argument list and the function BV n converts its argument boolean list into a number and is defined below as: Definition 12: Conversion of list to number BV n [] = 0 h t. BV n (h::t) = ((2 EXP (LENGTH t)) * BV h + BV n t) where the function BV converts a boolean variable to its corresponding number, i.e, BV b = if b then 1 else 0 [13]. The relationship between the specification and implementation of the 2:1 and n:1 Mux is formally verified in HOL as the following theorems: Theorem 1: Formal Verification of 2:1 Mux in1 in2 sel out. mux imp in1 in2 sel out <=> mux spec in1 in2 sel out Theorem 2: a s b. Formal Verification of n:1 Mux ( (s = []) (LENGTH a = 2 EXP LENGTH s)) (mux imp n a s b <=> mux spec n a s b) The Theorem 1 is used for the formal verification of n:1 Mux. The assumptions in Theorem 2, ensure that there is atleast one select line and the relationship between the input data and input select lines. The formal verification of Theorem 1 is primarily based on induction of variable s. 3.3 Decoder The recursive implementation of a n:2 n Decoder [25], shown in Fig. 3.3, is implemented using two (n-1):2 (n 1) Decoders having input of tail of the

39 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 27 data input line, i.e., a[n-2:0]. Head of the data input line, i.e., a[n-1], in conjunction with a global enable input e enables either of the two Decoders, which then sets the bits of the output signal depending upon the binary number represented by the input data vector. Figure 3.3: Recursive Implementation of n:2 n Decoder Definition 13: Implementation of n:2 n Decoder n e b. decod imp n n e [] b = if e then (HD b= T) else (BV n b= 0) n e h t b. decod imp n n e (h::t) b = q r s. not h q and n [e;q] s and n [h;e] r decod imp n n s t (DROP (HALF b) b) decod imp n n r t (TAKE (HALF b) b)

40 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 28 where n is the width of the output data line. The behaviour of the Decoder is formalized as: Definition 14: n e a b. Specification of n:2 n Decoder decod spec n n e a b = if e then (b = num BV f n (2 EXP BV n a)) else (b = num BV f n 0) where the expression (num BV f n a) is used to convert a number a into a list having n elements as: Definition 15: Conversion of number to list n a. num BV f n a = REVERSE (num BV n a) a. num BV 0 a = [] n a. num BV (SUC n) a = (num2bool (a MOD 2) :: num BV n (a DIV 2)) where the HOL function REVERSE returns the given list in the reverse order, the HOL expression SUC n represents the successor of the variable n, i.e., n + 1 and the function num2bool converts a number to its corresponding boolean value: if (n = 0) then F else T. The relationship between the specification and implementation of the Decoder is formally verified in HOL as following theorem: Theorem 3: Formal Verification of n:2 n Decoder n e a b. (LENGTH b = n LENGTH b = 2 EXP LENGTH a) (decod imp n n e a b <=> decod spec n n e a b) where the assumptions ensure that the length of output data signal is equal to width of the Decoder and the relationship between the data input and the data output vectors.

41 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY Demultiplexer The functionality of Demultiplexer [25] is quite similar to that of the Decoder with the difference that Decoder sets one of the output lines depending upon the input signal while the Demultiplexer transmits the input data to one of the output lines depending upon the input select lines. Fig. 3.4 shows an implementation of the Demultiplexer using a Decoder, where the data input signal of the Demultiplexer a, is connected to the enable signal of the Decoder, the select input signal of the Demultiplexer s, is connected to the data input signal of Decoder and the data output signal of the Demultiplexer b, is connected to the data output signal of Decoder. The relation between the width of select line k, and the width of the data output lines n, can be specified by the equation k = log 2 n, or in other words n = 2 k. Demultiplexer can easily be defined using implementation definition of Decoder as shown below: Figure 3.4: Implementation of 1:n Demultiplexer

42 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 30 Definition 16: n a s b. Implementation of 1:n Demultiplexer dmux imp n n a s b = decod imp n n a s b where n specifies the width of the output data signal. The behaviour of the Demultiplexer is formally defined and verified in HOL as follows: Definition 17: n a s b. Specification of 1:n Demultiplexer dmux spec n n a s b = if a then (b = num BV f n (2 EXP BV n s)) else (b = num BV f n 0) Theorem 4: Formal Verification of 1:n Demultiplexer n a s b. (LENGTH b = n LENGTH b = 2 EXP LENGTH s) (dmux imp n n a s b <=> dmux spec n n a s b) where the assumptions ensure that the length of output data vector is equal to the width of the Demultiplexer and relationship between the output data and the input select vectors. 3.5 Encoder The Encoder [25] generates a binary output code for one bit of input True at a time. There are two discrepancies that may happen with the Encoders, i.e., the output behavior is non-deterministic in the case when more than one input bits are True at a time or all input bits are zero. Priority Encoder [25] resolves these issues, by encoding output on the basis of priority and by using a valid output bit, respectively. Fig. 3.5 presents a recursive implementation of a 2 n :n Priority Encoder using two 2 n 1 :(n-1) Encoders, which encodes on the bases of the highest priority of the input signal, i.e., all other bits of the

43 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 31 input data signal are ignored if the most significant bit of the data input signal is True. Figure 3.5: Recursive Implementation of 2 n :n Encoder The recursive implementation of Encoder is formalized in HOL as: Definition 18: Implementation of 2 n :n Encoder n e a v. encod imp n n e a [] v = if e then if (HD a) then (v = F) else (v = T) else (v = F) n e a h t v. encod imp n n e a (h::t) v = p. encod 2to1 imp e p v h encod imp n n e (TAKE (HALF a) a) t p encod imp n n p (DROP (HALF a) a) t v

44 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 32 where n specifies the width of the output data signal b, e is the enable input signal of the Encoder, p connected with the valid output signal of the first Encoder, is used to enable the second Encoder, when the top half of the input data vector contains all False elements, v is the valid output signal, which indicates the validity of the encoded output data signal, and the function encod 2to1 imp computes the head of the output data signal using NOT, AND gates and a 2:1 Mux as depicted by Fig The formalized definition of the implementation of encod 2to1 is given below: Figure 3.6: Implementation of encod 2to1 Definition 19: Implementation of encod 2to1 e p eo h. encod 2to1 imp e p eo h = x y z. not p x not eo y and n [e;y] z mux imp h x z h

45 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 33 The formal definition of the behavior of the 2 n :n Encoder is defined recursively in HOL as: Definition 20: Specification of 2 n :n Encoder n e b v. encod spec n n e [] b v = if e then (v = T) else (v = F) n e h t b v. encod spec n n e (h::t) b v = if e then if h then ((b = num BV f n (LENGTH t)) (v = F)) else encod spec n n e t b v) else (v = F) Here, variable of recursion is input data lines which are needed to be encoded. In order to simplify the verification of Encoder, the behaviour of the encod 2to1 is formalized and verified in HOL. Definition 21: e p eo h. Specification of encod 2to1 encod 2to1 spec e p eo h = if (e eo) then (if p then h else h) else T Theorem 5: Formal Verification of encod 2to1 e p eo h. encod 2to1 imp e p eo h <=> encod 2to1 spec e p eo h The relationship between implementation and specification of Encoder is verified as following Theorem, where assumptions ensure the relationship between the lengths of the input and output data vectors. Theorem 6: Formal Verification of 2 n :n Encoder n e a b v.(length a = 2 EXP LENGTH b) (LENGTH b = n) (encod imp n n e a b v = encod spec n n e a b v)

46 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY Ripple Carry Adder A recursive implementation of n-bit Ripple Carry Adder [25] is shown in Fig. 3.7, where d1 and d2 are the two data input vectors which are required to be added, cin is the boolean carry input, cout is the boolean carry output and s is the sum output vector of the adder. One bit adder is implemented using the basic logic gates, i.e., XOR, AND and OR gates, as depicted in Fig. 3.8 and is formalized in HOL as: Figure 3.7: Recursive Implementation of n-bit Adder Definition 22: Implementation of 1-bit Ripple Carry Adder a b cin. Adder imp 1 a b cin = [or [AND [xor [a;b];cin];(and [a;b])]; (xor [xor [a;b];cin])] The structure of the n-bit adder can now be formalized in terms of the 1-bit adder as follows:

47 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 35 Figure 3.8: Implementation of 1-bit Ripple Carry Adder Definition 23: Implementation of n-bit Ripple Carry Adder d1 d2 cin. Adder imp 0 d1 d2 cin = [cin] n d1 d2 cin. Adder imp (SUC n) d1 d2 cin = (Adder imp 1 (HD d1) (HD d2) (HD (Adder imp n (TL d1) (TL d2) cin) ++ TL (Adder imp n (TL d1) (TL d2) cin))) n d1 d2 cin sum cout. Adder imp n n d1 d2 cin sum cout = (cout::sum = Adder imp n d1 d2 cin) where the first function Adder imp is adding two data inputs with boolean carry input, the second function Adder imp n describes the behaviour of the first function in the predicate form giving outputs in boolean carry output cout and data output lines sum and the HOL function TL returns the tail of the input list. The variable of recursion is n, which specifies the number of bits of the adder. The behavior of the 1-bit adder can be formally specified

48 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 36 and verified in HOL as: Definition 24: Specification of 1-bit Ripple Carry Adder a b cin. Adder spec 1 a b cin = (num BV f (SUC 1) (BV a + BV b + BV cin)) Theorem 7: Formal Verification of 1-bit Ripple Carry Adder a b cin. Adder imp 1 a b cin <=> Adder spec 1 a b cin The behaviour of the n-bit Ripple Carry Adder is formally defined in HOL as: Definition 25: Specification of n-bit Ripple Carry Adder n d1 d2 cin. Adder spec n n d1 d2 cin = num BV f (SUC n) (BV n d1 + BV n d2 + BV cin) The relationship between the implementation and specification is proved as a theorem, where the assumptions ensure that the lengths of both of the input vectors is equal to width of the adder. Theorem 8: Formal Verification of n-bit Ripple Carry Adder n d1 d2 cin. ((LENGTH d1 = n) (LENGTH d2 = n)) (Adder imp n d1 d2 cin <=> Adder spec n n d1 d2 cin) 3.7 Carry Select Adder The formalization of the Carry Select Adder [25] is quite similar to that of the Ripple Carry Adder since both share the same recursive implementation, shown in Fig The main difference is the implementation of the 1-bit

49 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 37 adder, which is implemented using a Mux and full adder as shown in Fig The idea is to obtain the addition for 1-bit data using two full adders working in parallel for both cases of the carry input, i.e., T and F. The final values for sum and carry-out are chosen based on the input value of carry using a Mux. This behavior can be formalized in HOL as follows: Figure 3.9: Implementation of 1-bit Carry Select Adder Definition 26: Implementation of 1-bit Carry Select Adder a b cin. CSA imp 1 a b cin = [mux (HD (FA a b T)) (HD (FA a b F)) cin ; mux (LAST (FA a b T)) (LAST (FA a b F)) cin] where the HOL function LAST returns the last element of its argument list, the function FA implements the full adder behavior and the function mux implements the 2:1 multiplexer behavior using basic logic gates. The formal definition of the implementation of the n-bit Carry Select Adder using 1-bit

50 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 38 Carry Select Adder is given below, which is quite similar to that of the Ripple Carry Adder: Definition 27: Implementation of n-bit Carry Select Adder d1 d2 cin. CSA imp 0 d1 d2 cin = [cin] n d1 d2 cin. CSA imp (SUC n) d1 d2 cin = (CSA imp 1 (HD d1) (HD d2) HD (CSA imp n (TL d1) (TL d2) cin) ++ TL (CSA imp n (TL d1) (TL d2) cin)) n d1 d2 cin sum cout. CSA imp n n d1 d2 cin sum cout = (cout::sum = CSA imp n d1 d2 cin) where the first function CSA imp is adding two data inputs with boolean carry input and the second function CSA imp n describes the behaviour of the first function in the predicate form. As behaviour of the adder is always same, whether Carry Select Adder is used or Ripple Carry Adder is used, hence same definitions are used for the specification as used for the case of Ripple Carry Adder which are described in Definitions 24 and 25. The 1-bit and n-bit Carry Select Adder are verified in HOL as following Theorems: Theorem 9: Formal Verification of 1-bit Carry Select Adder a b cin. CSA imp 1 a b cin <=> Adder spec 1 a b cin Theorem 10: Formal Verification of n-bit Carry Select Adder n d1 d2 cin. ((LENGTH d1 = n) (LENGTH d2 = n)) (CSA imp n d1 d2 cin <=> Adder spec n n d1 d2 cin) where assumptions ensure that lengths of both of the input data vectors is equal to the width of the adder.

51 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY Multiplier The recursive implementation of a n-bit Multiplier [25] is shown in Fig. 3.10, where each bit of the multiplicand d2, is multiplied one-by-one with the multiplier d1, making partial products, which are then added using a Ripple Carry Adder. Figure 3.10: Recursive Implementation of n-bit Multiplier Definition 28: Implementation of n-bit Multiplier d1. mult imp d1 [] = make list F (LENGTH d1) d1 h t. mult imp d1 (h::t) = mult imp 1 d1 (TAKE (LENGTH d1) (mult imp d1 t)) h ++ DROP (LENGTH d1) (mult imp d1 t) a b p. mult imp n a b p = (p = mult imp a b)

52 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 40 Figure 3.11: Implementation of 1-bit Multiplier where the first function mult imp is multiplying two data inputs, the second function mult imp n describes the behaviour of the first function in the predicate form giving product in data output lines i.e., p, the function mult imp 1 is implementing 1-bit multiplier shown in Fig and the HOL expression (make list F n) returns a list with all logic low elements, having width n, which is defined in HOL as: Definition 29: List with all False Elements make list F 0 = [] n. make list F (SUC n) = (F:: make list F n) The 1-bit Multiplier is implemented using a Ripple Carry Adder and arrays of AND gates, depicted in Fig. 3.11and is defined formally in HOL as:

53 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 41 Definition 30: Implementation of 1-bit Multiplier d1 d2 b. mult imp 1 d1 d2 b = (Adder imp (LENGTH d2) (and array d1 b) d2 F) where the function and array generates an array of AND gates, which takes the conjunction of the entire input list with a boolean input signal. Its structure and behaviour can be formally defined in HOL as: Definition 31: Implementation of and array b. and array [] b = [] h t b. and array (h::t) b = (AND [h;b] :: and array t b) the behaviour of the and array can be formalized in HOL as: Definition 32: Specification of and array a b. and array spec [] b = if b then a else (make list F (LENGTH a)) Based on the above definitions, we verified the n-bit Multiplier using the following specification: Definition 33: Specification of n-bit Multiplier a b. mult spec n a b = (num BV f (LENGTH a + LENGTH b) (BV n a * BV n b)) Theorem 11: Formal Verification of n-bit Multiplier a b. mult imp a b <=> mult spec n a b The main advantage of the results presented in this section, i.e., the formal verification of the universally quantified theorems for the correctness of generic combinational circuits with arbitrary inputs, is the ability to use

54 CHAPTER 3. FORMALIZATION OF GENERIC LIBRARY 42 them for automatically verifying a wide range of combinational circuits, as depicted in Fig This benefit is attained at the cost of extensive usereffort spent in guiding the HOL theorem prover for verifying these theorems. The formalization, presented in this section, took around 7000 lines of HOL code and approximately 12 man-months. A significant amount of time was also spent on identifying the generic implementations of the common combinational circuits that can be expressed recursively. Moreover, the proof sketches of the theorems, presented in this section, could not be obtained in any text and we developed as part of the reported work as well. The proof script, corresponding to the verification of some of the circuits, is available at [38] for download, and the others can also be obtained under a license by contacting the authors.

55 Chapter 4 Graphical User Interface A user-friendly graphical user interface is created for the proposed methodology of Automatic Formal Verification of Generic Combinational circuits (AFVGG). This tool is developed using C# and supports translators that automatically translate the Verilog model of the given RTL circuit under verification and its desired behaviour, given in simple C language, to the formal language supported by the interactive theorem prover HOL. After this automatic translation, the tool automatically verifies the given circuit against its intended behaviour. For this purpose, it utilizes a pre-developed library of formally verified generic circuits of commonly used combinational components, described in chapter 3. The final output of the tool is the complete gate-level Verilog code for the desired circuit, along with a formally verified theorem of its correctness. The brief introduction of the tool along with the translators is described in the next sections. 43

56 CHAPTER 4. GRAPHICAL USER INTERFACE AFVGCC Interface AFVGCC- interface, as depicted in Fig. 4.1, consists of two tabs namely implementation and specification, which are used for describing structural connections of the design under verification and its desired behavior. At the extreme left there are set of buttons for each step of the process. At the bottom there are two tabs namely errors and console, which shows the status of the proof along with the detail of the error, if any. Figure 4.1: Graphical User Interface 4.2 Starting a New Project In order to start the verification of new design, user is required to press new button from the menu given at the left side of the tool.

57 CHAPTER 4. GRAPHICAL USER INTERFACE Path Selection In order to start the tool, it is required to load the libraries and theories of the tool. For this purpose, in the start, user is required to specify the path of the directory where HOL is installed. Path can easily be specified in the text-field provided on the top right corner of the tool, shown in Fig When user presses enter after editing the path, tool starts loading theories of HOL along with the libraries required for the verification. It is important to note that tool will not work, if path is not specified correctly or libraries are not downloaded in the correct folder as described in the installation guide of AFVGCC tool [38]. User will be notified when HOL files are loaded and tool is ready to be used. While tool is loading files, user can enter implementation and desired behavior or specification of the design under verification, as specified in the next sections. 4.4 Implementation of the design For the verification of any design, user is required to provide the structure of the circuit in terms of its sub-components in Verilog format. He can use N-bit logic gates, n-bit Ripple Carry Adder, n-bit Carry Select Adder, n:1 Multiplexers, 1:n Demultiplexers, n:2n Decoders, 2n:n Encoders and n- bit Multipliers for describing the circuit that is needed to be verified. The Verilog code for the implementation of the design can be provided by user in two forms, i.e., either by uploading a text file or by writing the code in the editing space provided by the tool, as shown in Fig Check implementation button at the right side of the menu can be used to check the syntax of implementation which will notify user if any component is wrongly used. The syntax of the code for describing structural description

58 CHAPTER 4. GRAPHICAL USER INTERFACE 46 of the circuit is very much similar to Verilog format, details of which can be found at [38]. 4.5 Desired behavior or specification of the design Next step is to provide the desired behavior or specification of the design under verification, using the combo box provided in the specification tab of the tool. Here, the user is restricted to use some specific keywords and operators, i.e., if else conditional statements, arithmetic and logical operators and concatenation for smooth translation. A combo box, shown in Fig. 4.2, is used for the selection of the type of the statement and clear button can be used to clear the entered specification at any time. The textbox at the bottom of the specification tab displays the result of the command entered by the user step by step. Figure 4.2: GUI combox-box After selection of the type of statement, tool provides the user with text-field depending upon the type of statement i.e., if if statement is pressed from combo-box, it provides the user with two text-fields, one for entering the condition and other for entering the statement under condition, as shown in Fig The user is required to press enter, for confirmation of the text edited in these text-fields, which then is displayed below in the textbox.

59 CHAPTER 4. GRAPHICAL USER INTERFACE 47 Figure 4.3: GUI Interface for Entering Specification 4.6 Steps for Verification User can verify a circuit either by following manual steps of verification or by using automatic approach as described below: Manual Steps for Verification The manual steps for verification are described below: 1. First step is to provide a structural description of the circuit to be verified, in the Verilog format. 2. After that user is required to press convert implementation button from the menu. The syntax of the code will be checked automatically before conversion and in case of any error; user is notified along with the detail, which can be viewed in error tab at the bottom of the tool. 3. Then user is required to provide the desired behavior or specification of the design in simple C language, which can be done in the specification

60 CHAPTER 4. GRAPHICAL USER INTERFACE 48 tab using the combo box. 4. After that user is required to press convert specification button from the menu. 5. Lastly, user is required to press run button from the menu to start the process of verification which will show the final output of the verification Automatic Steps for Verification In order to facilitate the automation and save user form the trouble of remembering sequence of steps, tool also provides the option to compute all the above mentioned steps automatically. For this purpose, verification of a circuit is just a two step process i.e., to provide the structural description of the circuit along with its desired behavior and then to press a verify button from the menu of the tool. 4.7 Final Output of the Tool As a final output, the AFVGCC tool is capable of generating the circuit design with complete behavioral description along with the result of the formal proof. User is notified with the help of pop-up box displaying the result of the proof as Goal Proved and Formally Verified Verilog Code of the Circuit is created or Implementation of the design is not according to the specification described. In the case of successful proof, user is provided with the option of save theorem and save code, while failure of the goal provides with an interactive environment.

61 CHAPTER 4. GRAPHICAL USER INTERFACE Saving a theorem At the end of successful proof, user is provided with the option to save the theorem that the implementation of the circuit implies the specification provided by the user. On pressing this button, tool saves the respective theorem by the name provided by the user Saving a code At the end of successful proof, tool generates the Verilog code of the circuit with complete behavioral description and provides with the option to save the generated code Interactive Environment The interactive environment, shown in Fig. 4.4 is given to user, in the case of the failure of the proof which shows the status of the proof. Figure 4.4: GUI Interactive Environment In this environment, user can view the on-going proof, and can find out the