1 national university of sciences and technology...

A HOL Library for Hardware Verification using Theorem Proving

Sumayya Shiraz1 and Osman Hasan2

1School of Electrical Engineering and Computer ScienceNational University of Sciences and Technology, Islamabad, Pakistan

Email: [email protected] of Electrical Engineering and Computer Science

National University of Sciences and Technology, Islamabad, Pakistan

Email: [email protected]

Abstract

Efficient verification of digital designs is of utmost importance due to their extensive use in manysafety-critical applications. In this respect, formal verification has been widely acknowledged to be farbetter, accurate and efficient as compared to the traditional simulation approach. However, automatictheorem provers and model checking techniques cannot tackle large circuits due to the associated highcomputational requirements. Interactive theorem provers, using higher-order logic, can overcome theselimitations by verifying generic circuits and universally quantified properties but they require explicituser guidance, which makes them quite uninteresting for industry usage. As a first step to overcomethese issues, this paper presents a library of formally verified generic circuits for all the commonlyused hardware modules using the HOL4 theorem prover. This library can in turn be used to verifythe structural view of any arbitrary combinational circuit against its behavior with very minimal user-guidance. For illustration purpose, the proposed library has been used for the verification of manycombinational circuits, including a 24-bit adder/subtractor, the 8-bit shifter module of benchmarkcircuit c3540, the 17-bit EqualZ W module of benchmark circuit c2670, a 16:1 Multiplexer circuitusing a 4:16 Decoder, a 512-bit Multiplier circuit and n-bit arithmetic logic unit (ALU).

1 Introduction

Verification of digital designs is of utmost importance due to the heavy costs of undetected bugs andtheir extensive usage in many safety-critical domains, such as health and transportation. Traditionally,digital designs are verified using simulation, which ascertains the correctness of the design by observingthe behavior of the circuit under a subset of all possible inputs due to the inability to perform exhaustivesimulation for large circuits. Due to the non-exhaustive nature of simulation, it cannot guarantee accurateanalysis [1].Formal verification [2] is an accurate alternative to simulation that overcomes its limitations by provingor disproving the correctness of the given design against its desired properties mathematically. The mainprinciple behind formal analysis of a digital circuit is to construct a computer based mathematical modelof the given circuit and formally verify, within a computer, that this model meets rigorous specificationsof intended behavior. Thus, the engineer working with a formal methods based verification tool has todevelop a formal model of the given circuit and the formal specification of the desired properties. Moreover,she may be involved in the verification task as well. There are some formal verification tools, mainly based

1

on model checking [3] and automated theorem proving techniques [4], that accept Verilog models [5] andautomatically translate them to the corresponding formal models and also automatically verify the rela-tionship between the formal model and its corresponding specification. Thus, the verification engineer hasto be involved in the formal specification of the properties only. These kind of tools, such as FormalPro byMentor Graphics, Conformal by Cadence, Synopsys Hector, Calypto’s SLEC and Formality by Synopsys,are quite well-suited for the industrial setting and are thus widely accepted by the industry as well. How-ever, they have a somewhat limited scope and scalability issues. For example, model checking is generallylimited 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 anexponential increase in computations with an increase in the number of variables and intermediate nodes.Interactive theorem provers [4], using the expressive higher-order logic, can overcome these shortcomingsbut at the cost of explicit user involvement. The verification engineer needs to manually construct a logicalmodel of the system and then verify the desired properties while guiding the theorem proving tool. Thiscould be a very rigorous process and the user needs to be an expert in both system design and theoremproving skills. This drawback limits the usage of higher-order-logic theorem proving in the mainstreamhardware industry where the engineers prefer to have push-button type tools.The main scope of this paper is to facilitate the usage of an interactive theorem prover for the verificationof combinational circuits by minimizing the user involvement. In this regard, we present a library offormally verified generic circuits of commonly used components, such as various implementations of n-bitAdders, n:1 Multiplexers, 1:n Demultiplexers, n:2n Decoders, 2n:n Encoders and n-bit logic gates. Themain challenge in this library development was to identify, formalize and verify generic versions, i.e.,for aribitrary length inputs, of most of the commonly used combinational circuits. Our formalization andverification is primarily inspired by the formal hardware verification approach initially proposed by Gordonand Melham [6]. The verification of the generic components is done interactively but the availablility ofthis library greatly faciliates the verification of more complex designs. The user of the proposed approachwould provide the structure of the combinational circuit to be verified in terms of its sub-components, basedon the existing components in the proposed library, and its desired behavior in the language supportedby the HOL4 theorem prover. The relationship between the structural view and the behavior of the givencircuit can then be verified using the library of formally verified generic circuits in a very straightforwardmanner. Thus, the user of our methodology can leverage upon the strengths of interactive theorem provingwithout being involved in the manual formalization and verification tasks. The effectiveness and utilizationof the proposed methodology is illustrated by verifying a number of real-world combinational circuitsautomatically, like a 24-bit adder/subtractor, the 8-bit shifter module of benchmark circuit c3540, the17-bit EqualZ W module of benchmark circuit c2670, a 16:1 Multiplexer circuit using a 4:16 Decoder,a 512-bit Multiplier circuit and a n-bit ALU. We have used the HOL4 theorem prover [7] as our proofassistant due to its long term relationship with hardware verification [6].The rest of the paper is organized as follows. In Section 2, we present a review of the related work.Then in Section 3, the proposed methodology is explained in detail. The formal verification of genericcombinational circuits using the HOL theorem prover are explained in Section 4. Then in Section 5, theworking of the proposed methodology is explained using a running example. Finally, Section 6 concludesthe paper.

2

2 Related Work

There is a plethora of research available in the formal verification of hardware designs in the last twodecades and the area primarily got a huge interest due to the infamous Intel Pentium’s bug [8] in mid1990s. We have classified these in terms of the formal verification techniques.

2.1 Assertions

In assertion based verification, assertions are used in conjunctions with simulation to formally express andverify the required behavior of the hardware [9]. This approach has been found to be way faster thanthe regular simulation and has been used to develop a language HDVL for both designing and verifying asystem using assertions [10]. Assertions have been found to be very helpful for debugging industrial levelFPGA designs [11]. But due to the simulation based verification, the results cannot guaranteed to becomplete and there is always a risk of missing the test case that reveals the bug.

2.2 Computer Algebra

Computer algebraic algorithms have also been used to verify many combinational circuits - Galois Fieldarithmetic circuits [12], arithmetic datapaths [13], arithmetic circuits [14] and Galois Field multipliers [15].The good thing about these algorithms is the fact that the analysis is done symbolically and thus there isno risk of missing test cases. However, the simplification algorithms themselves may contain bugs as theyare not formally verified. Moreover, computer algebra systems are generally only good at xor-dominatedcircuits..

