towards automatic formal veri cation of generic...

Towards Automatic FormalVerification 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)

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

Dedication

To My Husband

Parents

Brothers and Parents-in-law

ii

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 de-

sign and conception or in style, presentation and linguistics which has been

acknowledged.

Author Name: Sumayya Shiraz

Signature:

iii

Acknowledgment

First and foremost, I would like to thank almighty ALLAH, the most merci-

ful 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 Muham-

mad Ahmad and Hira Taqdees.

I also wish to express my gratitude to Ayesha Jamil for helping me in creat-

ing 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

Abstract

Efficient verification of digital designs is of utmost importance due to their

extensive use in many safety-critical applications. In this respect, formal ver-

ification 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

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.

Table of Contents

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Assertions . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.2 Computer Algebra . . . . . . . . . . . . . . . . . . . . 4

1.2.3 Combinational Equivalence Checking . . . . . . . . . . 5

1.2.4 Model Checking . . . . . . . . . . . . . . . . . . . . . . 5

1.2.5 Automated Theorem Proving . . . . . . . . . . . . . . 6

1.2.6 Interactive Theorem Proving . . . . . . . . . . . . . . . 7

1.2.7 Hybrid Techniques . . . . . . . . . . . . . . . . . . . . 8

1.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Proposed Methodology . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Thesis Contributions . . . . . . . . . . . . . . . . . . . . . . . 12

1.6 Organization of Thesis . . . . . . . . . . . . . . . . . . . . . . 13

2 Preliminaries 15

2.1 Theorem Proving . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 HOL Theorem Prover . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

vii

TABLE OF CONTENTS viii

2.2.3 Inference Rules . . . . . . . . . . . . . . . . . . . . . . 18

2.2.4 Theorems . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.5 Theories . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.6 Proofs in HOL . . . . . . . . . . . . . . . . . . . . . . 19

2.2.7 HOL Notations . . . . . . . . . . . . . . . . . . . . . . 19

3 Formalization of Generic Library 21

3.1 Logic Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Demultiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5 Encoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6 Ripple Carry Adder . . . . . . . . . . . . . . . . . . . . . . . . 34

3.7 Carry Select Adder . . . . . . . . . . . . . . . . . . . . . . . . 36

3.8 Multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Graphical User Interface 43

4.1 AFVGCC Interface . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Starting a New Project . . . . . . . . . . . . . . . . . . . . . . 44

4.3 Path Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4 Implementation of the design . . . . . . . . . . . . . . . . . . 45

4.5 Desired behavior or specification of the design . . . . . . . . . 46

4.6 Steps for Verification . . . . . . . . . . . . . . . . . . . . . . . 47

4.6.1 Manual Steps for Verification . . . . . . . . . . . . . . 47

4.6.2 Automatic Steps for Verification . . . . . . . . . . . . . 48

4.7 Final Output of the Tool . . . . . . . . . . . . . . . . . . . . . 48

4.7.1 Saving a theorem . . . . . . . . . . . . . . . . . . . . . 49

4.7.2 Saving a code . . . . . . . . . . . . . . . . . . . . . . . 49

TABLE OF CONTENTS ix

4.7.3 Interactive Environment . . . . . . . . . . . . . . . . . 49

4.8 Translators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.8.1 Implementation Translator . . . . . . . . . . . . . . . . 50

4.8.2 Specification Translator . . . . . . . . . . . . . . . . . 50

5 Case Studies 52

5.1 24-bit Adder/Subtractor . . . . . . . . . . . . . . . . . . . . . 53

5.2 8-bit Shifter Module of Benchmark Circuit c3540 . . . . . . . 59

5.3 17-bit EqualZ W Module of Benchmark Circuit c2670 . . . . . 66

5.4 16:1 Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.5 512-bit Multiplier . . . . . . . . . . . . . . . . . . . . . . . . . 77

6 Conclusion and Future Work 80

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

List of Figures

1.1 Proposed Methodology . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Recursive Implementation of n:1 Mux . . . . . . . . . . . . . . 24

3.2 Implementation of 2:1 MUX . . . . . . . . . . . . . . . . . . . 24

3.3 Recursive Implementation of n:2n Decoder . . . . . . . . . . . 27

3.4 Implementation of 1:n Demultiplexer . . . . . . . . . . . . . . 29

3.5 Recursive Implementation of 2n:n Encoder . . . . . . . . . . . 31

3.6 Implementation of encod 2to1 . . . . . . . . . . . . . . . . . . 32

3.7 Recursive Implementation of n-bit Adder . . . . . . . . . . . . 34

3.8 Implementation of 1-bit Ripple Carry Adder . . . . . . . . . . 35

3.9 Implementation of 1-bit Carry Select Adder . . . . . . . . . . 37

3.10 Recursive Implementation of n-bit Multiplier . . . . . . . . . . 39

3.11 Implementation of 1-bit Multiplier . . . . . . . . . . . . . . . . 40

4.1 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . 44

4.2 GUI combox-box . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 GUI Interface for Entering Specification . . . . . . . . . . . . 47

4.4 GUI Interactive Environment . . . . . . . . . . . . . . . . . . 49

5.1 Implementation of 24-bit Adder/Subtractor . . . . . . . . . . 53

5.2 Implementation of the 8-bit Shifter Module of c3540 . . . . . . 59

x

LIST OF FIGURES xi

5.3 Implementation of the 17-bit EqualZ W Module of c2670 . . . 67

5.4 Implementation of a 16:1 Multiplexer . . . . . . . . . . . . . . 73

5.5 Implementation of a 512-bit Multiplier . . . . . . . . . . . . . 77

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 1999. 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 ascer-

tains 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

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 over-

comes its limitations by proving or disproving the correctness of the given

design against its desired properties mathematically. The main principle be-

hind formal analysis of a digital circuit is to construct a computer based

mathematical model of the given circuit and formally verify, within a com-

puter, 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 speci-

fication 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 Graph-

ics, 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 theo-

rem provers [15], using the expressive higher-order-logic, can overcome these


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 Multiplex-

ers, 1:n Demultiplexers, n:2n Decoders, 2n: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 flexi-

bility 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


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.

1.2.1 Assertions

In assertion based verification, assertions are used in conjunctions with sim-

ulation to formally express and verify the required behavior of the hardware

[1]. This approach has been found to be way faster than the regular simula-

tion 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.

1.2.2 Computer Algebra

Computer algebraic algorithms have also been used to verify many combi-

national 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 algo-

rithms themselves may contain bugs and thus the results cannot be termed

as 100% reliable.


1.2.3 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.

1.2.4 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 veri-

fication goal of a large systems into a finite number of subgoals, which are

then discharged using the SMV model checker. Multi-agent systems are ver-

ified using model checking via Ordered Binary Decision Diagrams [11]. A

generic model checking based tool is developed for the verification of pro-

tocols 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


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.

1.2.5 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 proper-

ties 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 ver-

ify 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 scal-

ability of this technique is a major concern since the state transition checks

grow exponentially for large circuits and thus the automatic verification ca-

pability is compromised.


1.2.6 Interactive Theorem Proving

Interactive theorem provers, using higher-order logic, can overcome the lim-

ited 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 Con-

structions (CiC) and features dependent types, which are quite helpful in

creating reliable circuit models as errors can be caught earlier by type check-

ing [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) com-

ponents library [31]. Both of these works are application specific. Also the

conversion of Verilog to formal language is done manually in the DS encoding


verification [23].

1.2.7 Hybrid Techniques

Many hybrid techniques, based on the idea of exploiting the strengths of

interactive theorem proving and automatic verification tools, have been de-

veloped 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 combina-

tional 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 hard-

ware 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 theo-

rem 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


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 fi-

nal 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


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 characteris-

tics 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:2n Decoder, 2n:n En-

coder, 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 im-

portant 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


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 stan-

dard 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 syn-

tax, 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 specifi-

cation 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 tradi-

tional 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


system (i) the formal proof of system properties that specify that given cir-

cuits 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. 1.1.

The distinguishing features of the proposed methodology include its ac-

ceptance and generation of Verilog codes and automatic formal verification,

using a sound higher-order-logic theorem prover. The translators and a li-

brary 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 cir-

cuit 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 cir-

cuits.

• Automatic translation of HDLs to formal language is provided by our

methodology which saves the user from a lot of manual effort.


• 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 combina-

tional circuits without describing its behaviour details which is auto-

matically 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 il-

lustrated by automatically verifying a number of real-world combina-

tional 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 in-

troduction 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 demon-

strate the practical usefulness of the proposed methodology, five case studies

namely 24-bit adder/subtractor, the 8-bit shifter module of benchmark cir-

cuit 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


presented in Chapter 5. Lastly, Chapter 6 concludes the thesis and points

out some future research areas.

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. De-

pending upon the requirements of expressibility, the mathematical theories

can be build upon various types of logic, such as, first-order logic, proposi-

tional 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 pro-

vides 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

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 com-

binational 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 verifi-

cation [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 mathemati-

cal 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 ver-

sions 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


(SML). The HOL core consists of only 5 basic axioms and 8 primitive in-

ference rules. HOL theorem prover has been widely used for the hardware

verification [13].

2.2.1 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).

2.2.2 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).


2.2.3 Inference Rules

Inference rules are represented as ML functions and they are used for de-

riving new theorems. HOL provides with a set of eight primitive infer-

ence rules, which are then used to derive any new theorem. These infer-

ence rules are Reflexivity, Assumption introduction, Substitution, Abstrac-

tion, Beta-conversion, Type instantiation, Modus Ponens and Discharging

an assumption.

2.2.4 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.

2.2.5 Theories

A HOL theory comprises of a set of type, type operators, constants, defini-

tions, 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.


2.2.6 Proofs in HOL

In order to verify any proof in HOL, two approaches can be followed: for-

ward 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 re-

quires 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 au-

tomatic tactics provided by HOL which helps in simplifying the goal while

other proof steps can be verified through user interaction.

2.2.7 HOL Notations

The Table 2.1 provides the mathematical interpretation of some HOL func-

tions 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.


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 : t

@x.t ε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 ex Exponential function

Chapter 3

Formalization of Generic

Library

This Chapter explains the grey shaded blocks of the proposed methodology,

given in Fig. 1.1. 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

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 True

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))


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: n-bit NOR gate

` ∀ h t out. 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: n-bit XNOR gate

` ∀ h t out. 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 log2n 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 = log2n, or in other


Figure 3.1: Recursive Implementation of n:1 Mux

Figure 3.2: Implementation of 2:1 MUX


words n = 2k. 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 - 1 - BV n s) a))


where the HOL expression (EL n a) returns the nth 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 num-

ber, 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: Formal Verification of n:1 Mux

` ∀ a s b. (¬(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 as-

sumptions 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:2n Decoder [25], shown in Fig. 3.3,

is implemented using two (n-1):2(n−1) Decoders having input of tail of the


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:2n Decoder

Definition 13: Implementation of n:2n 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)


where n is the width of the output data line. The behaviour of the Decoder

is formalized as:

Definition 14: Specification of n:2n Decoder

` ∀ n e a b. 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:2n 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.


3.4 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 = log2n, or in other words n = 2k. Demultiplexer

can easily be defined using implementation definition of Decoder as shown

below:

Figure 3.4: Implementation of 1:n Demultiplexer


Definition 16: Implementation of 1:n Demultiplexer

` ∀ n a s b. 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: Specification of 1:n Demultiplexer

` ∀ n a s b. 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 2n:n Priority Encoder using two 2n−1:(n-1) Encoders, which encodes on

the bases of the highest priority of the input signal, i.e., all other bits of the


input data signal are ignored if the most significant bit of the data input

signal is True.

Figure 3.5: Recursive Implementation of 2n:n Encoder

The recursive implementation of Encoder is formalized in HOL as:

Definition 18: Implementation of 2n: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


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. 3.6. 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


The formal definition of the behavior of the 2n:n Encoder is defined recur-

sively in HOL as:

Definition 20: Specification of 2n: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 en-

coded. In order to simplify the verification of Encoder, the behaviour of the

encod 2to1 is formalized and verified in HOL.

Definition 21: Specification of encod 2to1

` ∀ e p eo h. 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 2n: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)


3.6 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:


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


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. 3.7. The main difference is the implementation of the 1-bit


adder, which is implemented using a Mux and full adder as shown in Fig.

3.9. 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


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.


3.8 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)


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 pred-

icate form giving product in data output lines i.e., p, the function mult imp 1

is implementing 1-bit multiplier shown in Fig. 3.11 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:


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


them for automatically verifying a wide range of combinational circuits, as

depicted in Fig. 1.1. This benefit is attained at the cost of extensive user-

effort 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 com-

binational 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.

Chapter 4

Graphical User Interface

A user-friendly graphical user interface is created for the proposed method-

ology 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 ver-

ification and its desired behaviour, given in simple C language, to the formal

language supported by the interactive theorem prover HOL. After this au-

tomatic 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 compo-

nents, 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

CHAPTER 4. GRAPHICAL USER INTERFACE 44

4.1 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.


4.3 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. 4.1.

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. 4.1. 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


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. 4.3. 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.


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:

4.6.1 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


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 veri-

fication.

4.6.2 Automatic Steps for Verification

In order to facilitate the automation and save user form the trouble of re-

membering 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 de-

sign 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 specifi-

cation 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.


4.7.1 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.

4.7.2 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.

4.7.3 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


reason of failure. He can even guide the tool for further verification steps

in the traditional interactive style by entering the command in the textbox

provided and then pressing run button. ”Details” button is needed to be

pressed after sending any command to refresh the status of the tool.

4.8 Translators

In order to facilitate automation, two translators are developed in C#, i.e.,

the implementation and specification translators.

4.8.1 Implementation Translator

The implementation translator is developed at the backend of ”convert im-

plementation” button, which accepts the input of structural description of

the circuit that is needed to be verified in Verilog format. This code is then

translated into its corresponding formal description through the technique

of string matching. In order to facilitate this translation, the user is only

allowed to use the component names that are consistent with the formally

verified generic components.

4.8.2 Specification Translator

The specification translator, developed at the backend of ”convert specifi-

cation” button, deals with the translation of the desired behaviour of the

circuit in simple C language to its corresponding formal specification. Here,

the user is restricted to use some specific keywords and operators with the

help of a combo box, as described in section 4.5.

It is worth mentioning here that the translators used are not formally

verified and are thus susceptible to make translation errors. But the chances


of verifying wrong circuits are very rare since the chances of making the

corresponding errors in both the specification and implementation and thus

verifying their equivalence are very less. What can practically happen is that

either the specification or the implementation may get a translation bug but

this can be caught during the formal verification phase and thus rectified.

Chapter 5

Case Studies

In order to evaluate the effectiveness of the proposed methodology, shown in

Fig. 1.1, we used it to formally verify many combinational circuits includ-

ing 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 Multi-

plexer circuit using a 4:16 Decoder and a 512-bit Multiplier circuit. All these

circuits were automatically verified on a Ubuntu workstation with Corei5-

2320 processor operating at 3GHz*4 with 4GB memory and their results are

shown below in Table ??. It is important to note that these results have

been obtained automatically without any user guidance. The accuracy and

automation in verification are the main benefits provided by our proposed

methodology. It is also worth-mentioning here that despite of the use of

larger number of inputs and larger number of gates in the circuits, the pro-

posed methodology has been able to successfully and automatically verify

them in less than a couple of minutes, as can be seen in Table 5.1.

52

CHAPTER 5. CASE STUDIES 53

Figure 5.1: Implementation of 24-bit Adder/Subtractor

5.1 24-bit Adder/Subtractor

In this section, we explain the step-by-step working of the proposed method-

ology using the 24-bit adder/subtractor, shown in Fig. 5.1, which acts as

a binary adder or subtractor depending upon a boolean input signal sel.

The input to the proposed methodology is the structural view of the circuit,

shown in Fig. 5.1. Our methodology accepts Verilog codes for this purpose

and the corresponding file is given below:

module case_study(a, b, sel, y, co);

input [23:0] a;

input [23:0] b;

input sel;


output [23:0] y;

output co;

wire [23:0] xb;

xor n0(xb[23],b[23],sel); xor n1(xb[22],b[22],sel);





xor r0(xb[13],b[13],sel); xor r1(xb[12],b[12],sel);





xor s3(xb[3],b[3],sel); xor s2(xb[2],b[2],sel);

xor s1(xb[1],b[1],sel); xor s0(xb[0],b[0],sel);

ripple_adder a1(y,co,a,xb,sel);

endmodule

It is important to note that this file does not contain the behavioral de-

scriptions of the module ripple adder. Actually, it is reserved for the cor-

responding formally verified component and its behavior would be extracted

from the Definitions 25, during the verification phase. The above-mentioned

Verilog code is used to obtain the formal implementation of the given circuit

with the help of the implementation translator:

` ∀ a23...a0 b23...b0 sel y23...y0 co.