2.3 Combinational Equivalence Checking

Combinational equivalence checking using various automatic techniques - SAT solver [16,17], FSM traversaland random simulation [17], BDD and boolean satisfiability [18] and model checking [19] - has beenextensively used to check if two circuits produce the same output or not. But the scope of the currentpaper is checking the circuit against its required specification, which is quite different than the equivalencechecking.

2.4 Model Checking

The main strength of model checking is to automatically and exhaustively verify temporal properties forfinite 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 IIIchip [20]. A very scalable system-level hardware verification methodology is described in [21] and the mainidea is to reduce the verification goal of a large systems into a finite number of subgoals, which are thendischarged using the SMV model checker. Multi-agent systems are verified using model checking via Or-dered Binary Decision Diagrams [22]. A generic model checking based tool is developed for the verificationof protocols and reactive systems written in C, C++, Java, Verilog and VHDL [23]. The bounded modelchecking technique allows to somewhat cater for the inherrent state-space explosion problem [3] of model

3

checking. Thus, large digital designs, such as C and Verilog programs [24], Alpha microprocessor [25]and an implementation of an Asynchronous Transfer Mode (ATM) network switching module [26] havebeen verified using the NuSMV tool. The main strength of model checking is the automatic verificationof temporal properties. However, the high computational requirements of model checking does not allowverifying circuits with very large number of inputs or high complexity. The scope of the current paper isto use higher-order-logic theorem proving to overcome this problem and thus the proposed methodologycan work in conjunction with model checking to accurately verify complete hardware designs, includingboth combinational and sequential components.

2.5 Automated Theorem Proving

In theorem proving or automated reasoning [4], the system that needs to be analyzed is mathematicallymodeled in an appropriate logic and the properties of interest are verified using computer based formaltools. The core of theorem provers usually consists of some well-known axioms and primitive inferencerules. Soundness is assured as every new theorem must be created from these basic axioms and primitiveinference rules or any other already proven theorems.The ACL2 theorem prover has been widely used to verify digital circuits. For example, it has beenused in conjunction with symbolic simulation for verifying hardware [27] and VIA nano microprocessorcomponents [28]. However, using symbolic simulation compromises the completeness of the analysis andthus accuracy. Similarly, ACL2 has also been used with IBM’s SixthSense model checker [29,30] to developa hybrid verification framework for digital hardware. But the scalability of this technique is a major concernsince the state transition checks grow exponentially for large circuits and thus the automatic verificationcapability is compromised.

2.6 Interactive Theorem Proving

Interactive theorem provers or proof assistants can be used to reason about higher-order logic and thuscan be used to verify generic theorems with arbitrary continuous variables, which cannot be handled bypropositional and first-order logic theorem provers. Thus, PVS has been used for the verification of somelarge designs, including some FPGA designs [31] and the floating point unit used in the VAMP processor[32], which supports addition, subtraction, multiplication, division, comparison, and conversions. Similarly,a hardware verification tool, called PROVERIFIC [33], allows PSL assertions to be used with PVS. Allthe above-mentioned works require explicit user guidance in the proof process. Moreover, these works arededicated towards a particular circuit and are thus not generic.The Coq theorem prover is based on the Calculus of (Co)Inductive Constructions (CiC) and featuresdependent types, which are quite helpful in creating reliable circuit models as errors can be caught earlierby type checking [34]. Braibant [34] has created a library in Coq to facilitate modeling and verifyinghardware circuits. Although dependent types, available in this library, are helpful in creating reliabledefinitions, the library still requires the user to guide the proof tools, which somewhat limits the scope ofthis work for industrial usage. A step-by-step procedure for the formal verification of a multiplier in CiC isgiven in [35]. But this work also requires extensive user interaction for verifying new designs and is specificfor one example only.

4

The HOL theorem prover has been used for the verification of the SPW Data-strobe (DS) encoding [36] andmultiway decision graphs (MDG) components library [37]. Both of these works are application specific. Ahardware platform for a gate level electronic control unit has been implemented and verified in HOL [38].But in this work, verification is done interactively and also it is not generic. Similarly, the HOL Lighttheorem prover has been used for the verification of floating-point algorithms for division, square root andtranscendental functions [39]. However, the verification does not involve the gate level implementationsand requires significant user interaction.

2.7 Hybrid Techniques

Many hybrid techniques, based on the idea of exploiting the strengths of interactive theorem proving andautomatic verification tools, have been developed as well. The HOL theorem prover has been integratedwith MDG for hardware verification [40,41]. Similarly, the Pipelined Double-Precision IEEE Floating-PointMultiplier is verified by the Voss hardware verification system using a combination of theorem proving andmodel checking [42]. The Floating point divider unit of an Intel IA-32 microprocessor [43] and large-scaleindustrial trials on datapath-dominated hardware [44] are formally verified using the Forte framework,which uses ThmTac theorem-prover and the symbolic trajectory model checker. However, the verificationin the Forte framework requires user interaction. The COSPAN model-checker and the TLP theoremprover are used to verify a multiplier of 64-bits and beyond [45]. All the above works are focused on oneor a subset of combinational circuits. Similarly, due to their hybrid nature require a lot of user guidanceand also suffer from the state-space explosion problems.Based on the above-mentioned review, it is observed that automated theorem proving and model checking isoften found to be limited while dealing with large bit-widths circuits and often fails to verify generic resultsinvolving structural designs with arbitrary-width inputs and outputs. This is mainly due to the usage ofalgorithmic verification procedures that require extensive computational resources while dealing with largedesigns involving wide bit-widths. On the other hand, the proposed hardware verification approach isprimarily based on natural deduction and it utilizes both automatic and interactive theorem proving. Themain idea is to interactively reason about the correctness of generic expressions for the relationships betweenstructural and behavioral representations of commonly used combinational circuits using the principles ofnatural deduction using a proof assistant. These formally verified results can then be specialized for anyparticular bit-widths and used to transform a proof goal regarding the relationship between structuraland behavioural representation of a circuit to a proof goal involving behavioral representations only. Wepropose to invoke automatic theorem proving at this level as verifying relationships between behavioralrepresentations can be handled automatically much more efficiently.

3 Proposed Methodology

The proposed methodology, shown in Fig. 1, requires two inputs: (i) A higher-order-logic model of thestructural connections of various components of the circuit that is needed to be verified, i.e., implementa-tion and (ii) the formal specification or the required behavior of the given circuit. The final output of ourmethodology is the formally verified relationship between these two models of the given circuit. It is impor-tant to note here that the main objective of our methodology is to obtain this result with very minimal user