case_study_imp a23...a0 b23...b0 sel y23...y0 co =


? xb23...xb0.

xor_n [b23;sel] xb23 ∧ xor_n [b22;sel] xb22 ∧












Adder_imp_n (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC

(SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC

(SUC 0)))))))))))))))))

[a23;a22;a21;a20;a19;a18;a17;a16;a15;a14;a13;a12;a11;a10;a9;a8;a7;

a6;a5;a4;a3;a2;a1;a0]

[xb23;xb22;xb21;xb20;xb10;xb18;xb17;xb16;xb15;xb14;xb13;xb12;xb11;

xb10;xb9;xb8;xb7;xb6;xb5;xb4;xb3;xb2;xb1;xb0] sel

[y23;y22;y21;y20;y19;y18;y17;y16;y15;y14;y13;y12;y11;y10;y9;y8;y7;

y6;y5;y4;y3;y2y1;y0] co

Besides providing the structural view of the circuit, the user is also responsi-

ble for providing the desired behaviour of the given circuit using arithmetic

operators (+,-,*) and if-else conditional statements. The behavior of the

given adder/subtractor circuit can be expressed as follows:


if (sel)

co,y = a + (-b + 1);

else

co,y = a + b;

where binary subtraction is carried out by adding input a with the 2’s com-

plement of input b and co,y represents the concatenation of the carry-out

signal and the sum output y. This behavior is used to obtain the formal speci-

fication of the given circuit automatically though the specification translator:

` ∀ a23...a0 b23...b0 sel y23...y0 co.

case_study_spec a23...a0 b23...b0 sel y23...y0 co =

if sel then

([co;y23;y22;y21;y20;y19;y18;y17;y16;y15;y14;y13;y12;y11;y10;y9;

y8;y7;y6;y5;y4;y3;y2;y1;y0] =

num_BV_f (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC


(SUC 0)))))))))))))))))))))))))

(BV_n [a23;a22;a21;a20;a19;a18;a17;a16;a15;a14;a13;a12;a11;a10;a9;

a8;a7;a6;a5;a4;a3;a2;a1;a0] +

(BV_n [¬b23;¬b22;¬b21;¬b20;¬b19;¬b18;¬b17;¬b16;¬b15;¬b14;¬b13;

¬b12;¬b11;¬b10;¬b9;¬b8;¬b7;¬b6;¬b5;¬b4;¬b3;¬b2;¬b1;¬b0] + 1))

else

([co;y23;y22;y21;y20;y19;y18;y17;y16;y15;y14;y13;y12;y11;y10;y9;


y8;y7;y6;y5;y4;y3;y2;y1;y0] =

num_BV_f (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC


(SUC 0)))))))))))))))))))))))))

(BV_n [a23;a22;a21;a20;a19;a18;a17;a16;a15;a14;a13;a12;a11;a10;a9;

a8;a7;a6;a5;a4;a3;a2;a1;a0] +

(BV_n [b23;b22;b21;b20;b19;b18;b17;b16;b15;b14;b13;b12;b11;b10;b9;

b8;b7;b6;b5;b4;b3;b2;b1;b0]))))

Now, the equivalence between the formal implementation and specification of

the given circuit is automatically verified as a HOL theorem, which is given

below:

` ∀ a23...a0 b23...b0 sel y23...y0 co.

case_study_imp a23...a0 b23...b0 sel y23...y0 co <=>

case_study_spec a23...a0 b23...b0 sel y23...y0 co.

The automated reasoning process involves Definition 25 and Theorem 8

and is pretty straightforward (The proof script contains only 4 lines of HOL

code). Once this theorem is verified, the Verilog code of the generic circuit is

also appended to the input Verilog file as shown below. For this purpose, our

methodology has access to generic (n-bit) Verilog codes, corresponding to all

the formally verified structures. These codes are supposed to be provided by

the library design engineer for every formally verified component.


module ripple_adder #(parameter n = 24)

(output [n-1:0] s, output co,

input [n-1:0] a, input [n-1:0] b,

input cin);

generate

if (n == 1)

Adder_imp a1 (a[0],b[0],cin,co,s[0]);

else

begin

wire p;

Adder_imp a1 (a[n-1],b[n-1],p,co,s[n-1]);

ripple_adder #(n-1) m3(s[n-2:0],p,a[n-2:0],b[n-2:0],cin);

end

endgenerate

endmodule

module Adder_imp (a,b,cin,out);

input a,b,cin;

output [1:0] out; wire p,q,r;

xor x1 (p,a,b); xor x2 (out[0],p,cin);

and a1 (q,a,b); and a2 (r,p,cin);

or o1 (out[1],r,q);

endmodule

Thus, the final outcome of the tool is a complete synthesizeable Verilog

code along with a formally verified theorem that ascertains its correctness.

To the best of our knowledge, this kind of capability is not provided by any

existing formal hardware verification tool.


5.2 8-bit Shifter Module of Benchmark Cir-

cuit c3540

In this section, formal verification of 8-bit shifter module of benchmark circuit

c3540, shown in Fig. 5.2, is carried out.

Figure 5.2: Implementation of the 8-bit Shifter Module of c3540

It performs right and left shifting of the 8-bit data input signal, i.e., a de-

pending upon a boolean input cnt3. If cnt3 is True, left shifting takes place,

otherwise right shifting occurs. The data input signal which is to be shifted

is replaced by 8-bit input signal q, in the case of right shifting and by 8-bit

input signal r, in the case of left shifting. A 3:8 Decoder is used to compute

the times input signal needs to be shifted, which is indicated by user using

input signals cnt12, cnt10 and cnt2. The signal cnt5 is used for shifting the

signed bit of the input data signal. The input to the proposed methodology,


is the structural view of the circuit in which user has the benefit of using the

modules of and, or, Decoder and Mux without describing their behaviour.

The input Verilog code of the circuit is converted into HOL syntax using our

Verilog-HOL translator as:

∀ a0 a1 a2 a3 a4 a5 a6 a7 sel7 sel6 sel5 sel4 sel3 sel2 sel1 sel0

out. Mux8_1 a0 a1 a2 a3 a4 a5 a6 a7 sel7 sel6 sel5 sel4 sel3 sel2

sel1 sel0 out = ? t7 t6 t5 t4 t3 t2 t1 t0.

and_n [a0;sel0] t0 ∧ and_n [a1;sel1] t1 ∧




or_n [t7;t6;t5;t4;t3;t2;t1;t0] out.

----------------------------------------------------------------

∀ a7 a6 a5 a4 a3 a2 a1 a0 b7 b6 b5 b4 b3 b2 b1 b0 c7 c6 c5 c4 c3

c2 c1 c0 q7 q6 q5 q4 q3 q2 q1 q0 r7 r6 r5 r4 r3 r2 r1 r0 x7 x6 x5

x4 x3 x2 x1 x0 y7 y6 y5 y4 y3 y2 y1 y0 z7 z6 z5 z4 z3 z2 z1 z0

sel7 sel6 sel5 sel4 sel3 sel2 sel1 sel0 out7 out6 out5 out4 out3

out2 out1 out0.

Mux8bit8_1

a7 a6 a5 a4 a3 a2 a1 a0 b7 b6 b5 b4 b3 b2 b1 b0

c7 c6 c5 c4 c3 c2 c1 c0 q7 q6 q5 q4 q3 q2 q1 q0

r7 r6 r5 r4 r3 r2 r1 r0 x7 x6 x5 x4 x3 x2 x1 x0

y7 y6 y5 y4 y3 y2 y1 y0 z7 z6 z5 z4 z3 z2 z1 z0

sel7 sel6 sel5 sel4 sel3 sel2 sel1 sel0

out7 out6 out5 out4 out3 out2 out1 out0 =


Mux8_1 a7 b7 c7 q7 r7 x7 y7 z7 sel7 sel6 sel5 sel4 sel3 sel2 sel1

sel0 out7 ∧


sel0 out6 ∧


sel0 out5 ∧


sel0 out4 ∧


sel0 out3 ∧


sel0 out2 ∧


sel0 out1 ∧


sel0 out0.

------------------------------------------------------------------

∀ a7 a6 a5 a4 a3 a2 a1 a0 q7 q6 q5 q4 q3 q2 q1 q0 r7 r6 r5 r4 r3

r2 r1 r0 cnt12 cnt10 cnt2 cnt3 cnt5 s7 s6 s5 s4 s3 s2 s1 s0.

Shifter_imp a7 a6 a5 a4 a3 a2 a1 a0 q7 q6 q5 q4 q3 q2 q1 q0 r7 r6

r5 r4 r3 r2 r1 r0 cnt12 cnt10 cnt2 cnt3 cnt5 s7 s6 s5 s4 s3 s2 s1

s0 = ? sel7 sel6 sel5 sel4 sel3 sel2 sel1 sel0 sq7 sq6 sq5 sq4

sq3 sq2 sq1 sq0 sr7 sr6 sr5 sr4 sr3 sr2 sr1 sr0 zz.

decod_imp_n (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC 0)))))))) T

[cnt12;cnt10;cnt2] [sel7;sel6;sel5;sel4;sel3;sel2;sel1;sel0] ∧

Mux8bit8_1


q0 a7 a6 a5 a4 a3 a2 a1 q1 q0 a7 a6 a5 a4 a3 a2

q2 q1 q0 a7 a6 a5 a4 a3 q3 q2 q1 q0 a7 a6 a5 a4

q4 q3 q2 q1 q0 a7 a6 a5 q5 q4 q3 q2 q1 q0 a7 a6

q6 q5 q4 q3 q2 q1 q0 a7 q7 q6 q5 q4 q3 q2 q1 q0


sq7 sq6 sq5 sq4 sq3 sq2 sq1 sq0 ∧

Mux8bit8_1

a6 a5 a4 a3 a2 a1 a0 r7 a5 a4 a3 a2 a1 a0 r7 r6

a4 a3 a2 a1 a0 r7 r6 r5 a3 a2 a1 a0 r7 r6 r5 r4

a2 a1 a0 r7 r6 r5 r4 r3 a1 a0 r7 r6 r5 r4 r3 r2

a0 r7 r6 r5 r4 r3 r2 r1 r7 r6 r5 r4 r3 r2 r1 r0


sr7 sr6 sr5 sr4 sr3 sr2 sr1 sr0 ∧

mux_imp_n [sr7;sq7] [cnt3] zz ∧ mux_imp_n [a7;zz] [cnt5] s7 ∧

mux_imp_n [sr6;sq6] [cnt3] s6 ∧ mux_imp_n [sr5;sq5] [cnt3] s5 ∧



mux_imp_n [sr0;sq0] [cnt3] s0.

The behavior of the given shifter circuit is given by user using if-else condi-

tional statements which is again automatically converted into HOL formal

language by our translators as:

∀ a7 a6 a5 a4 a3 a2 a1 a0 q7 q6 q5 q4 q3 q2 q1 q0 r7 r6 r5 r4 r3

r2 r1 r0 cnt12 cnt10 cnt2 cnt3 cnt5 s7 s6 s5 s4 s3 s2 s1 s0.


Shifter_spec a7 a6 a5 a4 a3 a2 a1 a0 q7 q6 q5 q4 q3 q2 q1 q0 r7

r6 r5 r4 r3 r2 r1 r0 cnt12 cnt10 cnt2 cnt3 cnt5 s7 s6 s5 s4 s3

s2 s1 s0 =

if (cnt3) then

(if ([cnt12;cnt10;cnt2] = [F;F;F]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;a5;a4;a3;a2;a1;a0;r7])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [a6;a5;a4;a3;a2;a1;a0;r7]))

else if ([cnt12;cnt10;cnt2] = [F;F;T]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;a4;a3;a2;a1;a0;r7;r6])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [a5;a4;a3;a2;a1;a0;r7;r6]))

else if ([cnt12;cnt10;cnt2] = [F;T;F]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;a3;a2;a1;a0;r7;r6;r5])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [a4;a3;a2;a1;a0;r7;r6;r5]))

else if ([cnt12;cnt10;cnt2] = [F;T;T]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;a2;a1;a0;r7;r6;r5;r4])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [a3;a2;a1;a0;r7;r6;r5;r4]))

else if ([cnt12;cnt10;cnt2] = [T;F;F]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;a1;a0;r7;r6;r5;r4;r3])

else


([s7;s6;s5;s4;s3;s2;s1;s0] = [a2;a1;a0;r7;r6;r5;r4;r3]))

else if ([cnt12;cnt10;cnt2] = [T;F;T]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;a0;r7;r6;r5;r4;r3;r2])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [a1;a0;r7;r6;r5;r4;r3;r2]))

else if ([cnt12;cnt10;cnt2] = [T;T;F]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;r7;r6;r5;r4;r3;r2;r1])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [a0;r7;r6;r5;r4;r3;r2;r1]))

else

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;r6;r5;r4;r3;r2;r1;r0])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [r7;r6;r5;r4;r3;r2;r1;r0])))

else

(if ([cnt12;cnt10;cnt2] = [F;F;F]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;a7;a6;a5;a4;a3;a2;a1])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [q0;a7;a6;a5;a4;a3;a2;a1]))

else if ([cnt12;cnt10;cnt2] = [F;F;T]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;q0;a7;a6;a5;a4;a3;a2])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [q1;q0;a7;a6;a5;a4;a3;a2]))


else if ([cnt12;cnt10;cnt2] = [F;T;F]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;q1;q0;a7;a6;a5;a4;a3])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [q2;q1;q0;a7;a6;a5;a4;a3]))