5

interaction. The library of formally verified generic circuits depict the core components that facilitate theautomatic and generic characteristics of our methodology. We have developed a library of formal definitionsand formally verified theorems corresponding to most of the commonly used combinational logic blocksthat includes all logic gates, n-bit Ripple Carry Adder, n-bit Carry Select Adder, n-bit Multiplier, n:2n

Decoder, 2n:n Encoder, n:1 Multiplexer and 1:n Demultiplexer by building upon the Boolean, Arithmeticand List theories of the HOL theorem prover. All these definitions and theorems are generic and hencecan be used for the formal verification of any type of the circuit irrespective of its size and complexity.It is important to note here that the verification of these generic circuits required explicit user guidance.But once verified, the corresponding formally verified theorems facilitate the almost automatic verificationof 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 toinclude more foundational components and their area/performance efficient implementations to broadenthe verification scope of our methodology. This idea is kind of inherited from the concept of standard cellbased ASIC designs, where the various standard cells are developed by the library vendors and the ASICdesigners can then use the standard cells to construct their ASIC designs.

Figure 1: Proposed Methodology

The first step of the proposed methodology is to develop a formal model of the structure of the combi-national circuit to be verified. The structure of a combination circuit is usually expressed in a hardwaredescription language, such as Verilog or VHDL, and a corresponding formal model can be developed in astraightforward manner by utilizing the formally verified generic component names and formally expressingtheir interconnections. Besides the formal model, we also require a formal specification, i.e., the behavioraldescription of the given circuit. This behavior is usually expressed using conditional if-else statements andarithmetic and logical operators.

6

The second step is to formally verify that the given circuit implies the specification given by the user. Inorder 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 verificationis almost automatically done as the same rewriting tactics are required. The exceptions happen whenthe specification is given as a complex arithmetic expression, which does not have a very straightforwardrelationship with the structure. In these cases, the user can provide proof guidance while interactingwith the HOL user interface in the traditional interactive theorem proving style. However, these casesseldom arise and the approach concludes with very minimal user interaction in most of the cases, as will beillustrated by the case studies performed as part of this work. Finally, upon the successful verification, theuser gets a formal proof of system properties that specify that given circuit’s code implies the specificationgiven by the user as shown in Fig. 1.It is worth mentioning here that the structural and behavioral models are manually developed in theproposed approach and thus are susceptible to make translation errors. But the chances of verifying wrongcircuits are very low since the chances of making the corresponding errors in both the specification andimplementation and thus verifying their equivalence are less. What can practically happen is that eitherthe specification or the implementation may get a translation bug but this can be caught during the formalverification phase and thus rectified. It is important to note here that the proposed verification methodologyallows the verification of equivalence relationships between the implementation and specification models ofthe given circuit. This kind of strong relationship removes the possibility of verifying a theorem betweena partial specification and the complete implementation and vice versa. Obviously, the above-mentionedrisk would be there if we verify theorems involving implication relationships between the specification andimplementation of the given circuit but, in this case, the user would be aware of the consequences ofverifying a rather weak property.

4 Formal Verification of Generic Combinational Circuits

This section explains the formal definitions and verification of equivalent behaviours of the commonlyused combinational components, mentioned in Fig. 1. This formalization, mainly inspired by the seminalwork on digital circuit verification done at the University of Cambridge, UK [6], is the core componentthat allows the automatic formal verification of generic combinational circuits. The main idea is to modelgeneric (arbitrary-input) circuit diagrams of combinational circuits. i.e., circuit implementations, by usingtheir logical components and their interconnections. The inputs and outputs of these circuits are modelledas lists of booleans to allow generic definitions. The primary inputs and outputs of these definitions areuniversally quantified while the internal connection points, hidden from the external world, are introducedusing existential quantifiers. The behavior, or specifications, of these combinational circuits is representedin terms of their desired input-output relationships. The relationships between the implementations andtheir corresponding specifications are then verified using induction on the input variables within the soundcore of a theorem prover.

7

4.1 Logic Gates

In this section, we describe the formal definitions for all of the primitive logic gates. All definitions, exceptthe inverter, are generic and thus they can be used to model the respective gate of any number of inputs.

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 theinverter 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. Thesecond function and n describes the behavior of the n-bit and gate in the predicate form. In the abovedefinitions, h::t refers to a list with h as its head and t as its tail. The NAND gate can now be formalizedusing 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 booleanlist. The second function or n describes the behavior of the n-bit or gate in the predicate form. The NORgate 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))

8

` ∀ 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 thefinal outcome of the XOR gate as:

Definition 7: n-bit XNOR gate

` ∀ h t out. xnor n (h::t) out= (out = ¬xor (h::t))

4.2 Multiplexer

The n:1 Multiplexer (Mux) [46] passes the signal of any one of the n input data lines to the one bit outputline depending upon the log2n input select lines. Fig. 2 is depicting the recursive implementation of ageneric n:1 Mux, where n is the width of data input lines a, k is the width of select input lines s and b isa boolean output signal. The relation between the width of select and data input lines can be specified bythe equation k = log2n, or in other words n = 2k.

Figure 2: Recursive Implementation of n:1 Mux

The primitive 2:1 Mux can be implemented using basic logic gates, as shown in Fig. 3 and is formallydefined 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

9

Figure 3: Implementation of 2:1 MUX

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 halfof the length of the given list a, i.e., (LENGTH a) DIV 2, the HOL expression (TAKE n a) picks the topn elements from the list a, the HOL expression (DROP n a) drops the top n elements from the list a andrecursion is done on the input select lines h::t. The next step is to define the behavior (specification) ofthe 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)

10

where the function BV converts a boolean variable to its corresponding number, i.e, BV b = if b then

1 else 0 [47]. The relationship between the specification and implementation of the 2:1 and n:1 Mux isformally 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 assumptions in Theorem 2, ensure thatthere is atleast one select line and the relationship between the input data and input select lines. Theformal verification of Theorem 1 is primarily based on induction of variable s.

4.3 Decoder

The recursive implementation of a n:2n Decoder [46], shown in Fig. 4, is implemented using 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 setsthe bits of the output signal depending upon the binary number represented by the input data vector.

Figure 4: Recursive Implementation of n:2n Decoder

11

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 toits corresponding boolean value: if (n = 0) then F else T. The relationship between the specificationand 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 andthe relationship between the data input and the data output vectors.

4.4 Demultiplexer