else if ([cnt12;cnt10;cnt2] = [F;T;T]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;q2;q1;q0;a7;a6;a5;a4])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [q3;q2;q1;q0;a7;a6;a5;a4]))

else if ([cnt12;cnt10;cnt2] = [T;F;F]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;q3;q2;q1;q0;a7;a6;a5])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [q4;q3;q2;q1;q0;a7;a6;a5]))

else if ([cnt12;cnt10;cnt2] = [T;F;T]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;q4;q3;q2;q1;q0;a7;a6])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [q5;q4;q3;q2;q1;q0;a7;a6]))

else if ([cnt12;cnt10;cnt2] = [T;T;F]) then

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;q5;q4;q3;q2;q1;q0;a7])

else

([s7;s6;s5;s4;s3;s2;s1;s0] = [q6;q5;q4;q3;q2;q1;q0;a7]))

else

(if (cnt5) then

([s7;s6;s5;s4;s3;s2;s1;s0] = [a7;q6;q5;q4;q3;q2;q1;q0])


else

([s7;s6;s5;s4;s3;s2;s1;s0] = [q7;q6;q5;q4;q3;q2;q1;q0]))).

The equivalence between the formal implementation and specification

of the given circuit is automatically verified as a HOL theorem shown be-

low which involves Definitions 11 and 14 along with Theorems 2 and 3 for

verification.

` ∀ a7 a6 a5 a4 a3 a2 a1 a0 q7 q6 q5 q4 q3 q2 q1 q0 r7 r6 r5 r4

r3 r2 r1 r0 cnt12 cnt10 cnt2 cnt3 cnt5 s7 s6 s5 s4 s3 s2 s1 s0.

Shifter_imp a7 a6 a5 a4 a3 a2 a1 a0 q7 q6 q5 q4 q3 q2 q1 q0 r7


s2 s1 s0 <=>

Shifter_spec a7 a6 a5 a4 a3 a2 a1 a0 q7 q6 q5 q4 q3 q2 q1 q0 r7


s2 s1 s0.

5.3 17-bit EqualZ W Module of Benchmark

Circuit c2670

In this section, formal verification of the 17-bit EqualZ W module of bench-

mark circuit c2670, shown in Fig. 5.3 is carried out. It is a simple module

which gives True at output signal eq when any bit of the two 16-bit data in-

put signals, i.e. z and w are equal. The boolean output signal neq indicates

that all bits of the both data signals are unequal.


Figure 5.3: Implementation of the 17-bit EqualZ W Module of c2670

The Verilog code given by the user for the circuit, shown in Fig. 5.3 is given

below:

module xor17bit(z,w,x);

input [16:0] z,w;

output [16:0]x;

xor n16 (x[16],z[16],w[16]); xor n15 (x[15],z[15],w[15]);

xor n14 (x[14],z[14],w[14]); xor n13 (x[13],z[13],w[13]);

xor n12 (x[12],z[12],w[12]); xor n11 (x[11],z[11],w[11]);

xor n10 (x[10],z[10],w[10]); xor n9 (x[9],z[9],w[9]);

xor n8 (x[8],z[8],w[8]); xor n7 (x[7],z[7],w[7]);

xor n6 (x[6],z[6],w[6]); xor n5 (x[5],z[5],w[5]);

xor n4 (x[4],z[4],w[4]); xor n3 (x[3],z[3],w[3]);

xor n2 (x[2],z[2],w[2]); xor n1 (x[1],z[1],w[1]);


xor n0 (x[0],z[0],w[0]);

endmodule

------------------------------------------------------------------

module AN18(z,cont,out);

input [16:0] z;

input cont;

output out;

wire [5:0] line;

and a1(line[0],z[0],z[1],z[2],z[3],z[4]);

and a2(line[1],z[5],z[6],z[7],z[8],z[9]);

and a3(line[2],line[0],line[1]);

and a4(line[3],z[10],z[11]);

and a5(line[4],z[12],z[13],z[14],z[15],z[16]);

and a6(line[5],line[3],line[4]);

and a7(out,line[2],line[5],cont);

endmodule

------------------------------------------------------------------

module EqualZ_W_imp(z,w,cont,eq,neq);

input [16:0] z,w;

input cont;

output eq,neq;

wire [16:0]x;

xor17bit n1(z,w,x);

AN18 n2(x,cont,neq);

not n3(eq,neq);

endmodule

where module xor17bit is implementing arrays of XOR gates and the module


AN18 is implementing arrays of AND gates. It is important to note that

this file does not contain the behavioral descriptions of the modules and

and xor. The above-mentioned Verilog code is used to obtain the formal

implementation of the given circuit with the help of the implementation

translator as:

∀ z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2 z1 z0

w16 w15 w14 w13 w12 w11 w10 w9 w8 w7 w6 w5 w4 w3 w2 w1 w0 x16

x15 x14 x13 x12 x11 x10 x9 x8 x7 x6 x5 x4 x3 x2 x1 x0.

xor17bit z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2 z1

z0 w16 w15 w14 w13 w12 w11 w10 w9 w8 w7 w6 w5 w4 w3 w2 w1 w0 x16

x15 x14 x13 x12 x11 x10 x9 x8 x7 x6 x5 x4 x3 x2 x1 x0 =

xor_n [z16;w16] x16 ∧ xor_n [z15;w15] x15 ∧

xor_n [z14;w14] x14 ∧ xor_n [z13;w13] x13 ∧

xor_n [z12;w12] x12 ∧ xor_n [z11;w11] x11 ∧

xor_n [z10;w10] x10 ∧ xor_n [z9;w9] x9 ∧

xor_n [z8;w8] x8 ∧ xor_n [z7;w7] x7 ∧

xor_n [z6;w6] x6 ∧ xor_n [z5;w5] x5 ∧

xor_n [z4;w4] x4 ∧ xor_n [z3;w3] x3 ∧

xor_n [z2;w2] x2 ∧ xor_n [z1;w1] x1 ∧

xor_n [z0;w0] x0.

------------------------------------------------------------------

∀ z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2 z1 z0

cont out.

AN18 z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2 z1 z0

cont out = ?line0 line1 line2 line3 line4 line5.

and_n [z0;z1;z2;z3;z4] line0 ∧

and_n [z5;z6;z7;z8;z9] line1 ∧


and_n [line0;line1] line2 ∧

and_n [z10;z11] line3 ∧

and_n [z12;z13;z14;z15;z16] line4 ∧

and_n [line3;line4] line5 ∧

and_n [line2;line5;cont] out.

------------------------------------------------------------------

∀ z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2 z1 z0 w16

w15 w14 w13 w12 w11 w10 w9 w8 w7 w6 w5 w4 w3 w2 w1 w0 cont eq neq.

EqualZ_W_imp z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2

z1 z0 w16 w15 w14 w13 w12 w11 w10 w9 w8 w7 w6 w5 w4 w3 w2 w1 w0

cont eq neq = ? x16 x15 x14 x13 x12 x11 x10 x9 x8 x7 x6 x5 x4 x3

x2 x1 x0.

xor17bit z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2 z1

z0 w16 w15 w14 w13 w12 w11 w10 w9 w8 w7 w6 w5 w4 w3 w2 w1 w0 x16

x15 x14 x13 x12 x11 x10 x9 x8 x7 x6 x5 x4 x3 x2 x1 x0 ∧

AN18 x16 x15 x14 x13 x12 x11 x10 x9 x8 x7 x6 x5 x4 x3 x2 x1 x0

cont neq ∧

not neq eq.

After providing the structural view of the circuit, the user provides the de-

sired behaviour of the given circuit using if-else conditional statements as:

if (¬(z[0] == w[0]))

if (¬(z[1] == w[1]))

if (¬(z[2] == w[2]))

if (¬(z[3] == w[3]))

if(¬(z[4] == w[4]))


if(¬(z[5] == w[5]))

if(¬(z[6] == w[6]))

if(¬(z[7] == w[7]))

if(¬(z[8] == w[8]))

if(¬(z[9] == w[9]))

if(¬(z[10] == w[10]))

if(¬(z[11] == w[11]))

if(¬(z[12] == w[12]))

if(¬(z[13] == w[13]))

if(¬(z[14] == w[14]))

if(¬(z[15] == w[15]))

if(¬(z[16] == w[16]))

if(cont)

neq = 1;

else

neq = 0;

eq = ¬neq;

where each bit of the two data input signals are checked and True is given to

signal neq, if all are unequal. Then the output signal eq is computed using

the result of neq. This behavior is used to obtain the formal specification of

the given circuit automatically as:

∀ z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2 z1 z0 w16


EqualZ_W_spec z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2



cont eq neq =

(if (¬(z0 = w0) ∧ ¬(z1 = w1) ∧ ¬(z2 = w2) ∧ ¬(z3 = w3) ∧

(z4 = w4) ∧ ¬(z5 = w5) ∧ ¬(z6 = w6) ∧ ¬(z7 = w7) ∧ ¬(z8 = w8) ∧

¬(z9 = w9) ∧ ¬(z10 = w10) ∧ ¬(z11 = w11) ∧ ¬(z12 = w12) ∧

¬(z13 = w13) ∧ ¬(z14 = w14) ∧ ¬(z15 = w15) ∧ ¬(z16 = w16) ∧

cont) then z_not_eq_w = num2bool 1

else z_not_eq_w = num2bool 0) ∧

(z_eq_w = ¬z_not_eq_w).

The equivalence between the formal implementation and specification of the

given circuit is automatically verified as a HOL theorem given below using

Definitions 2 and 6.

` ∀ z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2 z1 z0 w16


EqualZ_W_imp z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2


cont eq neq <=>

EqualZ_W_spec z16 z15 z14 z13 z12 z11 z10 z9 z8 z7 z6 z5 z4 z3 z2


cont eq neq.

5.4 16:1 Multiplexer

In this section, formal verification of 16:1 Multiplexer circuit, shown in Fig.

5.4, is carried out, in which 4-bit input select lines, i.e., s is used to select


one of the 16 bits of the input data vector, i.e., a and gives the result on

1-bit output signal y.

Figure 5.4: Implementation of a 16:1 Multiplexer


the corresponding file of which is given below:

module Mux_16(a,s,y);

input [15:0] a;

input [3:0] s;

output y;

wire [15:0]y,x;

and n0 (y[0],a[0],x[0]); and n1 (y[1],a[1],x[1]);


and n2 (y[2],a[2],x[2]); and n3 (y[3],a[3],x[3]);

and n4 (y[4],a[4],x[4]); and n5 (y[5],a[5],x[5]);

and n6 (y[6],a[6],x[6]); and n7 (y[7],a[7],x[7]);

and n8 (y[8],a[8],x[8]); and n9 (y[9],a[9],x[9]);

and n10 (y[10],a[10],x[10]); and n11 (y[11],a[11],x[11]);

and n12 (y[12],a[12],x[12]); and n13 (y[13],a[13],x[13]);

and n14 (y[14],a[14],x[14]); and n15 (y[15],a[15],x[15]);

or o1 (y,y[15],y[14],y[13],y[12],y[11],y[10],y[9],y[8],y[7],y[6],

y[5],y[4],y[3],y[2],y[1],y[0]);

decoder d1 (x,T,s);

endmodule


scriptions of the module decoder. Its behavior would be extracted from the

Definition 14, during the verification phase. Implementation translator auto-

matically converts this Verilog code to the formal implementation as shown

below:

∀a15 a14 a13 a12 a11 a10 a9 a8 a7 a6 a5 a4 a3 a2 a1 a0 s3 s2 s1

s0 y.

Mux_16_imp a15 a14 a13 a12 a11 a10 a9 a8 a7 a6 a5 a4 a3 a2 a1 a0

s3 s2 s1 s0 y = ?x15 x14 x13 x12 x11 x10 x9 x8 x7 x6 x5 x4 x3 x2

x1 x0 y15 y14 y13 y12 y11 y10 y9 y8 y7 y6 y5 y4 y3 y2 y1 y0.

decod_imp_n (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC (SUC

(SUC (SUC (SUC (SUC (SUC (SUC 0)))))))))))))))) T [s3;s2;s1;s0] [x15;x14;x13;x12;x11;x10;x9;x8;x7;x6;x5;x4;x3;x2;x1;x0] ∧

and_n [a0;x0] y0 ∧ and_n [a1;x1] y1 ∧

and_n [a2;x2] y2 ∧ and_n [a3;x3] y3 ∧


and_n [a4;x4] y4 ∧ and_n [a5;x5] y5 ∧

and_n [a6;x6] y6 ∧ and_n [a7;x7] y7 ∧

and_n [a8;x8] y8 ∧ and_n [a9;x9] y9 ∧

and_n [a10;x10] y10 ∧ and_n [a11;x11] y11 ∧

and_n [a12;x12] y12 ∧ and_n [a13;x13] y13 ∧

and_n [a14;x14] y14 ∧ and_n [a15;x15] y15 ∧

or_n [y15;y14;y13;y12;y11;y10;y9;y8;y7;y6;y5;y4;y3;y2;y1;y0] y.

The behavior for the mux circuit under verification is given by the user as:

if (s == 0) y = a[0];

else if (s == 1) y = a[1];

else if (s == 2) y = a[2];

else if (s == 3) y = a[3];

else if (s == 4) y = a[4];

else if (s == 5) y = a[5];

else if (s == 6) y = a[6];

else if (s == 7) y = a[7];

else if (s == 8) y = a[8];

else if (s == 9) y = a[9];

else if (s == 10) y = a[10];

else if (s == 11) y = a[11];

else if (s == 12) y = a[12];

else if (s == 13) y = a[13];

else if (s == 14) y = a[14];

else y = a[15];


The behaviour is specifying that element of input data list, i.e., a is selected

on the basis of select lines and is given to the boolean output, i.e.,y. This

behavior is used to obtain the formal specification of the given circuit auto-

matically though the specification translator:

∀a15 a14 a13 a12 a11 a10 a9 a8 a7 a6 a5 a4 a3 a2 a1 a0 s3 s2 s1

s0 y.

Mux_16_spec a15 a14 a13 a12 a11 a10 a9 a8 a7 a6 a5 a4 a3 a2 a1 a0

s3 s2 s1 s0 y =

if [s3;s2;s1;s0] = [F;F;F;F] then (y = a0)

else if [s3;s2;s1;s0] = [F;F;F;T] then (y = a1)

else if [s3;s2;s1;s0] = [F;F;T;F] then (y = a2)

else if [s3;s2;s1;s0] = [F;F;T;T] then (y = a3)

else if [s3;s2;s1;s0] = [F;T;F;F] then (y = a4)

else if [s3;s2;s1;s0] = [F;T;F;T] then (y = a5)

else if [s3;s2;s1;s0] = [F;T;T;F] then (y = a6)

else if [s3;s2;s1;s0] = [F;T;T;T] then (y = a7)

else if [s3;s2;s1;s0] = [T;F;F;F] then (y = a8)

else if [s3;s2;s1;s0] = [T;F;F;T] then (y = a9)

else if [s3;s2;s1;s0] = [T;F;T;F] then (y = a10)

else if [s3;s2;s1;s0] = [T;F;T;T] then (y = a11)

else if [s3;s2;s1;s0] = [T;T;F;F] then (y = a12)