The functionality of Demultiplexer [46] is quite similar to that of the Decoder with the difference thatDecoder sets one of the output lines depending upon the input signal while the Demultiplexer transmits theinput data to one of the output lines depending upon the input select lines. Fig. 5 shows an implementationof the Demultiplexer using a Decoder, where the data input signal of the Demultiplexer a, is connected tothe enable signal of the Decoder, the select input signal of the Demultiplexer s, is connected to the datainput signal of Decoder and the data output signal of the Demultiplexer b, is connected to the data outputsignal of Decoder. The relation between the width of select line k, and the width of the data output linesn, can be specified by the equation k = log2n, or in other words n = 2k.

12

Figure 5: 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 formallydefined 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 Demulti-plexer and relationship between the output data and the input select vectors.

4.5 Encoder

The Encoder [46] generates a binary output code for one bit of input True at a time. There are twodiscrepancies that may happen with the Encoders, i.e., the output behavior is non-deterministic in thecase when more than one input bits are True at a time or all input bits are zero. Priority Encoder[46] resolves these issues, by encoding output on the basis of priority and by using a valid output bit,respectively. Fig. 6 presents a recursive implementation of a 2n:n Priority Encoder using two 2n−1:(n-1)

13

Encoders, which encodes on the bases of the highest priority of the input signal, i.e., all other bits of theinput data signal are ignored if the most significant bit of the data input signal is True.

Figure 6: 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, pconnected with the valid output signal of the first Encoder, is used to enable the second Encoder, when thetop half of the input data vector contains all False elements, v is the valid output signal, which indicatesthe validity of the encoded output data signal, and the function encod 2to1 imp computes the head of theoutput data signal using NOT, AND gates and a 2:1 Mux as depicted by Fig. 7. The formalized definitionof the implementation of encod 2to1 is given below:

14

Figure 7: 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 recursively 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 encoded. In order to simplify theverification 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

15

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)

4.6 Ripple Carry Adder

A recursive implementation of n-bit Ripple Carry Adder [46] is shown in Fig. 8, where d1 and d2 are thetwo data input vectors which are required to be added, cin is the boolean carry input, cout is the booleancarry output and s is the sum output vector of the adder.

Figure 8: Recursive Implementation of n-bit Adder

One bit adder is implemented using the basic logic gates, i.e., XOR, AND and OR gates, as depicted inFig. 9 and is formalized in HOL as:

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:

16

Figure 9: 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 functionAdder imp n describes the behaviour of the first function in the predicate form giving outputs in booleancarry 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-bitadder 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)

17

The relationship between the implementation and specification is proved as a theorem, where the assump-tions 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)

4.7 Carry Select Adder

The formalization of the Carry Select Adder [46] is quite similar to that of the Ripple Carry Adder sinceboth share the same recursive implementation, shown in Fig. 8. The main difference is the implementationof the 1-bit adder, which is implemented using a Mux and full adder as shown in Fig. 10. The idea isto obtain the addition for 1-bit data using two full adders working in parallel for both cases of the carryinput, i.e., ’T’ and ’F’. The final values for sum and carry-out are chosen based on the input value of carryusing a Mux. This behavior can be formalized in HOL as follows:

Figure 10: 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 thefull adder behavior and the function mux implements the 2:1 multiplexer behavior using basic logic gates.

18

The formal definition of the implementation of the n-bit Carry Select Adder using 1-bit Carry Select Adderis 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 functionCSA imp n describes the behaviour of the first function in the predicate form. As behaviour of the adderis always same, whether Carry Select Adder is used or Ripple Carry Adder is used, hence same definitionsare used for the specification as used for the case of Ripple Carry Adder which are described in Definitions24 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.

4.8 Multiplier

The recursive implementation of a n-bit Multiplier [46] is shown in Fig. 11, where each bit of the multipli-cand d2, is multiplied one-by-one with the multiplier d1, making partial products, which are then addedusing a Ripple Carry Adder.

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)

19

Figure 11: Recursive Implementation of n-bit Multiplier

where the first function mult imp is multiplying two data inputs, the second function mult imp n describesthe behaviour of the first function in the predicate form giving product in data output lines i.e., p, the func-tion mult imp 1 is implementing 1-bit multiplier shown in Fig. 12 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 inFig. 12and 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 entireinput 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)

20

Figure 12: Implementation of 1-bit Multiplier

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 universallyquantified theorems for the correctness of generic combinational circuits with arbitrary inputs, is the abilityto use them for automatically verifying a wide range of combinational circuits, as depicted in Fig. 1. Thisbenefit is attained at the cost of extensive user-effort spent in guiding the HOL theorem prover for verifying

21

these theorems. The formalization, presented in this section, took around 7000 lines of HOL code andapproximately 12 man-months. A significant amount of time was also spent on identifying the genericimplementations of the common combinational circuits that can be expressed recursively. Moreover, theproof sketches of the theorems, presented in this section, could not be obtained in any text and we developedas part of the reported work as well. The proof script, corresponding to the verification of some of thecircuits, is available at [48] for download, and the others can also be obtained under a license by contactingthe authors.

5 Case Studies

In order to evaluate the effectiveness of the proposed methodology, shown in Fig. 1, we used it to for-mally verify many combinational circuits including a 24-bit adder/subtractor, the 8-bit shifter module ofbenchmark circuit c3540, the 17-bit EqualZ W module of benchmark circuit c2670, a 16:1 Multiplexercircuit using a 4:16 Decoder and a 512-bit Multiplier circuit. All these circuits were verified on a Ubuntuworkstation with Corei5-2320 processor operating at 3GHz with 4GB memory and their results are shownbelow in Table 1. It is important to note that these results have been obtained using the same proof scriptand thus without any user guidance. The accuracy and automation in verification are the main benefitsprovided by our proposed methodology. It is also worth-mentioning here that despite of the use of largernumber of inputs and larger number of gates in the circuits, the proposed methodology has been able tosuccessfully verify them in less than a couple of minutes, as can be seen in Table 1.

Table 1: Results of Case studiesCircuit Name Bench-

markNumberof Inputs

Numberof Gates

VerificationTime (s)

24-bit Adder/subtractor - 49 144 018-bit Shifter c3540 29 201 6016:1 Multiplexer - 20 62 0317-bit EqualZ W c2670 35 25 0.3512-bit Multiplier - 1024 1572864 126

5.1 24-bit Adder/Subtractor

In this section, we explain the step-by-step working of the proposed methodology using the 24-bit adder/subtractor,shown in Fig. 13, 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, which can be translated toits corresponding formal model in HOL as follows:

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

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