else if [s3;s2;s1;s0] = [T;T;F;T] then (y = a13)

else if [s3;s2;s1;s0] = [T;T;T;F] then (y = a14)

else (y = a15).

Then equivalence between the formal implementation and specification of the

given circuit is automatically verified as a HOL theorem given below which


involves Definition 14 and Theorem 3.

` ∀a15 a14 a13 a12 a11 a10 a9 a8 a7 a6 a5 a4 a3 a2 a1 a0 s3 s2 s1

s0 y.

Mux_16_imp a15 a14 a13 a12 a11 a10 a9 a8 a7 a6 a5 a4 a3 a2 a1 a0

s3 s2 s1 s0 y <=>

Mux_16_spec a15 a14 a13 a12 a11 a10 a9 a8 a7 a6 a5 a4 a3 a2 a1 a0

s3 s2 s1 s0 y

5.5 512-bit Multiplier

In this section, formal verification of a 512-bit Multiplier circuit, shown in

Fig. 5.5, is carried out, in which two 512-bit data input signals a and b are

multiplied to give product in the data output signal y.

Figure 5.5: Implementation of a 512-bit Multiplier



the corresponding file of which is given below:

module mult_512(a,b,y);

input [511:0] a;

input [511:0] b;

output [1023:0] y;

multiplier m1(y,a,b);

endmodule


scriptions of the modules multiplier which would be extracted from the

Definition 33, during the verification phase. Implementation translator au-

tomatically converts the above-mentioned Verilog code to the formal imple-

mentation of the given circuit as shown below:

∀ a511 a510......a1 a0 b511 b510.....b1 b0

y1023 y1022......y1 y0.

mult_512_imp a511 a510......a1 a0 b511 b510.....b1 b0

y1023 y1022......y1 y0 =

(mult_imp_n [a511;a510;....a1;a0] [b511;b510;....b1;b0]

[y1023;y1022;.....y1;y0]).

The behavior for the multiplier circuit under verification is given by the user

as:


y = a * b;

This behavior is used to obtain the formal specification of the given circuit

automatically though the specification translator:

∀ a511 a510......a1 a0 b511 b510.....b1 b0

y1023 y1022......y1 y0.

mult_512_spec a511 a510......a1 a0 b511 b510.....b1 b0

y1023 y1022......y1 y0 =

[y1023;y1022;.....y1;y0] = num_BV_f (SUC (SUC (SUC (SUC

(SUC (SUC (SUC (SUC (SUC (SUC .......))))))))))

(BV_n [a511;a510;....a1;a0] * BV_n [b511;b510;....b1;b0]).

.

Then equivalence between the formal implementation and specification of the

given circuit is automatically verified as a HOL theorem given below which

involves Definition 33 and Theorem 11.

` ∀ a511 a510......a1 a0 b511 b510.....b1 b0

y1023 y1022......y1 y0.

mult_512_imp a511 a510......a1 a0 b511 b510.....b1 b0

y1023 y1022......y1 y0 <=>

mult_512_spec a511 a510......a1 a0 b511 b510.....b1 b0

y1023 y1022......y1 y0.

Chapter 6

Conclusion and Future Work

6.1 Conclusion

In this thesis, we have presented a methodology for the automatic formal ver-

ification of combinational circuits using a higher-order-logic theorem prover

HOL. The proposed methodology enables the user to formally verify any

combinational circuit, irrespective of its size and complexity without having

any expertise in logical reasoning and formal language. The core principal

behind the proposed methodology is the availability of translators and com-

prehensive library of formally verified generic combinational circuits. The

translators are responsible for an automatic conversion of the implementa-

tion of the given design and its desired behaviour to their corresponding HOL

models while the library facilitates in the automation of the verification pro-

cess. The development of this library does involve interactive verification and

detailed tool guidance. But this is a one time effort that the tool vendors can

spend to facilitate automatic formal verification of arbitrary combinational

circuits. We have also created a user-friendly interface for our proposed

methodology. It is important to note here that the idea of using interac-

80

CHAPTER 6. CONCLUSION AND FUTURE WORK 81

tive theorem proving for hardware verification dates back to late 1980s [13].

What distinguishes our work from this idea and all the other existing work

in this direction, mentioned in the Section 1.2 of this thesis, is a practical

and generic methodology that, despite being based on interactive theorem

proving, allows the verification of real-world circuits automatically.

6.2 Future Work

The proposed work opens the door to many interesting future directions of

research. The formally verified library of circuits needs to be enhanced and

advanced components like, Wallace Tree, Booth multipliers and components

of floating-point arithmetic units may be added. More case studies for evalu-

ation purposes are also underway. As long term goals, we plan to integrate a

model checker with the proposed methodology to verify both combinational

and sequential circuits within the same framework. Our work can also be

combined with the recently proposed theorem proving based analog circuit

verification approach [39] to form a theorem proving based Analog and Mixed

Signal (AMS) circuit analysis framework.

Bibliography

[1] A. Dahan, D. Geist, L. Gluhovsky, D. Pidan, G. Shapir, Y. Wolfsthal,

L. Benalycherif, R. Kamidem and Y. Lahbib. Combining System Level

Modeling with Assertion based Verification. In International Symposium

on Quality of Electronic Design, pages 310–315. IEEE, 2005.

[2] A. Slobodova, J. Davis, S. Swords and W. Hunt. A Flexible Formal

Verification Framework for Industrial Scale Validation. In IEEE/ACM

International Conference on Formal Methods and Models for Codesign,

pages 89–97. IEEE, 2011.

[3] A.K. Mishra and A. Chandra. EQU-IITG: A Multi-Format Formal

Equivalence Checker. In International Conference on Energy, Automa-

tion, and Signal, pages 1–6. IEEE, 2011.

[4] C. Berg and C. Jacobi. Formal Verification of the VAMP Floating Point

Unit. In Correct Hardware Design and Verification Methods, volume

2144, pages 325–339. Springer, 2001.

[5] C. Paulin-Mohring. Circuits as Streams in Coq: Verification of a Se-

quential Multiplier. In Types for Proofs and Programs, volume 1158,

pages 216–230. Springer, 1996.

82

BIBLIOGRAPHY 83

[6] T. Coe. Inside the Pentium-FDIV Bug. Dr. Dobbs Journal, 20(4):129–

135, 1995.

[7] D. Drusinsky. The Temporal Rover and the ATG Rover. In SPIN

Model Checking and Software Verification, volume 1885, pages 323–330.

Springer, 2000.

[8] E. Clarke and D. Kroening and K. Yorav. Behavioral Consistency of

C and Verilog Programs using Bounded Model Checking. In Design

Automation Conference, pages 368–371. IEEE, 2003.

[9] E. Goldberg, M. Prasad and R Brayton. Using SAT for Combinational

Equivalence Checking. In Conference on Design, Automation and Test

in Europe, pages 114–121. IEEE Press, 2001.

[10] E.M. Clarke and O. Grumberg and D. Peled. Model Checking. MIT

press, 1999.

[11] F. Raimondi and A. Lomuscio. Automatic Verification of Multi-Agent

Systems by Model Checking Via Ordered Binary Decision Diagrams.

Journal of Applied Logic, 5(2):235–251, 2007.

[12] G.Al. Sammane, J. Schmaltz, D. Toma, P. Ostier and D. Borrione.

TheoSim: Combining Symbolic Simulation and Theorem Proving for

Hardware Verification. In Symposium on Integrated circuits and system

design, pages 60–65. ACM, 2004.

[13] A. Camilleri, M. Gordon and T.F. Melham. Hardware Verification using

Higher-order Logic. Computer Laboratory, University of Cambridge,

1986.