22

Figure 13: Implementation of 24-bit Adder/Subtractor

? xb23...xb0.

xor_n [b23;sel] xb23 ∧ xor_n [b22;sel] xb22 ∧xor_n [b21;sel] xb21 ∧ xor_n [b20;sel] xb20 ∧xor_n [b19;sel] xb19 ∧ xor_n [b18;sel] xb18 ∧xor_n [b17;sel] xb17 ∧ xor_n [b16;sel] xb16 ∧xor_n [b15;sel] xb15 ∧ xor_n [b14;sel] xb14 ∧xor_n [b13;sel] xb13 ∧ xor_n [b12;sel] xb12 ∧xor_n [b11;sel] xb11 ∧ xor_n [b10;sel] xb10 ∧xor_n [b9;sel] xb9 ∧ xor_n [b8;sel] xb8 ∧xor_n [b7;sel] xb7 ∧ xor_n [b6;sel] xb6 ∧xor_n [b5;sel] xb5 ∧ xor_n [b4;sel] xb4 ∧xor_n [b3;sel] xb3 ∧ xor_n [b2;sel] xb2 ∧xor_n [b1;sel] xb1 ∧ xor_n [b0;sel] xb0 ∧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;

23

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

The functions xor n and Adder imp n represent our formal model of the generic XOR gate and an n-bitRipple Carry Adder, described in the previous section.

Besides providing the structural view of the circuit, the user is also responsible for providing the formalspecification of the given circuit. Note that the binary subtraction is carried out by adding input a withthe 2’s complement of the input b.

` ∀ 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 alomstautomatically verified as a HOL theorem:

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

24

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(It takes less than a second).

5.2 8-bit Shifter Module of Benchmark Circuit c3540

In this section, formal verification of 8-bit shifter module of benchmark circuit c3540, shown in Fig. 14, iscarried out.

Figure 14: 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 depending upon a boolean inputcnt3. If cnt3 is True, left shifting takes place, otherwise right shifting occurs. The data input signal whichis 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 shiftingthe signed bit of the input data signal. The input to the proposed methodology, is the structural view ofthe circuit in which user uses the modules of and, or, Decoder and Mux of our library and formally expresstheir interconnections as follows:

25

∀ 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 ∧and_n [a2;sel2] t2 ∧ and_n [a3;sel3] t3 ∧and_n [a4;sel4] t4 ∧ and_n [a5;sel5] t5 ∧and_n [a6;sel6] t6 ∧ and_n [a7;sel7] t7 ∧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 ∧Mux8_1 a6 b6 c6 q6 r6 x6 y6 z6 sel7 sel6 sel5 sel4 sel3 sel2 sel1







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.

26

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 [sr4;sq4] [cnt3] s4 ∧ mux_imp_n [sr3;sq3] [cnt3] s3 ∧mux_imp_n [sr2;sq2] [cnt3] s2 ∧ mux_imp_n [sr1;sq1] [cnt3] s1 ∧mux_imp_n [sr0;sq0] [cnt3] s0.

The behavior of the given shifter circuit is formally expressed using if-else statements in HOL 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

27

([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]))

28

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 verified in astraightforward manner as a HOL theorem shown below which involves Definitions 11 and 14 along withTheorems 2 and 3 for verification. Proof script involves rewriting tactics along with arithmetic reasoningwhich is repeated number of times depending upon if-else statements usedS in the definition of specificationgiven by the user.

29

` ∀ 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 benchmark circuit c2670, shown inFig. 15 is carried out. It is a simple module which gives True at output signal eq when any bit of the two16-bit data input signals, i.e. z and w are equal. The boolean output signal neq indicates that all bits ofthe both data signals are unequal.

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

The input to the proposed methodology is the structural view of the circuit described formally by the userusing formal definitions of logic gates of our library as:

30

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

where function xor17bit is implementing arrays of XOR gates and the function AN18 is implementingarrays of AND gates. After providing the structural view of the circuit, the user provides the desired

31

behaviour of the given circuit formally 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

z1 z0 w16 w15 w14 w13 w12 w11 w10 w9 w8 w7 w6 w5 w4 w3 w2 w1 w0 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).

Where, each bit of the two data input signals are checked and True is given to signal neq, if all areunequal. Then the output signal eq is computed using the result of neq. The equivalence between theformal implementation and specification of the given circuit is almost automatically verified as a HOLtheorem 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. 16, is carried out, in which4-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 givesthe result on 1-bit output signal y. The input to the proposed methodology is the structural view of thecircuit formally defined as:

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

32

Figure 16: Implementation of a 16:1 Multiplexer

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 defined formally by the user as:

33

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

The behaviour is specifying that element of input data list, i.e., a is is selected on the basis of selectlines and is given to the boolean output, i.e.,y. Then equivalence between the formal implementation andspecification of the given circuit is almost automatically verified as a HOL theorem given below whichinvolves 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. 17, is carried out, in whichtwo 512-bit data input signals a and b are multiplied to give product in the data output signal y.The circuit under verification can easily be formally defined by using multiplier module of our library as:

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

y1023 y1022......y1 y0.

34

Figure 17: Implementation of a 512-bit Multiplier

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 formally defined by the user as:

∀ 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 almost auto-matically 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.

35

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.

5.6 n-bit Arithmetic Logic Unit (ALU)

Besides the verification of circuits with known number of bits, our formalised theories can also be used toverify n-bit circuits. In order to illustrate this process, consider the verification of an n-bit arithmetic logicunit (ALU), shown in Fig. 18. It takes three n-bit inputs, a, b and c, which can be optionally inverteddepending upon the signals nega, negb and negc. These signals along with other enable signals, enab andenc, generate different outputs of the ALU: A.B, −A.B, A.B + C, A.B − C, −A.B + C, −A.B − C, etc.This ALU has been recently formally verified for operand widths ranging form 4 to 256 bits taking 0.01 to34.66 seconds [49]. To illustrate the effectiveness of the proposed verification methodology, we show howwe can use it to formally verify this ALU design for n-bit operands.

Figure 18: Implementation of a n-bit Arithmetic Logic Unit

The first step is the formalization of the implementation of the given circuit, which can be defined usingthe pre-verified components of our library as follows:

∀ n a b c nega negb negc enab enc y co =

36

∃ FA FB FC FAB FABen FCen.

mux_neg1_imp a nega FA ∧mux_neg1_imp b negb FB ∧mux_neg1_imp c negc FC ∧mult_imp_n FA FB FAB ∧and_list_imp FAB enab FABen ∧and_list_imp FC enc FCen ∧Adder_imp_n (n + n) FABen

(make_list_F n ++ FCen)

F y co

Where, the variable n represents the operand widths for variables a, b and c. The function mux neg1 imp

represents a combination of a multiplexer and a not gate, shown in Fig. 19, such that it allows to selectbetween a given arbitrary-width input and its inverted signal depending upon the select signal nega.Similarly, the function and list imp models a series of and gates for performing the logical conjunction ofa single bit signal en with all elements of input list a individually. For simplification, we have first of alldescribed the behaviour of these functions and then verified them formally as a theorem to be used later.Verification process of mux neg1 and and list is described below:

The Mux neg1 is a combination of multiplexer for list (mux list) and not gate (not 0) as shown in Fig.19. First of all, it inverts the input data signal and then passes either of the input data lines, a or itsinverted data lines, na, to output data lines y, depending upon the boolean select signal sel. The definitionof mux list is given below:

Figure 19: Implementation of mux neg1

Definition 34: Implementation of mux list

37

` ∀ a b sel. (mux list 0 [] b sel= []) ∧(mux list 0 (h::t) b sel =

mux 0 imp h (HD b) sel::mux list 0 t (TL b) sel)

` ∀ a b sel y. mux list imp a b sel y = (y = mux list 0 a b sel)

where, the expression mux 0 imp is 2:1 mux, defined as nand (nand in2 (not sel)) (nand sel in1).The next step is to define the behavior (specification) of the mux list.

Definition 35: Specification of mux list

` ∀ a b sel. mux list spec a b sel =

if sel then a else b

Definition 36: Implementation of mux neg1

` ∀ a sel y. mux neg1 imp a sel y <=>

mux list imp (not 0 a) a sel y

The specification of mux neg1 is formally defined as:

Definition 37: Specification of mux neg1

` ∀ a sel y. mux neg1 imp a sel y <=>

if sel then y = (not 0 a) else y = a

The relationship between the specification and implementation of the mux neg1 is formally verified in HOLas the following theorem:

Theorem 12: Formal Verification of mux neg1

` ∀ a b sel y.

(mux neg1 imp a b sel y <=> mux neg1 spec a b sel y)

The And list combines series of and gates for taking conjunction of boolean input en with all elementsof input data signal a. The implementation and specification of of and list is formally defined as:

Definition 38: Implementation of and list

` ∀ a b sel. (and list 0 [] en = []) ∧(and list 0 (h::t) en =

(and 0 [h;en]::(and list 0 t en)))

` ∀ a en out. and list imp a en out = (out = and list 0 a en)

The relationship between the specification and implementation of the and list is formally verified as:

Theorem 13: Formal Verification of and list