[14] H. Deng. Formal Verification of FPGA based Systems, 2011.

BIBLIOGRAPHY 84

[15] J. Harrison. Handbook of Practical Logic and Automated Reasoning.

Cambridge University Press, 2009.

[16] J. Harrison, K. Slind, and R. Arthan. HOL. In The Seventeen Provers

of the World, pages 11–19. Springer, 2006.

[17] J. Lv, P. Kalla and F. Enescu. Efficient Grobner Basis Reductions for

Formal Verification of Galois Field Multipliers. In Conference on Design,

Automation and Test in Europe, pages 899–904. EDA Consortium, 2012.

[18] J. Lv, P. Kalla and F. Enescu. Efficient Grobner Basis Reductions

for Formal Verification of Galois Field Arithmetic Circuits. Computer-

Aided Design of Integrated Circuits and Systems, IEEE Transactions

on, 32(9):1409–1420, 2013.

[19] J. Sawada and E. Reeber. ACL2SIX: A Hint used to Integrate a Theo-

rem Prover and an Automated Verification Tool. In Formal Methods in

Computer Aided Design, pages 161–170. IEEE, 2006.

[20] J. Sawada, P. Sandon, V. Paruthi, J. Baumgartner, M. Case and H.

Mony. Hybrid Verification of a Hardware Modular Reduction Engine.

In International Conference on Formal Methods in Computer-Aided De-

sign, pages 207–214. FMCAD Inc, 2011.

[21] K. Datta, P.P. Das. Assertion based Verification using HDVL. In Inter-

national Conference on VLSI Design, pages 319–325. IEEE, 2004.

[22] T. Kropf. Introduction to Formal Hardware Verification. Springer, 1999.

[23] L. Li,L. Liu, Y. Guan, Y. Zhang, J. Zhang and L .Tao. A Formal Method

for Verifying the Implementation of SPW. In Conference on Spacewire,

2010.

BIBLIOGRAPHY 85

[24] L. Pierre, F. Pancher, R. Suescun and J. Quevremont. On the Effective-

ness of Assertion-based Verification in an Industrial Context. In For-

mal Methods for Industrial Critical Systems, volume 8187, pages 78–93.

Springer, 2013.

[25] P.K. Lala. Principles of Modern Digital Design. John Wiley & Sons,

2007.

[26] K.L. McMillan. A Methodology for Hardware Verification using Compo-

sitional Model Checking. Science of Computer Programming, 37(1):279–

309, 2000.

[27] M.D. Aagaard and C.-J.H. Seger. The Formal Verification of a Pipelined

Double-Precision IEEE Floating-Point Multiplier. In IEEE/ACM In-

ternational Conference on Computer-aided Design, pages 7–10. IEEE

Computer Society, 1995.

[28] N. Saeed, A. Inam, A. Khan and O. Hasan. V-HOLT Verifier-an Au-

tomatic Formal Verification Tool for Combinational Circuits. In Inter-

national Conference on Multitopic Conference, pages 155–158. IEEE,

2012.

[29] O. Wienand, M. Wedler, D. Stoffel, W. Kunz and G.-M. Greuel. An

Algebraic Approach for Proving Data Correctness in Arithmetic Data

Paths. In Computer Aided Verification, volume 5123, pages 473–486.

Springer, 2008.

[30] P. Bjesse, T. Leonard and A. Mokkedem. Finding Bugs in an Alpha

Microprocessor using Satisfiability Solvers. In Computer Aided Verifi-

cation, volume 2102, pages 454–464. Springer, 2001.

BIBLIOGRAPHY 86

[31] P. Curzon, S. Tahar and O. Ait-Mohamed. Verification of the MDG

Components Library in HOL. Theorem Proving in Higher-Order Logics:

Emerging Trends, pages 31–46, 1998.

[32] P. Sule, Y. Kim and N. Mansouri. PROVERIFIC: Experiments in Em-

ploying (PSL) Standard Assertions in Theorem-Proving-based Verifica-

tion. In Midwest Symposium on Circuits and Systems, pages 112–115,

2005.

[33] R. Kaivola and M.D. Aagaard. Divider Circuit Verification with Model

Checking and Theorem Proving. In Theorem Proving in Higher Order

Logics, volume 1869, pages 338–355. Springer, 2000.

[34] R. Kumar, C. Blumenrohr, D. Eisenbiegler, and D. Schmid. Formal Syn-

thesis in Circuit DesignA Classification and Survey. In Formal Methods

in Computer-Aided Design, volume 1166, pages 294–309. Springer, 1996.

[35] R.P. Kurshan and L. Lamport. Verification of a Multiplier: 64 Bits and

Beyond. In Computer Aided Verification, volume 697, pages 166–179.

Springer, 1993.

[36] S. Kort, S. Tahar and P. Curzon. Hierarchical Formal Verification using

a Hybrid Tool. International Journal on Software Tools for Technology

Transfer, 4(3):313–322, 2003.

[37] S. Reda, A. Salem. Combinational Equivalence Checking using Boolean

Satisfiability and Binary Decision Diagrams. In Conference on Design,

Automation and Test in Europe, pages 122–126. IEEE Press, 2001.

[38] S. Shiraz. AFVGCC: A Tool for the Automatic For-

mal Verification of Generic Combinational Circuits,

http://save.seecs.nust.edu.pk/projects/afvgcc/index.html, 2014.

BIBLIOGRAPHY 87

[39] S.H. Taqdees and O. Hasan. Formalization of Laplace Transform using

the Multivariable Calculus Theory of HOL-Light. In Logic for Pro-

gramming, Artificial Intelligence, and Reasoning, volume 8312, pages

744–758. Springer, 2013.

[40] T. Braibant. Coquet: A Coq Library for Verifying Hardware. In Certified

Programs and Proofs, volume 7086, pages 330–345. Springer, 2011.

[41] U. Ressi, A. Fedeli, M. Boschini and F. Toto. Concrete Impact of For-

mal Verification on Quality in IP Design and Implementation. In Inter-

national Symposium on Quality Electronic Design, pages 38–43. IEEE,

2001.

[42] V.K. Pisini, S. Tahar, P. Curzon, O. Ait-Mohamed and X. Song. Formal

Hardware Verification by Integrating HOL and MDG. In Great Lakes

Symposium on VLSI, pages 23–28. ACM, 2000.

[43] V.M. Rodrigues, D. Borrione and P. Georgelin. An ACL2 Model of

VHDL for Symbolic Simulation and Formal Verification. In Symposium

on Integrated Circuits and Systems Design, pages 269–274. IEEE, 2000.

[44] W.A. Hunt, Jr. Verifying via Nano Microprocessor Components. In

Conference on Formal Methods in Computer-Aided Design, pages 3–10.

FMCAD Inc, 2010.

[45] W.A. Hunt, Jr., S. Swords, J. Davis, and A. Slobodova. Use of For-

mal Verification at Centaur Technology. In Design and Verification of

Microprocessor Systems for High-Assurance Applications, pages 65–88.

Springer, 2010.

BIBLIOGRAPHY 88

[46] X. Sun, F. Xie, J. Wu and X. Song. Verification of a Network ASIC

Component using Bounded Model Checking. International Journal of

Electronics, 94(2):183–196, 2007.

[47] Y. Watanabe, N. Homma, T. Aoki and T. Higuchi. Application of Sym-

bolic Computer Algebra to Arithmetic Circuit Verification. In Interna-

tional Conference on Computer Design, pages 25–32. IEEE, 2007.

[48] Y.A. Chen and R.E. Bryant. Verification of Floating-Point Adders. In

Computer Aided Verification, volume 1427, pages 488–499. Springer,

1998.

towards automatic formal veri cation of generic...

Documents