` ∀ a en. (and list 0 a en <=> and list spec a en)

Now, the behaviour of the ALU is formally defined as follows, where the binary subtraction is carriedout by taking the 1‘s complement of the desired input, i.e., BV n (not 0 a).

38

(if (enab) then

if (enc) then

if (~nega /\ ~negb /\ ~negc) then

((co::y) =

(num_BV_f (SUC (n + n))

((BV_n a * BV_n b) + BV_n c)))

else if (~nega /\ ~negb /\ negc) then

((co::y) =


((BV_n a * BV_n b) +

(BV_n (not_0 c)))))

else if (~nega /\ negb /\ ~negc) then

((co::y) =


((BV_n a * (BV_n (not_0 b))) + BV_n c)))

else if (~nega /\ negb /\ negc) then

((co::y) =


((BV_n a * (BV_n (not_0 b))) +

(BV_n (not_0 c)))))

else if (nega /\ ~negb /\ ~negc) then

((co::y) =


(((BV_n (not_0 a)) * BV_n b) + BV_n c)))

else if (nega /\ ~negb /\ negc) then

((co::y) =


(((BV_n (not_0 a)) * BV_n b) +

(BV_n (not_0 c)))))

else if (nega /\ negb /\ ~negc) then

((co::y) =


(((BV_n (not_0 a)) *(BV_n (not_0 b))) +

BV_n c)))

else

39

((co::y) =


(((BV_n (not_0 a))*(BV_n (not_0 b))) +

(BV_n (not_0 c)))))

else

if (~nega /\ ~negb) then

((co::y) =


(BV_n a * BV_n b)))

else if (~nega /\ negb) then

((co::y) =


(BV_n a * (BV_n (not_0 b)))))

else if (nega /\ ~negb) then

((co::y) =


((BV_n (not_0 a)) * BV_n b)))

else

((co::y) =


((BV_n (not_0 a))*(BV_n (not_0 b)))))

else

if (~enc /\ ~negc) then

((co::y) = (F::make_list_F (n+n)))

else if (~enc /\ negc) then

((co::y) = (F::make_list_F (n+n)))

else if (enc /\ ~negc) then

((co::y) =

(num_BV_f (SUC (n + n)) (BV_n c)))

else

((co::y) =

(num_BV_f (SUC (n + n)) (BV_n (not_0 c))))

The equivalence between the formal implementation and specification of the given circuit is verified us-ing the already verified theorems along with Theorem verified for mux neg1 and and list, in a verystraightforward manner involving very little user interaction. The main step was the replacement of theimplementation models of the components, involved in the ALU, with their corresponding specificationsby simple rewriting. This is followed by the automatic proof of equivalence between the two behavioralspecifications based on automatic theorem proving. Based on this formally verified equivalence theorem

40

with universally quantified input variables, we are able to verify corresponding equivalence relationships for512 and 1024 bit ALUs within a fraction of a second, which clearly indicates the strength of the proposedmethodology in verifying combinational circuits.

6 Conclusions

In this paper, we have presented a methodology for the formal verification of combinational circuits using ahigher-order-logic theorem prover HOL. The main motivation of our work is to verify that a given combina-tional circuit behavior (specification) is consistent with its given structure (implementation), irrespectiveof its size and complexity, in an interactive theorem prover while minimizing the manual proof guidanceeffort. For this purpose, our methodology accepts the behavior description and the structure of the circuitin HOL. The core contribution of the work is the formalization of structural and behavioral descriptionsof all commonly used circuits and the verification of their relationships using the HOL theorem prover.These formalizations are done for arbitrary n-bit circuits and thus can be used to formalize and verify anycombinational circuit. Hence, the above-mentioned verification of correspondence between the structuraland behavioral description is done automatically within the sound core of a theorem prover.

The development of formally verified combinational circuits library involved interactive verification anddetailed tool guidance. But this is a one time effort that the tool vendors can spend to facilitate automaticformal verification of arbitrary combinational circuits. It is important to note here that the idea of usinginteractive theorem proving for hardware verification dates back to mid 80s 1980s [6]. What distinguishesour work from this idea and all the other existing work in this direction, mentioned in the Section 2 of thispaper, is a practical and generic methodology that, despite being based on interactive theorem proving,allows the verification of real-world circuits almost automatically. Moreover, to the best of our knowledge,generic n-bit models for such a wide range of commonly used combinational circuits have not been verifiedin a single platform before.

The proposed work opens the door to many interesting future directions of research. The formallyverified library of circuits needs to be enhanced and advanced components like, Wallace Tree, Booth mul-tipliers and components of floating-point arithmetic units may be added. More case studies for evaluationpurposes are also underway. As long term goals, we plan to integrate a model checker with the proposedmethodology to verify both combinational and sequential circuits within the same framework. The ideawould be to replace the structure of combinational circuits with their corresponding behaviors, as verifiedin the reported work, to verify behavioral properties for complete digital circuits that contain both com-binational and sequential circuits within the model checker. The replacement of structural combinationalparts with the corresponding behavioral descriptions is expected to significantly reduce the complexityof the models and thus would be very helpful in coping with the state-space explosion problem of modelchecking while dealing with large circuits with a lot of combinational components. Our work can alsobe combined with the recently proposed theorem proving based analog circuit verification approach [50]to form a theorem proving based Analog and Mixed Signal (AMS) circuit analysis framework. Finally,currently we have done a shallow embedding of the digital circuit structures in higher-order logic and aninteresting area to work on would be to formalize them using deep embedding as is done in [51]. This willpave the way towards certified synthesis as well.

41

Acknowledgements

This work was supported by the National Research Program for Universities grant (number 1543) of HigherEducation Commission (HEC), Pakistan.

References

[1] M. J. C. Gordon and T. F. Melham, Eds., Introduction to HOL: A Theorem Proving Environment forHigher order Logic. Cambridge University Press, 1993.

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

[3] E. Clarke, O. Grumberg, and D. Peled, Model Checking. MIT press, 1999.

[4] J. Harrison, Handbook of Practical Logic and Automated Reasoning. Cambridge University Press,2009.

[5] Z. S. Andraus and K. A. Sakallah, “Automatic abstraction and verification of verilog models,” inDesign Automation Conference, San Diego, CA, USA, June 7-11,. ACM, 2004, pp. 218–223.

[6] A. C. M. Gordon and T. Melham, “Hardware Verification using Higher-order Logic,” Com-puter Laboratory, University of Cambridge, Cambridge, UK, Tech. Rep. IUCAM-CL-TR-91, 1986,www.cl.cam.ac.uk/techreports/UCAM-CL-TR-91.pdf.

[7] K. Slind and M. Norrish, “A brief overview of HOL4,” in Theorem Proving in Higher Order Logics,Montreal, Canada, August 18-21, ser. LNCS, vol. 5170. Springer, 2008, pp. 28–32.

[8] T. Coe, “Inside the Pentium-FDIV Bug,” Dr. Dobbs Journal, vol. 20, no. 4, pp. 129–135, 1995.

[9] A. Dahan, D. Geist, L. Gluhovsky, D. Pidan, G. Shapir, Y. Wolfsthal, L. Benalycherif, R. Kamidemand Y. Lahbib, “Combining System Level Modeling with Assertion based Verification,” in Interna-tional Symposium on Quality of Electronic Design. IEEE, 2005, pp. 310–315.

[10] K. Datta, P.P. Das, “Assertion based Verification using HDVL,” in International Conference on VLSIDesign. IEEE, 2004, pp. 319–325.

[11] L. Pierre, F. Pancher, R. Suescun and J. Quevremont, “On the Effectiveness of Assertion-basedVerification in an Industrial Context,” in Formal Methods for Industrial Critical Systems, vol. 8187.Springer, 2013, pp. 78–93.

[12] J. Lv, P. Kalla and F. Enescu, “Efficient Grobner Basis Reductions for Formal Verification of Ga-lois Field Arithmetic Circuits,” Computer-Aided Design of Integrated Circuits and Systems, IEEETransactions on, vol. 32, no. 9, pp. 1409–1420, 2013.

42

[13] O. Wienand, M. Wedler, D. Stoffel, W. Kunz and G.-M. Greuel, “An Algebraic Approach for ProvingData Correctness in Arithmetic Data Paths,” in Computer Aided Verification, vol. 5123. Springer,2008, pp. 473–486.

[14] Y. Watanabe, N. Homma, T. Aoki and T. Higuchi, “Application of Symbolic Computer Algebra toArithmetic Circuit Verification,” in International Conference on Computer Design. IEEE, 2007, pp.25–32.

[15] J. Lv, P. Kalla and F. Enescu, “Efficient Grobner Basis Reductions for Formal Verification of GaloisField Multipliers,” in Conference on Design, Automation and Test in Europe. EDA Consortium,2012, pp. 899–904.

[16] E. Goldberg, M. Prasad and R Brayton, “Using SAT for Combinational Equivalence Checking,” inConference on Design, Automation and Test in Europe. IEEE Press, 2001, pp. 114–121.

[17] A.K. Mishra and A. Chandra, “EQU-IITG: A Multi-Format Formal Equivalence Checker,” in Inter-national Conference on Energy, Automation, and Signal. IEEE, 2011, pp. 1–6.

[18] S. Reda, A. Salem, “Combinational Equivalence Checking using Boolean Satisfiability and BinaryDecision Diagrams,” in Conference on Design, Automation and Test in Europe. IEEE Press, 2001,pp. 122–126.

[19] U. Ressi, A. Fedeli, M. Boschini and F. Toto, “Concrete Impact of Formal Verification on Quality inIP Design and Implementation,” in International Symposium on Quality Electronic Design. IEEE,2001, pp. 38–43.

[20] Y.A. Chen and R.E. Bryant, “Verification of Floating-Point Adders,” in Computer Aided Verification,vol. 1427. Springer, 1998, pp. 488–499.

[21] K. McMillan, “A Methodology for Hardware Verification using Compositional Model Checking,” Sci-ence of Computer Programming, vol. 37, no. 1, pp. 279–309, 2000.

[22] F. Raimondi and A. Lomuscio, “Automatic Verification of Multi-Agent Systems by Model CheckingVia Ordered Binary Decision Diagrams,” Journal of Applied Logic, vol. 5, no. 2, pp. 235–251, 2007.

[23] D. Drusinsky, “The Temporal Rover and the ATG Rover,” in SPIN Model Checking and SoftwareVerification, vol. 1885. Springer, 2000, pp. 323–330.

[24] E. Clarke and D. Kroening and K. Yorav, “Behavioral Consistency of C and Verilog Programs usingBounded Model Checking,” in Design Automation Conference. IEEE, 2003, pp. 368–371.

[25] P. Bjesse, T. Leonard and A. Mokkedem, “Finding Bugs in an Alpha Microprocessor using SatisfiabilitySolvers,” in Computer Aided Verification, vol. 2102. Springer, 2001, pp. 454–464.

[26] X. Sun, F. Xie, J. Wu and X. Song, “Verification of a Network ASIC Component using BoundedModel Checking,” International Journal of Electronics, vol. 94, no. 2, pp. 183–196, 2007.

43

[27] G.Al. Sammane, J. Schmaltz, D. Toma, P. Ostier and D. Borrione, “TheoSim: Combining SymbolicSimulation and Theorem Proving for Hardware Verification,” in Symposium on Integrated circuits andsystem design. ACM, 2004, pp. 60–65.

[28] W.A. Hunt, Jr., “Verifying via Nano Microprocessor Components,” in Conference on Formal Methodsin Computer-Aided Design. FMCAD Inc, 2010, pp. 3–10.

[29] J. Sawada, P. Sandon, V. Paruthi, J. Baumgartner, M. Case and H. Mony, “Hybrid Verification of aHardware Modular Reduction Engine,” in International Conference on Formal Methods in Computer-Aided Design. FMCAD Inc, 2011, pp. 207–214.

[30] J. Sawada and E. Reeber, “ACL2SIX: A Hint used to Integrate a Theorem Prover and an AutomatedVerification Tool,” in Formal Methods in Computer Aided Design. IEEE, 2006, pp. 161–170.

[31] H. Deng, “Formal Verification of FPGA based Systems,” 2011.

[32] C. Berg and C. Jacobi, “Formal verification of the VAMP floating point unit,” in Correct HardwareDesign and Verification Methods, Livingston, Scotland, UK, September 4-7, vol. 2144. Springer, 2001,pp. 325–339.

[33] P. Sule, Y. Kim, and N. Mansouri, “PROVERIFIC: Experiments in employing (psl) standard asser-tions in theorem-proving-based verification,” in Midwest Symposium on Circuits and Systems, Cincin-nati, Ohio, (USA), August 7-10, 2005, pp. 112–115.

[34] T. Braibant, “Coquet: A coq library for verifying hardware,” in Certified Programs and Proofs,Kenting, Taiwan, December 7-9, vol. 7086. Springer, 2011, pp. 330–345.

[35] C. Paulin-Mohring, “Circuits as streams in coq: Verification of a sequential multiplier,” in Types forProofs and Programs, Torino, Italy, June 5-8, vol. 1158. Springer, 1996, pp. 216–230.

[36] L. Li, L. Liu, Y. Guan, Y. Zhang, J. Zhang, and L. Tao, “A formal method for verifying the imple-mentation of SPW,” in Conference on Spacewire, 2010.

[37] P. Curzon, S. Tahar, and O. Ait-Mohamed, “Verification of the MDG components library in HOL,”in Theorem Proving in Higher-Order Logics: Emerging Trends, Canberra, Australia, September 27 -October 1, 1998, pp. 31–46.

[38] S. Tverdyshev, “A verified platform for a gate-level electronic control unit,” in Formal Methods inComputer-Aided Design, Austin, Texas, USA, November 15-18. IEEE, 2009, pp. 164–171.

[39] J. Harrison, “Formal verification at Intel,” in Logic in Computer Science, Ottawa, Canada, June22-25. IEEE Computer Society, 2003, pp. 45–54.

[40] V. Pisini, S. Tahar, P. Curzon, O. Ait-Mohamed, and X. Song, “Formal hardware verification byintegrating HOL and MDG,” in Great Lakes Symposium on VLSI, Chicago, Illinois, USA, March 2-4.ACM, 2000, pp. 23–28.

44

[41] S. Kort, S. Tahar, and P. Curzon, “Hierarchical formal verification using a hybrid tool,” InternationalJournal on Software Tools for Technology Transfer, vol. 4, no. 3, pp. 313–322, 2003.

[42] M. Aagaard and C.-J. Seger, “The formal verification of a pipelined double-precision IEEE floating-point multiplier,” in IEEE/ACM International Conference on Computer-aided Design, San Jose,California, USA, November 5-9. IEEE Computer Society, 1995, pp. 7–10.

[43] R. Kaivola and M. Aagaard, “Divider circuit verification with model checking and theorem proving,” inTheorem Proving in Higher Order Logics, Portland, Oregon, USA, August 14-18, vol. 1869. Springer,2000, pp. 338–355.

[44] C.-J. Seger, R. Jones, J. O’Leary, T. Melham, M. Aagaard, C. Barrett, and D. Syme, “An industri-ally effective environment for formal hardware verification,” IEEE Transactions on Computer-AidedDesign of Integrated Circuits and Systems, vol. 24, no. 9, pp. 1381–1405, 2005.

[45] R. Kurshan and L. Lamport, “Verification of a multiplier: 64 bits and beyond,” in Computer AidedVerification, Elounda, Greece, June 28 - July 1, vol. 697. Springer, 1993, pp. 166–179.

[46] P. Lala, Principles of Modern Digital Design. John Wiley & Sons, 2007.

[47] A. C. M. Gordon and T. Melham, Hardware Verification using Higher-order Logic. Computer Lab-oratory, University of Cambridge, 1986.

[48] S. Shiraz, “AFVGCC: A Tool for the Automatic Formal Verification of Generic Combinational Cir-cuits, http://save.seecs.nust.edu.pk/projects/afvgcc/index.html,” 2016.

[49] C. Yu, W. Brown, and M. Ciesielski, “Verification of arithmetic datapath designs using word-levelapproach: A case study,” in Circuits and Systems, Lisbon, Portugal, May 24-27, 2015, pp. 1862–1865.

[50] S. Taqdees and O. Hasan, “Formalization of laplace transform using the multivariable calculus theoryof HOL-Light,” in Logic for Programming, Artificial Intelligence, and Reasoning, Stellenbosch, SouthAfrica, December 14-19, vol. 8312. Springer, 2013, pp. 744–758.

[51] T. Braibant and A. Chlipala, “Formal verification of hardware synthesis,” in Computer Aided Verifi-cation, Saint Petersburg, Russia, July 13-19, ser. LNCS, vol. 8044. Springer, 2013, pp. 213–228.

45

1 national university of sciences and technology...

Documents