Hardware Description Language Program Slicing and Way to Reduce Bounded Model Checking Search Overhead

Home , Icarus Verilog, Specification language

Hardware Description Language Program Slicing and way to Reduce Bounded Model Checking Search Overhead

Jen-Chieh Ou

Submitted in Partial Fulﬁllment of the Requirements for the Degree of

Doctor of Philosophy

Advisor: Dr. Daniel G. Saab

Department of Electrical Engineering and Computer Science

CASE WESTERN RESERVE UNIVERSITY

January 2007 CASE WESTERN RESERVE UNIVERSITY

SCHOOL OF GRADUATE STUDIES

We hereby approve the dissertation of

______

candidate for the Ph.D. degree *.

(signed)______(chair of the committee)

______

(date) ______

*We also certify that written approval has been obtained for any proprietary material contained therein. To

My Parents Table of Contents

1 INTRODUCTION 1

2 BACKGROUND 6 2.1 Basic Concepts ...... 6 2.2 Graphs ...... 8 2.3 Software Program Slicing ...... 13 2.4 Hardware Program Slicing ...... 16

3 RTL SLICER 20 3.1 Static/Conditioned RTL slicer ...... 20 3.2 VRM ...... 21 3.3 Static/Conditioned VRM Slicer ...... 23 3.4 RTL slicer example ...... 25 3.5 HDL Slicing vs. Cone of Inﬂuence Reduction ...... 27

4 FORMAL VERIFICATION METHODS 35 4.1 Temporal Logic ...... 38 4.2 Bounded Model Checking ...... 40

5 ATPG-Based BMC Formal 44

6 EXPERIMENT 48 6.1 USB2.0 IP Core ...... 48 6.2 Experiment Results ...... 49

7 CONCLUSIONS 59

List of Tables

1 Node statements of the VRM ...... 29 2 VRM for example Verilog code...... 30 3 USB2.0 IP core property descriptions...... 53 4 Slice size for each USB2.0 IP core property...... 54 5 CPU time(second) of SMV...... 55 6 Memory usage(MB) of SMV...... 56 7 CPU time(second) of Formal...... 57 8 Memory usage(MB) of Formal...... 58

iv List of Figures

1 Overview ...... 5 2 A example for program slicing – Original Program ...... 9 3 The static slice with respect to the slicing criterion < S11, z > 10 4 The static slice with respect to the slicing criterion < S10, y > 10 5 Control Flow Graph ...... 11 6 Program Dependenc Graph ...... 12 7 The conditioned slice w.r.t. the slicing criterion < (x < 0) , S10, y > ...... 16 8 RTL slicer Framework ...... 21 9 Algorithm: Static/Conditioned VRM Slicer ...... 31 10 A hierarchical Verilog design...... 32 11 Static slice ...... 33 12 Conditioned slice ...... 34 13 Framework of ATPG-based BMC...... 46 14 Justiﬁcation on k time frames...... 47 15 USB2.0 functional blocks...... 49 16 Building blocks of IP core for SIE...... 49

v ACKNOWLEDGMENTS

First of all, I would like to acknowledge my adviser Dr. Daniel G.

Saab who always guides and encourages me through my entire Ph.D. research. Special thanks are given to his instructions, experiences and knowledge to help me overcome all the diﬃculties and challenges I have met in the past three and half years.

I want to express deep gratitude to Dr. Christos A.

Papachristou, Dr. Massood Tabib-Azar, and Dr. Swarup Bhunia, for serving on my dissertation committee and their valuable comments and suggestions to my research.

I also want to thank my friends in the department, Qiang Qiang,

Siva, Chia-Lun Chang, Chih-Hsueh Chang, Noppasit and

Wen-Teng Chang, for their help and friendship.

Finally, to my family in Taiwan. Thanks to all their support and encouragement in these years, I really appreciated.

vi Hardware Description Language Program Slicing and way to Reduce Bounded Model Checking Search Overhead

Abstract

by Jen-Chieh Ou

Modern complex digital systems are described in Hardware

Description Language (HDL). The increase in design complexity is causing veriﬁcation tools to require large amount of resources. In this research, we present a program slicing technique to extract statements from an RTL design that directly or indirectly contribute to a formal veriﬁcation rule.

The extracted statements constitute a less complex design that reduces the resource needed by verification tools without compromising the quality of the result. Both static and conditioned Verilog slicer is implemented in a computer program that is used as a pre-processor to SAT-based bounded model checker SMV and ATPG-based bounded model checker Formal. We show experimentally that the resources of the formal verification tool in terms of both CPU and memory are reduced significantly when verifying the USB2.0 IP core. The proposed slicer is the first hardware slicing technique that handles inter-module signal dependency in a hierarchical

Verilog design environment.

vii 1 INTRODUCTION 1

1 INTRODUCTION

As the transistor count exceeds one hundred million per die in modern semiconductor devices, it allows circuit designers to add more functionality onto a single chip. The increasing circuit complexity poses a challenge to

Computer-Aid Design (CAD) tools. These CAD tools are used at every step in the design cycle. A typical design cycle for a digital system starts with a speciﬁcation that deﬁnes a desired function. Typically a design is described in a Hardware Description Language such as VHDL or Verilog.

Simulation and verification tools are used to ensure correctness of the design by verifying that the implementation is consistent with the specification. After the behavioral hardware description is verified, another gate-level verification is performed. The process of behavioral verification and the gate-level verification is repeated until the design is verified. The

ﬁnal step is the technology mapping place and route to produce a layout.

In the design process, veriﬁcation is a crucial step. It requires large amount resource that is proportional to the size of the search space that is related to the HDL description. In current design, it is estimated that over

60% [48] of design effort is consumed by verification tools and it is expected to increase. This complexity is due to the trend in System on a Chip (SoC) and high-level design process which relying on the use of complex blocks with well defined functionally and interfaces and on integrating those blocks 1 INTRODUCTION 2 to produce a system. This is highlighted in the International Technology

Road-map for Semiconductors (ITRS) documents which points to the fact that verification has become the dominant cost in the design process, and that verification engineers outnumber design engineers up to three to one on complex designs. It points out that design conception and implementation are becoming mere preludes to the main activity of verification. Simulation of the design using validation tests is the main technique used in industry to verify large designs. However, as designs become larger, the percentage of the simulated possible behavior becomes smaller and the confidence in the design obtained by simulation diminishes. There is a growing interest in complementing simulation based verification with formal methods.

Unlike simulation, formal methods use mathematical reasoning to search the entire design space in order to verify design correctness.

However, the design space is too large to be searched exhaustively in large designs. For this reason, the existing formal methods are only applicable to small portions of a design.

In this research, we present a program slicing technique to extract statements from an RTL design that directly or indirectly contribute to a formal veriﬁcation rule. The extracted statements constitute a small design that formal methods can be applied with reasonable CPU time and memory requirement. We implemented this technique in a computer program and 1 INTRODUCTION 3 compared its impact on a SAT-based bounded model checker SMV and on an

ATPG-based bounded model checker Formal. Figure 1 shows how program slicing is integrated with a formal verification tool. In this approach, a set of Slice Target Variable (STV) and the Condition (Con) is generated based on the circuit property that needs to be verified. RTL program slicer reads the STV, Con and the Verilog description to compute a design slice that is behaviorally equivalent to the original design with respect to the property under verification. The slice that is smaller than the original design in terms of size and complexity is read by the verification tools, which verifies the validity of the property. We show experimentally that the resources of the formal verification tool in terms of both CPU and memory are reduced.

In addition, the technique made it possible to verify properties that the verification tools could not verify. This verification does not compromise the quality of the result. The proposed slicer is the first hardware slicing technique that handles inter-module signal dependency in a hierarchical

Verilog design environment.

The principle contribution of this work is:

1. This is the ﬁrst fully automated conditioned HDL slicer.

2. The ﬁrst slicer that handles the inter-module signal dependency in a

hierarchical Verilog design.

3. Users do not need to specify the slicing variables location like the 1 INTRODUCTION 4

conventional method. This allows designers with little knowledge of

the Verilog code to generate meaningful slices.

The rest of this thesis is organized as follows: Chapter 2 presents the basic concept and definition that used in our method. In this chapter, the program slicing concepts are defined in Chapter 2.1. The variant graphs that used by different program slicing methods are described in Chapter

2.2. The previous works on program slicing for software and hardware are reviewed in Chapter 2.3 and Chapter 2.4 respectively. In Chapter 3, we introduce a RTL program slicer and provide an example to show the static and conditioned slice of a hierarchical Verilog design obtained by our slicer.

Chapter 4 gives a background of formal veriﬁcation methods. Chapter 5, we formulates ATPG-based BMC and describes ATPG heuristic. Chapter 6 shows its impact of our method by verifying USB2.0 IP Core properties.

Chapter 7 concludes. 1 INTRODUCTION 5

Property

Condition(Con) Slice Target Variable(STV)

Sliced Witness RTL Verilog Verification or Verilog Design Program Design Tool Valid Slicer

Figure 1: Overview 2 BACKGROUND 6

2 BACKGROUND

2.1 Basic Concepts

The following deﬁnitions are derived from earlier work in [55].

Deﬁnition 1: A digraph Gi is a set of nodes N and a set of edges E where E N N. For an edge (u, v) E, u is the direct predecessor of v ⊆ × ∈ and v is the direct successor of u.

Deﬁnition 2: Given a node n N, PRED(n) and SUCC(n) are the ∈ set of direct predecessors and direct successors of a node n, respectively.

Definition 3: Given a node n N, the definition set DEF(n) is the ∈ set of variables those are defined at n. The reference set REF(n) is the set of variables that are referred at n.

Deﬁnition 4: A static slice S of a program P is constructed with respect to a slicing criterion < i,V > where V is a set of variables and i is a point in the program P. S is a subprogram of P consists of the statements that might aﬀect the values of V at point i.

Deﬁnition 5: A conditioned slice CS of a program P is constructed with respect to a slicing criterion < Con, i,V > where Con is the condition,

V is a set of variables and i is a point in the program P. CS is a subprogram of P consists of the statements which might aﬀect the values of

V at point i when the condition Con holds true. 2 BACKGROUND 7

Deﬁnition 6: The set of variables immediately relevant to a slicing

C criterion C, denoted by R0 (n) , is deﬁned as

RC (n) = v V n = i 0 { ∈ | } U(n) D(n) RC (SUCC(n)) = ∪{ | ∩ 0 6 ∅} RC (SUCC(n)) D(n) . ∪{ 0 − } C Deﬁnition 7: The set of statements included in the slice by R0 (n),

C denoted by S0 , is deﬁned as

SC = n N c D(n) RC (SUCC(n)) = . In which, N C is the set 0 { ∈ G| ∩ 0 6 ∅} G C of nodes of graph Gi of the program. The set S0 does not include the control ﬂow such as branch statements which allow execution of the

C C statements in S0 . Therefore for each statement of S0 , a control statements set is introduced.

Deﬁnition 8: Let C = < i, V > be a slicing criterion. The set of

C conditional statements which control the execution of the statements in S0 ,

C denoted B0 , is deﬁned as:

0 0 B = b NG INF L(b) S = C { ∈ | ∩ C 6 ∅} In which, INFL(b) is the set of statements conditioned by b. The program slice generated by the following recursive processes will include all statements and control predicates that have direct or indirect relevance with variables in V.

(1)Ri+1(n) = R1 (n) R0 (n) C C ∪ 2 BACKGROUND 8

i+1 i+1 (2)B = b NG INF L(b) S = C { ∈ | ∩ C 6 ∅} i+1 i+1 i (3)S = n NG D(n) R (SUCC(n)) = B C { ∈ | ∩ C 6 ∅} ∪ C i+1 i The terminal condition for this recursive process is: SC = SC . The

i SC is the slice of program based on slice criterion C.

A program slice with respect to a slicing criterion < i,V > consists of all statements in the program that potentially aﬀect the value of variable

V at program location p. For example, Figure 2 is the original program. In which, variable y and z were written in diﬀerent values that was depend on the value of variable x. Figure 3 is the program slice with respect to slicing criterion < S11,z >. This slice includes all statements in the original program that may aﬀect the value of variable z at statement S11. Figure 4 is the program slice with respect to slicing criterion < S10,y >

2.2 Graphs

Before introducing the variant of program slicing method, we give the deﬁnitions and examples for the some graphs that will be used in the following part.

1. CFG(Control Flow Graph): A control ﬂow graph is a representation

of a program that each node is associated with a statement in the

program and contains information about data and control ﬂow in a

program. The vertices in the CFG represent statements in the 2 BACKGROUND 9

begin S1: read(x); S2: if x < 0 then S3: y := f1(x); S4: z := g1(x); else S5: if (x=0) then S6: y := f2(x); S7: z := g2(x); else S8: y := f3(x); S9: z := g3(x); end if end if S10: write(y); S11: write(z); end Figure 2: A example for program slicing – Original Program

program while the edges represent the control ﬂow in the program.

Figure 5 gives an example for CFG that present the program in

Figure 2.

2. PDG(Program Dependence Graph): The program dependence graph

is a directed graph that contains information about data and control

dependence in a program. The vertices of PDG represent the

assignment statements and control predicates and the edges represent

the data and control dependences between vertices. There is a

distinguished vertex called the entry vertex in every PDG that is the 2 BACKGROUND 10

begin S1: read(x); S2: if x < 0 then S4: z := g1(x); else S5: if (x=0) then S7: z := g2(x); else S9: z := g3(x); end if end if S11: write(z); end

Figure 3: The static slice with respect to the slicing criterion < S11, z >

begin S1: read(x); S2: if x < 0 then S3: y := f1(x); else S5: if (x=0) then S6: y := f2(x); else S8: y := f3(x); end if end if S10: write(y); end

Figure 4: The static slice with respect to the slicing criterion < S10, y > 2 BACKGROUND 11

read(x)

if x < 0

true false

y = f1(x) if(x=0) true false

z = g1(x) y = f2(x) y = f3(x)

z = f2(x) z = f3(x)

write(y)

write(z)

Figure 5: Control Flow Graph

condition for execution of the program. Figure 6 gives an example for

PDG representation that used in Horwitz, Reps and Binkley [50]. The

program sums the integers from 1 to 10 and save the result in the 2 BACKGROUND 12

variable sum.

Main() { control dependence SUM = 0; loop−independent flow dependence i = 1; while(i < 11) loop−carried flow dependence { SUM = SUM + 1; i = i + 1; ENTRY } true print(SUM); true true true true print(i) }

SUM = 0 i = 1 while(i<11) print(i) print(SUM)

true true

SUM = SUM + 1 i = i + 1

Figure 6: Program Dependenc Graph

3. SDG(System Dependence Graph): The system dependence graph is

an extension of the PDG introduced by Horwitz, Reps and Binkley

[50] for the dependence graphs that represents multi-procedure

programs. The SDG consists of a single main procedure and a

collection of auxiliary procedures. Each procedure was represented by

the procedure dependence graphs which is similar with program

dependence graph except that they include vertices and edges 2 BACKGROUND 13

representing call statements, parameter passing, and transitive ﬂow

dependences due to calls. The interprocedural control dependence

edges and ﬂow dependence edges were used to connect all procedure

dependence graphs.

2.3 Software Program Slicing

The program slicing was mainly implemented by the following two methods. The first is by computing consecutive sets of relevant variables for each node in control-flow graph(CFG) which was introduced by Weiser [55] and there are many research have been presented for program slicing based on his definition trying to reduce the slice size further

[50, 38, 40, 9, 8, 11, 12, 14, 32].

The other method is based on the program dependence graph(PDG)

[36, 19]. Ottenstein and Ottenstein [43] proposed the use the PDG to implement the program slice. The PDG provides explicit data and control dependences for the program that makes the problem of slicing the program can be reduced to a vertex reachability problem in its PDG. Because the

PDG only describes the dependencies within a single procedural, this method can t be used to slicing the program with multiple procedurals.

Horwitz, Reps and Binkley [50] proposed the system dependence graph(SDG) that includes the interprocedural dependencies and a slicing algorithm based on SDG that could produce the closure program slices 2 BACKGROUND 14 from the original multiple-procedural program. Binkley proposed a slicing method improved from Horwitz, Reps and Binkley s that could produce executable interprocedural program slices in 1993 [12]. Binkley also proposed an interprocedural slicing algorithm which parameterized by a set of aliasing patterns for each procedure. Flow dependence edges are created on different levels to separately represent different possible flow dependencies for different aliasing patterns. By this method, slices can be produced by traversing the flow dependencies edges in the SDG.

There are variant of program slicing, the original slicing method introduced by Weiser is a static executable slice from a sequential program.

An executable slice with respect to the slicing criterion < p,v > is a syntactic subprogram of the original program that computes the same sequence of value for v at location p. A closure slice, on the other hand, is not a syntactic subprogram. It just includes all statements of the original program that might aﬀect the value v at location p.

A static slice includes all the statements that may aﬀect the value of v at point p for all input values. This kind of slicing gives us a general view for the portion of the original program related to the slicing criterion

< p,v >. However, for some applications, like program debugging, we will focus on speciﬁc computation with a set of input values. A static slice may contain the statements that were useless for this computation. 2 BACKGROUND 15

Korel and Laski [38, 37] ﬁrst proposed the ideas for dynamic slicing.

A dynamic slice contains the statements of the original program that did affect the value of a variable at a program location in a particular execution. Because the dynamic slicing was produced for a particular execution, it may significant reduce the slice size as compare to the static one. They obtain the dynamic slice by using data-flow equations and the trajectory which is a record of execution history of the program.

Conditioned slice is a theoretical bridge between static and dynamic slicing introduced by Canfora, Cimitile and Lucia [21, 23]. A conditioned slice of program P respect to the slicing criterion < Con,i,V > is a set of statements and predicates of P that might aﬀect the values in V at program position i when the condition Con holds true. The conditioned slicing has been shown to produce smaller and more meaningful slice than static slicing. Figure 7 is the conditioned program slice of the program in Figure 2 with respect to the slicing criterion < (x < 0) , S10, y >. Compare to the static slicing result in Figure 4, statement S5, S6 and S8 were eliminated for conditioned slice because these statements will never be executed when x < 0.

The conditioned slicing technique has been applied to program reuse

[23], re-engineering [22] and comprehension [6]. Danicic, Fox and Harman

[46] implemented a fully automated conditioned program slicing system: 2 BACKGROUND 16

begin S1: read(x); S2: if x < 0 then S3: y := f1(x); end if S10: write(y); end

Figure 7: The conditioned slice w.r.t. the slicing criterion < (x < 0) , S10, y >

ConSIT. It used symbolic execution, traditional static slicing and the

Isabelle theorem prover to implement conditioned slicing. The ConSIT only support a subset of C program.

2.4 Hardware Program Slicing

As mention above, program slicing tools and techniques have been developed for sequential programs. Those slicing tools and techniques could not applied directly to Hardware Description Languages(HDL) such as

Verilog or VHDL for many reasons. For example, contrary to sequential programs, HDL is a non-halting reactive system consisting of a set of concurrent processes. In a non-halting reactive system, a process is always active and during execution may wait for events on one or more signals, which are triggered in other concurrently executing processes. On the other hand, in sequential programs function are called explicitly when the 2 BACKGROUND 17 program controls reaches a procedure call. For these reasons, research to extend sequential program slicing technique to HDL design is being investigated. Iwaihara et al [42] was ﬁrst to proposed an HDL program slicing technique to analyze a VHDL design. He described a variety of applications that can be made more eﬃcient as a result of program slicing.

He did not implement his method and for this reason he did not oﬀer any experiments that support his claim.

To improve the eﬃciency of formal veriﬁcation process, Clarke [15] proposed a VHDL slicing method. In [15], a VHDL design is transformed into a sequential program constructs and a sequential program slicing tool is applied on the transformed VHDL code. In this technique, the user is required to specify statements and signals location in the slicing criterion.

This requires familiar knowledge of the source code that may make the use of this technique diﬃcult. In addition, this technique does closure slicing, with only partial support for executable slicing. In this technique, the slice needs to be transformed into executable Verilog code before it can be used by CAD tools.

The notion of chaining slice was introduced in [51] to extract circuit from Verilog. The chaining slice chains the signal value changes between two set of signals and find a set processes that affect the target variable. To extract the slice, they apply Weiser’s algorithm on each process. Instead of 2 BACKGROUND 18 asking the user to provide signal location like the Weiser’s slicing method, they obtain this information automatically. This idea is applicable to vendor-provided Intellectual Properties(IP) where the knowledge about the internal HDL design structure is limited. This method requires that variables define/use in the function or task to be declared as input or output and that the design consists of a single module.

Vedula, Abraham and Bhadra [53] ﬁrst attempt to use program slicing techniques for generating manufacturing tests. In which, a theoretical basis was proposed for using program slicing on HDL to obtain an ATPG view of a Module Under Test(MUT) in a synthesizable form by the notion of constraint slice that is the abstraction of surrounding designs relevant to the MUT. Because the surrounding designs relevant to the MUT may be too big to handle on large designs with multiple-levels of hierarchy, they also provided a solution to perform slicing hierarchically. These hierarchical slices are composed to obtain the complete constraint slice.

For Bounded Model Checking(BMC), it has been shown that

ATPG-based BMC perform better than SAT-based BMC. However,

ATPG-based BMC techniques require an eﬀective methodology to deal with the large size designs. Vedula, Townsend and Abraham [54] proposed a method that is similar with methodology in [53] to employ the program slicing techniques to derives the interface process of a Module Under 2 BACKGROUND 19

Veriﬁcation(MUV). The size of the interface process of a MUV was much smaller than the original design so that we can use an ATPG-based bounded property checking approach to verify the MUV with it and increase the eﬃciency of formal property checking. However, in [53, 54], they only performed structural slicing and did not provide implementation detail in these works. 3 RTL SLICER 20

3 RTL SLICER

3.1 Static/Conditioned RTL slicer

In this chapter, we introduce an efficient Verilog slicing method which generates both executable static and conditioned slice. This is the first fully automatic HDL slicing technique that generates the conditioned slice and handles inter-module signal dependency in both flat and hierarchically described Verilog design. Unlike conventional slicing, the user does not need to specify the location of the STV variables. This ability allows designers with little knowledge of the Verilog code to be able to generate very meaningful slices. This method is based on constructing a graphic model to present the Verilog design and an efficient traversal that extract relevant slices.

Figure 8 shows the framework of our RTL static/conditioned program slicer. In this framework, we use the Verilog RTL Model

(VRM) [47] to compute a VRM model for a Verilog design. Based on the

STV and the condition Con(only applied when computing the conditioned slice), the slicer generates appropriate slices in VRM. Finally, the transformer converts the sliced VRM into a syntactic Verilog program. The resulting Verilog program is used by the CAD tool to analyze the design. 3 RTL SLICER 21

RTL Static / Conditioned Verilog Program Slicer VRM tool Design Static / VRM Conditioned VRM Transformer Slicer Sliced STV VRM

Condition(Con)

Sliced Verilog Design

Figure 8: RTL slicer Framework

3.2 VRM The VRM is based on the ICARUS Verilog system [57]. To generate the

VRM model, the tool extracts the internal data during source compiling and generates three graphs. Those are the Circuit Graph(CKT), the

Control Flow Graph(CFG) and the Data Flow Graph(DFG). The CKT composed of a set of k-nodes, each node is a variable, a record containing a link to a process or a function in the CFG and list of events. The CFG is digraph Gi consisting of a set of c-nodes N and a set of edges E. Each 3 RTL SLICER 22 c-node N corresponds to a statement in the Verilog program and a ∈ pointer to a DFG. An edge e E between nodes u and v represents the ∈ control ﬂow dependency between two statements in the Verilog code. The

DFG consists of a set of d-nodes representing how the statement executes.

The deﬁnition of VRM nodes are listed in Table 1.

Table 2 is the VRM for the design in Figure 10. The ﬁrst column in the table 2 shows the CKT, the second column shows the CFG and the third column shows the DFG. Each line in the CKT, CFG and DFG corresponding to a k-node, c-node and d-node respectively. The k-node represents the primary input/output, variable, process and the event that trigger the process of the Verilog program. For example, k-node P-22 represents process top.u1.always.0 that is triggered by the event E-26 and { } its control ﬂow was described by CFG-0. Each c-node represents a statement in the Verilog program. Each c-nodes contains one entry edge and one or more exit edges. ST ART and END edges indicate the entry point to this process and the place where the process waits for a triggering event, respectively. For example, AB-0-0 represents the assignment statement c=a & b in module u1 and the process which this statement { } belongs is P-22 in the CKT graph. Label ST ART is entry edge to node

AB-0-0 and label AB-0-1 is an exit edge to c-node AB-0-1. The data ﬂow information for statement c=a & b is stored in DFG-0. The d-done { } 3 RTL SLICER 23

VI-0-0 and VI-0-1 are operands while BAN-0-2 and VO-0-3 are operations performed in this statement. Operands are stored in corresponding k-nodes in the CKT graph.

3.3 Static/Conditioned VRM Slicer Deﬁnition 9: Given a node n N, the control block set CB(n) is the set of ∈ statements which may regulated the execution by a control predict n.

Deﬁnition 10: Given a node n N, the branch block set BB(n) is a ∈ subset of CB(n) is the set of statements which will regulated the execution by a control predict n base on the control value.

Deﬁnition 11: The control predict set CPS(G) and the assignment set ASS(G) are the set of nodes in graph G which represent a control predict statement and an assignment statement, respectively.

There are two sections in our slicing algorithm. The ﬁrst is conditioned section and the other is slicing section. The conditioned section computes the conditioned program from the original program based on the condition. This part was executed only for conditioned slicing. The slicing section performs the static program slicing. In fact, the conditioned program slice can be obtained by performing static program slicing on the conditioned program instead of the original program.

To obtain the conditioned program, we need to exclude the statements from the original design that cannot get executed under the 3 RTL SLICER 24 condition. We assign the initial values to a set of variables based on the condition and then compute the control value of each control predict statement in the design. If the control value can be deﬁned for the control predict statement m, we will mark all the statements in the control block

CB(m) except statements also in the branch block BB(m). The marked statement will not be considered for the following process and therefore will not be included in the slice.

A Verilog program is a non-halting reactive system composed of a set of concurrent processes and the STV may be deﬁned in more then one process. For this reason, we need to compute the initial slicing location for a given STV when performing the program slicing. This is computed by adding every DFG n to the Start-Point queue(SPqueue) if the DEF (n) containing any STV. The slicing starts by operating on the ﬁrst elements p

SPqueue. At this point, p corresponding c-node (Cn) is included in the ∈ slice. The inclusion is performed in function P ick() and variables in the

REF (p) are added to the STV. This is achieved by pushing REF (p) into another queue, STV-queue(STqueue). Every node pushed on STqueue or

SPqueue is marked to ensure that it will be processed once. To compute the VRM slice we need to include in the slice all statements that may aﬀect

Cn. To include these statements, we perform a backward CFG traversal starting from Cn. In this traversal, no computation is performed when 3 RTL SLICER 25 nodes corresponding to assignment statements are encountered and the traversal is continued. On the other hand, when a control predicate node R is encountered that node is added to the slice if Cn is in the control block set(CB(R)). The traversal terminates when ST ART is reached or a node which is already selected to be in the slice is encountered. At this point, another start-point from the SPqueue initiates a new backward CFG traversal. The process is repeated until the SPqueue is empty. This process is repeated once for each STV in the STqueue. The slicing algorithm terminates when both SPqueue and STqueue are empty. This is shown in

Figure 9.

After the slice is formed, a conversion step is performed in the

Transformer block shown in Figure 8. The Transformer traverses the CFG and converts the sliced VRM into a syntactic Verilog program that can be read by CAD tools. Each c-nodes in the CFG corresponds to a Verilog statement. This makes the conversion of the sliced VRM possible with one

CFG transversal.

3.4 RTL slicer example

Figure 10 shows a simple hierarchical Verilog design consisting of three modules. The top module includes two submodules u1 and u2. In this design, we are interested in a program slice that aﬀect the behavior of variable ’target’ which consists of a subset of statements from the original 3 RTL SLICER 26

Verilog that may aﬀect directly or indirectly the behavior of register

’target’.

The introduced RTL slicer takes the Verilog design as input and produces both static and conditioned slice based on the interested variables and conditions. The static slice for register ’target’ is shown in Figure 11.

Note that statements that does not aﬀect register ’target’ are not included in the slice resulting in a smaller design. Figure 12 shows the conditioned slice for register ’target’ with condition c1 valid1 && valid2 is true. { } Compare to the static slice in Figure 11, statements that do not been executed while c1 holds true are not included in the conditioned slice and therefore produces a smaller design than the static slice. For example, module u2 does aﬀect the value of register 0target0 in this design and to be included in the static slice. However, it will not been executed when the condition c1 holds ture and for this reason module u2 does not included in the conditioned slice.

The behavior of variable 0target0 in the sliced program is equivalent to the behavior of variable 0target0 in the original program. Thus, when a

CAD application needs to analyze values stored in variable ’target’ could use the smaller and less complex sliced program rather than the original more complex code to reduce needed resources. 3 RTL SLICER 27

3.5 HDL Slicing vs. Cone of Inﬂuence Reduction

The Cone of Inﬂuence (COI) [2] reduction is a is a fundamental abstraction technique for reducing the size of models used by existing model checkers

[56]. The idea of COI is to construct a dependence graph of the state variables on the gate-level netlist and traverse it starting from the variables in the specification. The dependence graph is usually represented as a vector of transition functions generated from a symbolic encoding of a system such as BDDs. The set of state variables reached during this traversal forms the COI of the variables in the specification. The problem is, in complex IC designs, the generation of the state transition form from a hardware description language can itself be a critical challenge. HDL slicing is a source code level abstraction technique that can built a dependence graph directly on the HDL source code and traverse it starting from slicing target variables to find out the related parts of the design. By this method, we can reduce the overhead resulting from the generation of state transition form.

Although HDL slicing and COI technique build their dependence graph on diﬀerent level of the design, they both construct their dependence graph on the same design. Therefore, the HDL slicing (static) and COI reductions are semantically the same. The performance gains from the static slicing technique are due to the ease of model generation, not from 3 RTL SLICER 28 the model veriﬁcation.

In contrast, conditioned slicing produces a semantically different design from static slicing and COI reductions. The conditioned slicing technique removes parts of the design that was being included in the static slice but will not affect slicing target variables under the given condition from initial states. The conditioned slice is a new design to the original program, but retains the behavior with respect to the condition and interest variables. Therefore, the performance gains from the conditioned slicing are due to both the ease of model generation and the reduction in the complexity of model verification. An extra advantage for the HDL slicing technique is that the synthesis tool would need to generate the gate level netlist only for the relevant sliced design and not for the whole design. 3 RTL SLICER 29

Table 1: Node statements of the VRM

CKT (K-node) DFG (D-node) PI – primary input CI – input from constant PO – primary output VI – input from variable PIO – primary inout MI – input from memory IIO – internal inout FI – input from function WIRE – wire VO – output to variable WOR – wor SO – output to variable bit selection WAND – wand MO – output to memory VR – register variable for process CC – concatenation VM – memory variable for process SL – selection of bits P – process SLB – selection of bit VF – function input TN – ternary operation F – function output UPS – Unary Operation positive RAM – memory read-out UNG – Unary Operation negative BI0 – buﬁf0 (tri-state bit device) ULN – Unary Operation logical negation BI1 – buﬁf1 (tri-state bit device) UNT – Unary Operation bit-wise negation NEX – nexus for individual bit UAN – Unary Operation reduction AND with wire-type signal UNA – Unary Operation reduction NAND NEXL – nexus for individual bit UXR – Unary Operation reduction XOR with wor/wand-type signal UNX – Unary Operation reduction XNOR E – event UOR – Unary Operation reduction OR CFG (C-node) UNR – Unary Operation reduction NOR AB – blocking assignment BAD – Binary Operation arithmetic add AN – non-blocking assignment BSB – Binary Operation arithmetic subtract IF – if BML – Binary Operation arithmetic multiply CS – case BDV – Binary Operation arithmetic divide CX – casex BMD – Binary Operation arithmetic modulus CZ – casez BLS – left shift TM – terminal of branches BRS – Binary Operation right shift of IF, CS, CX, CZ BLT – Binary Operation less then BLE – Binary Operation less or equal BGT – Binary Operation greater then BGE – Binary Operation greater or equal BEQ – Binary Operation logical equality BIE – Binary Operation logical inequality BCE – Binary Operation case equality BCEX – Binary Operation casex equality BCEZ – Binary Operation casez equality BCI – Binary Operation case inequality BAN – Binary Operation bit-wise AND BOR – Binary Operation bit-wise OR BXR – Binary Operation bit-wise XOR BNX – Binary Operation bit-wise XNOR BLA – logical AND BLR – logical OR CBI – case branch index for statements case, casex, casez 3 RTL SLICER 30

Table 2: VRM for example Verilog code.

CKT CFG DFG

#CKT; #CFG-0 @ P-22; #DFG-0 @ AB-0-0; PI-0(1, top.clk); AB-0-0(DFG-0) = START : AB-0-1; VI-0-0(WIRE-10, 1, 0); PI-1(1, top.p); AB-0-1(DFG-1) = AB-0-0 : END; VI-0-1(WIRE-11, 1, 0); PI-2(1, top.q); BAN-0-2(1) = VI-0-0, VI-0-1; PI-3(1, top.r); #CFG-1 @ P-23; VO-0-3(VR-18, 1, 0, 0) = BAN-0-2; PI-4(1, top.s); AB-1-0(DFG-2) = START : AB-1-1; PI-5(1, top.valid1); AB-1-1(DFG-3) = AB-1-0 : END; #DFG-1 @ AB-0-1; PI-6(1, top.valid2); VI-1-0(WIRE-10, 1, 0); PO-7(1, top.out) = VR-16; #CFG-2 @ P-24; VI-1-1(WIRE-11, 1, 0); WIRE-8(1, top.u1o) = VR-18; IF-2-0(DFG-4) = START : AB-2-1, AB-2-2, TM-2-3; BOR-1-2(1) = VI-1-0, VI-1-1; WIRE-9(1, top.u2o) = VR-20; AB-2-1(DFG-5) = IF-2-0 : TM-2-3; VO-1-3(VR-19, 1, 0, 0) = BOR-1-2; WIRE-10(1, top.u1.a) = PI-2; AB-2-2(DFG-6) = IF-2-0 : TM-2-3; WIRE-11(1, top.u1.b) = PI-1; TM-2-3 = AB-2-1, AB-2-2, IF-2-0 : END; #DFG-2 @ AB-1-0; WIRE-12(1, top.u1.clk) = PI-0; VI-2-0(WIRE-14, 1, 0); WIRE-13(1, top.u2.clk) = PI-0; #CFG-3 @ P-25; VI-2-1(WIRE-15, 1, 0); WIRE-14(1, top.u2.l) = VR-18; IF-3-0(DFG-7) = START : AB-3-1, IF-3-2, TM-3-6; BXR-2-2(1) = VI-2-0, VI-2-1; WIRE-15(1, top.u2.m) = PI-3; AB-3-1(DFG-8) = IF-3-0 : TM-3-6; VO-2-3(VR-20, 1, 0, 0) = BXR-2-2; VR-16(1, top.out) = P-24; IF-3-2(DFG-9) = IF-3-0 : AB-3-3, AB-3-4, TM-3-5; VR-17(1, top.target) = P-25; AB-3-3(DFG-10) = IF-3-2 : TM-3-5; #DFG-3 @ AB-1-1; VR-18(1, top.u1.c) = P-22; AB-3-4(DFG-11) = IF-3-2 : TM-3-5; VI-3-0(WIRE-14, 1, 0); VR-19(1, top.u1.t) = P-22; TM-3-5 = AB-3-3, AB-3-4, IF-3-2 : TM-3-6; VI-3-1(WIRE-15, 1, 0); VR-20(1, top.u2.n) = P-23; TM-3-6 = AB-3-1, TM-3-5, IF-3-0 : END; BAN-3-2(1) = VI-3-0, VI-3-1; VR-21(1, top.u2.w) = P-23; VO-3-3(VR-21, 1, 0, 0) = BAN-3-2; P-22(CFG-0, top.u1.always.0) = E-26; P-23(CFG-1, top.u2.always.1) = E-26; #DFG-4 @ IF-2-0; P-24(CFG-2, top.always.2) = E-26; VI-4-0(PI-5, 1, 0); P-25(CFG-3, top.always.3) = E-26; VI-4-1(PI-6, 1, 0); E-26(pos, top.u1.s1) = PI-0[0]; BLR-4-2(1) = VI-4-0, VI-4-1;

#DFG-5 @ AB-2-1; VI-5-0(WIRE-9, 1, 0); VO-5-1(VR-16, 1, 0, 0) = VI-5-0;

#DFG-6 @ AB-2-2; CI-6-0(0); VO-6-1(VR-16, 1, 0, 0) = CI-6-0;

#DFG-7 @ IF-3-0; VI-7-0(PI-5, 1, 0); VI-7-1(PI-6, 1, 0); BLA-7-2(1) = VI-7-0, VI-7-1;

#DFG-8 @ AB-3-1; VI-8-0(PI-4, 1, 0); VI-8-1(WIRE-8, 1, 0); BXR-8-2(1) = VI-8-0, VI-8-1; VO-8-3(VR-17, 1, 0, 0) = BXR-8-2;

#DFG-9 @ IF-3-2; VI-9-0(PI-4, 1, 0);

#DFG-10 @ AB-3-3; VI-10-0(WIRE-9, 1, 0); VO-10-1(VR-17, 1, 0, 0) = VI-10-0;

#DFG-11 @ AB-3-4; VI-11-0(WIRE-8, 1, 0); VO-11-1(VR-17, 1, 0, 0) = VI-11-0; 3 RTL SLICER 31

Algorithm: Static/Conditioned VRM Slicer Input: VRM, STV(v) and the Condition(Con) Output: Sliced VRM w.r.t v and C Assign initial values to variables based on Con; for each m CPS(VRM) do Compute∈ the control{value cv of m; if (cv can not be defined) then continue; else for each z CB(m) do if (z not∈ included in BB(m)) then mark z for SPqueue;

Push(STqueue)} = v; while (STqueue = )do xv = Pop(STqueue);6 ∅ { for each DFG n VRM do if ((xv DEF(n)∈ and (n not marked for SPqueue)) then Push(SPqueue)∈ = n; while (SPqueue = ) do p = Pop(SPqueue);6 ∅ { Cn = corresponding c-node for p; Pick(Cn); for each w REF(p) do ∈ if (w not marked for STqueue) then Push(STqueue) = w; pCn = PRED(Cn); while ((pCn = BEGIN node) or (pCn not picked)) do if (pCn 6 ASS(VRM)) then { pCn =∈PRED(pCn) ; elseif ((pCn CPS(VRM)) and (Cn CB(pCn))) then Pick(pCn);∈ ∈ { for each q REF(pCn) do if (q not∈ marked for STqueue) then Push(STqueue) = q; pCn = PRED(pCn) ; } } } } Figure 9: Algorithm: Static/Conditioned VRM Slicer 3 RTL SLICER 32 module top(clk, q, p, r, s, valid1, valid2, out); input clk, q, p, r, s, valid1, valid2; output out; reg out, target; wire u1o, u2o; u1 u1(.clk(clk), .a(q), .b(p), .c(u1o)); u2 u2(.clk(clk), .l(u1o), .m(r), .n(u2o)); always@(posedge clk) begin if(valid1 || valid2 ) out = u2o; else out = 1’d0; end always@(posedge clk) begin if( valid1 && valid2) target = s ^ u1o; else if(s) target = u2o; else target = u1o; end endmodule module u1(clk, a, b, c); input clk, a, b; output c; reg c, t; always@(posedge clk) begin c = a & b; t = a | b; end endmodule module u2(clk, l, m, n); input clk, l, m; output n; reg n, w; always@(posedge clk) begin n = l ^ m; w = l & m; end endmodule Figure 10: A hierarchical Verilog design. 3 RTL SLICER 33

module top(clk, q, p, r, s, valid1, valid2, out); input clk, q, p, r, s, valid1, valid2; output out; reg out, target; wire u1o, u2o; u1 u1(.clk(clk), .a(q), .b(p), .c(u1o)); u2 u2(.clk(clk), .l(u1o), .m(r), .n(u2o)); always@(posedge clk) begin if( valid1 && valid2) target = s ^ u1o; else if(s) target = u2o; else target = u1o; end endmodule module u1(clk, a, b, c); input clk, a, b; output c; reg c, t; always@(posedge clk) c = a & b; endmodule module u2(clk, l, m, n); input clk, l, m; output n; reg n, w; always@(posedge clk) n = l ^ m; endmodule Figure 11: Static slice 3 RTL SLICER 34

module top(clk, q, p, r, s, valid1, valid2, out); input clk, q, p, r, s, valid1, valid2; output out; reg out, target; wire u1o, u2o; u1 u1(.clk(clk), .a(q), .b(p), .c(u1o)); always@(posedge clk) if( valid1 && valid2) target = s ^ u1o; endmodule module u1(clk, a, b, c); input clk, a, b; output c; reg c, t; always@(posedge clk) c = a & b; endmodule Figure 12: Conditioned slice 4 FORMAL VERIFICATION METHODS 35

4 FORMAL VERIFICATION METHODS

Verification tools are used to ensure the functional correctness of a VLSI design. These tools can be classified as simulation-based verification tools and formal verification tools. The simulation-based verification [63] using validation tests is the main technique used in industry to verify complex

VLSI designs. Since exhaustive simulation using all possible input sequences is impractical, only small parts of the design can be veriﬁed. As designs become larger, the likelihood that the validation tests will uncover subtle errors becomes smaller.

Instead of using validation test in the simulation to validate the functionality of the design, formal verification uses mathematical methods to show that a design meets its specification. To accomplish this, designer generates formal properties using temporal logic [61] that encapsulate design specification. The design that is described in HDL is checked using these properties and formal verification techniques. The formal verification technique checks whether the properties hold using exhaustive search.

To establishing the equivalence between the Register Transfer

Level(RTL) and the logic level [29] in the formal veriﬁcation. The state-of-the-art industry tools require a correspondence between the state elements in the RTL design and the logic level description, essentially dealing with a combinational equivalence problem. However, to establish 4 FORMAL VERIFICATION METHODS 36 the equivalence of two Boolean functions is a NP-complete problem. It requires proper heuristics and a combination of diﬀerent techniques, such as

SATisﬁability(SAT) and Automatic Test Pattern Generation(ATPG) solvers to allow veriﬁcation tools to formally verify the Boolean equivalence of combinational blocks in industry designs.

There are several methods for formal veriﬁcation, such as such as theorem proving [59], model checking [33, 1] and symbolic trajectory evaluation [25]. Each approach has diﬀerent strengths and weaknesses [26].

Theorem proving technique describes both the specification and the implementation in a formal logic. The correct result then obtained by proving that the specification and the implementation were properly related. The main advantage of theorem proving is that it can be mechanically checked. However, this method requires a large amount of effort for the user to develop specifications of each component and to guide the theorem prover through all of the lemmas.

Model checking technique is the process of analyzing a design for the validity of properties stated in temporal logic. The input to a model checker is a formal description of the design, and the result is a set of states which satisfy the given property, or a witness of a sequence which violates the property.

McMillan [34] developed eﬃcient techniques to manipulate Boolean 4 FORMAL VERIFICATION METHODS 37 formulas in model checking using Ordered Binary Decision Diagrams

(OBDDs). Clarke et al. [3] showed that LTL model checking can be reduced to Computation Tree Logic (CTL) [4] model checking with fairness constraints. The use of OBDDs allow the analysis of designs without explicitly enumerating their states. However, OBDDs are also vulnerable to the state explosion problem for even moderately complex designs.

Symbolic trajectory evaluation considers symbols rather than actual values for the design under simulation. By this method, a symbolic simulator can simulate the response to entire classes of values with a single simulation run. Veriﬁcation using conventional simulation requires tedious analysis of several possible input states and sequences along with analysis of their responses. In contrast, symbolic simulation considers symbols rather than actual values for the design under simulation. By this method, a symbolic simulator can simulate the response to entire classes of values with a single simulation run. Based on the symbolic simulation technique,

Seger and Bryant [25] introduced the Symbolic Trajectory Evaluation, which is an eﬃcient lattice-based model checking approach.

This approach verifies the correctness of circuit behavior described as trajectory assertions. These assertions are derived from a restricted subset of temporal logic over a bounded length of state sequences. A main weakness of this approach is the restricted expressiveness of its specification 4 FORMAL VERIFICATION METHODS 38 language, which allows only properties over finite time intervals.

4.1 Temporal Logic

Temporal logic is a logic consist of temporal modal operators, which allow representing, and reasoning about how the truth values of assertions change over time [5]. The temporal logic can be used to express properties of a system behavior. In general, properties can be categorized into two classes: safety and liveness properties [10, 62].

A safety property means that something bad will never happen. •

A liveness property means that something good will eventually happen. •

For example, the property ”whenever a request signal is asserted, signal acknowledgment will asserted within 5 clock cycles” is a safety property. The property ”whenever a request signal is asserted, signal acknowledgment will eventually asserted” is a liveness property.

Linear Time Logic (LTL) is a temporal logic with modalities referring to time. Six propositional operators and four temporal operators are used to describe LTL properties in dealing with hardware veriﬁcation.

Propositional Operators: • (False) ⊥ (True) > 4 FORMAL VERIFICATION METHODS 39

(Negation) ¬ (Conjunction) ∧ (Disjunction) ∨ (Implies) →

Temporal Operators: • X (Next state)

F (Future state)

G (Global states)

U (Until)

An LTL formula φ is deﬁned recursively below [64]:

φ ::= p ( φ) (φ φ) (φ φ) (φ φ) X φ (φ U φ) ⊥ | > | | ¬ | ∧ | ∨ | → | | | G φ F φ. | If p and q are LTL formulas, then

X q is true if q is true in the next state. •

F q is true if q is true at some state in the future. •

G q is true if q is true at every state in the future. •

p U q is true if p holds true in the future until q becomes true. • 4 FORMAL VERIFICATION METHODS 40

4.2 Bounded Model Checking

Because the design space is usually large and the exhaustive search is expensive, the size of the design that formal veriﬁcation can handle is small.

To limit the search, a bound can be set on the size of sequence a formal veriﬁcation tool should examine. This is practicable based on the fact that designers know the bounds on the number of steps within which a property should hold. This leads to the idea of Bounded Model Checking (BMC) where the property is determined to hold within a ﬁnite sequence of state transitions.

BMC has become an important technology in formal methods.

Instead of fully search to proof the correctness, it employs search engines such as SAT or ATPG to seek for a counter-example to the property within a certain bound of the design. This method can discover inconsistencies between properties and designs at an earlier time.

SAT-based BMC [1] formulates the validity of the property as a boolean SATisﬁability (SAT) problem [16]. A counter-example to the property exists if and only if the generated SAT formula is satisﬁed. A SAT solver [41, 60, 49] is then applied to the formula. If a satisfying assignment found, then the property is invalid by counter-example. The performance of

SAT-based BMC is determined by the adopted SAT solver.

SAT is a computationally expensive algorithm and belongs to the 4 FORMAL VERIFICATION METHODS 41 class of NP-complete [27] problems. Many algorithmic solutions have been proposed for the SAT problem. These solutions are based on search techniques where all possible combinations of inputs are implicitly searched.

The popular methods are diﬀerent variations of the Davis-Putnam

Procedure [20], which is based on the identiﬁcation of unit clauses and on computing the resulting implications. The best known version of this procedure is based on a backtracking search algorithm that, at each node in the search tree, elects an assignment and prunes subsequent search space by iteratively using the unit clause and the pure literal rules [58]. Another

SAT solver GRASP [49] combines previously proposed search-pruning techniques and helps in identification of some new ones. GRASP is based on detecting the inevitable conflicts during search. The most important feature of this approach is the enhancement of basic backtracking search with a powerful conflict detection procedure. Detection and analysis of conflicts to determine their cause helps GRASP to backtrack nonchronologically in the search tree, pruning large portions of the search space. In addition, by recording the causes of conflicts GRASP can recognize and avoid the occurrence of conflicts later on in the search.

Zchaff [41] is a high performance SAT solver that achieves two orders of magnitude improvement over previous SAT solvers through clever and efficient implementation of Boolean Constraint Propagation (BCP) and low 4 FORMAL VERIFICATION METHODS 42 overhead decision strategies. More recently, a hybrid approach [41] combining the advantages of structural and CNF based algorithms was shown to be better than ZChaff.

Sequential Automatic Test Pattern Generation ( ATPG) [7] can also be used to search for a counter-example, by inserting a stuck-at fault at one primary output of the circuit. The fault is testable if and only if a counter-example exists. The test pattern for this fault is then generated by an ATPG solver. If a test pattern for the target fault is found, it constitutes a counter-example to the property.

Boppana et al. [52] proposed the use of sequential ATPG for model checking. Their work focused only on safety properties, and studied the eﬃciency of sequential ATPG algorithms for state-space exploration.

Cheng [13] discussed the use of ATPG for veriﬁcation, including combinational equivalence checking and property checking of safety properties (Fp, that p is true some time in the future). Huan and

Cheng [30] proposed a combination of structural, word-level sequential

ATPG and modular arithmetic constraint-solving techniques for checking safety properties. Hsiao and Jain [28] suggested the use of simulation based sequential ATPG for verifying simple safety properties of the type EFp and compared this with Ordered Binery Decision Diagrams(OBDD)-based approaches. 4 FORMAL VERIFICATION METHODS 43

ATPG can be used as an alternative/complement to SAT BMC [31].

ATPG and SAT solvers were compared by Parthasarathy [24], Saab [18] and Qiang [44]. In [24], their results on simple static circuit properties such as set-reset conﬂict and bus-contention properties showed that there was no performance gap between SAT and ATPG solvers.

By checking simple safety and liveness properties, Saab [18] showed that ATPG solver is better than SAT in both CPU time and memory requirement. Qiang [44] proposed a ATPG-based BMC technique for checking nested properties and compared it to SAT-based BMC system using USB2.0 IP core in [45]. The result shows that ATPG-based BMC is superior to the SAT-based BMC in analyzing industrial-sized design. 5 ATPG-BASED BMC FORMAL 44

5 ATPG-Based BMC Formal

ATPG generates input test patterns for a target fault, by propagating the fault-eﬀect to a primary output and justifying primary inputs to achieve that. ATPG-based BMC task is equivalent to ATPG justiﬁcation problem.

Figure 13 is the framework of the ATPG-based BMC approach

Formal [44]. The model checker takes two inputs: a Circuit Under

Verification (CUV) and a property that will be verified. The CUV is described in terms of a circuit netlist on gate level and a property is formally stated in a specification language Linear-Time Logic (LTL) as formula f. Based on the semantics of LTL, properties f are checked globally along all state paths. Therefore, its negation formula f is Existential (E) ¬ that is only checked along one path. This existential formula E[ f] is the ¬ real input to the model checker in the Formal.

The CUV is flattened into an Iterative Logic Array (ILA) model with the length equals to the search bound k. As shown in Figure 14, the combinational logic is duplicated into an series of time frames [35] that are interface along flip-flops. The existential formula E[ f] is mapped to a ¬ monitor circuit (as pk in Figure 14). The monitor is concatenate to the ILA model without any modification to the original CUV. A binary value ‘1’ is injected at the monitor output . The verification of a property is equivalent to the justification of a target signal line. An ATPG-based justification 5 ATPG-BASED BMC FORMAL 45 algorithm [44] then used to traverse the ILA model in a backward way to search for an input sequence . If an input sequence is found, the E[ f] ¬ formula is justified true. However, the evaluation of the initial input property f still depends on the type of property. A safety property is invalid if E[ f] is true (a counter-example exists); a liveness property is valid if ¬ E[ f] is false (no counter-example exists). ¬ 5 ATPG-BASED BMC FORMAL 46

Input property f

Translation Existential formula Sequential CUV E[ f] ILA Model Monitor (bound k) Circuit

ATPG−Based State Justification Algorithm

FAIL No Witness Yes DONE E[ f] False for counter− E[ f] True f depends example? f depends

Figure 13: Framework of ATPG-based BMC. 5 ATPG-BASED BMC FORMAL 47

P I P I P I Primary Combi− Primary 1 k−1 k Inputs national OutputsS T S S T S T S Logic 1 1 2 k−1 k−1 k k k+1 Present Next P O P O P O States States 1 k−1 k Flip− pk Flops line k `1' Sequential Circuit

Figure 14: Justiﬁcation on k time frames. 6 EXPERIMENT 48

6 EXPERIMENT

6.1 USB2.0 IP Core The USB2.0 is a standard interconnect that provides serial communication between a PC and its peripherals with rates of up to 50 MB/s. Figure 15 shows the USB2.0 functional blocks [17]. Typically, the USB2.0 architecture consists of three major functional blocks, the USB2.0

Transceiver Microcell (UTM), the Serial Interface Engine (SIE), and

Device-Speciﬁc logic. The SIE implements USB protocol and communicates with UTM, is developed by peripheral and IP vendors.

We used the open-source IP core [17] of the SIE for USB2.0 device controller to verify our approach. Architecture of the IP core is shown in

Figure 16. The Protocol Layer (PL) block handles data packets and all the standard USB protocol handshakes and control correspondence. The UTMI has a speed negotiation engine and has transmit/receive interface blocks.

The UTMI block communicates with external USB2.0 transceiver. The

Control/Status Registers (CSR) block contains all control and status registers required to realize SIE function. The Memory Interface and

Arbiter block provides arbitration between SIE core and host interface for the access to external Synchronous SRAM (SSRAM). Besides arbitration, it also performs data steering and ﬂow control. 6 EXPERIMENT 49

ASIC

Serial Interface Engine

End Point Logic SIE USB 2.0 USB 2.0 End Point Logic Device Specific Control Transceiver Microcell Logic Logic

End Point Logic

Figure 15: USB2.0 functional blocks.

IP Core Function Control/Status Registers Interface Memory Interface UTMI and PL UTMI I/F SSRAM Arbiter

Figure 16: Building blocks of IP core for SIE.

6.2 Experiment Results To present the impact of this approach, we use the USB2.0 IP core from

(opencores.org) to measure the eﬀect of slicing on a ATPG-based BMC

Formal [44] described in Chapter 5 and to compare Formal performance to

SMV [39] model checker with SAT-based capabilities. All experiments reported in this dissertation performed on SUN Blade workstation. An 6 EXPERIMENT 50 experiment is aborted when a 4 hours CPU limit is reached.

To verify the USB2.0 IP core, we derive a set of properties shown in

Table 3. For each property, a list of STV and condition is computed and supplied with the original Verilog description of the USB 2.0 to the slicer.

The slicer produced a sliced Verilog ﬁle for each of the properties listed in

Table 3. Table 4 lists the number of executable Verilog statements for the original design and sliced design for each property. Each row corresponds to a property except the second row which corresponds to the original design.

The third row corresponds to property S1.2. For this property, the slicer extracted a static slice and conditioned slice consisting of 615 and 481 lines respectively from an original model consisting 4484 lines of Verilog code

(86% to 90% of the original Verilog model does not aﬀect S1.2 property).

The sliced design for each property then served as the input circuit for the veriﬁcation tools.

The experiment results are shown in Table 5, Table 6, Table 7 and

Table 8. Table 5 and Table 6 show the CPU time and memory required by the SAT-based BMC SMV. The properties were veriﬁed for bound ranging between 50 and 100. Table 7 and Table 8 show the CPU and memory required by the ATPG-based BMC Formal.

The speed-up in term of CPU time for the SAT-based BMC SMV shown in Table 5 is more pronounced when the size of the sliced program in 6 EXPERIMENT 51 terms of number of lines is much smaller than the original unsliced Verilog program. This is case of property S17 a 4 to 20 times speed-up is shown. A smaller speed-up is gained when the slice program is similar in size to the original Verilog code. The memory usage in Table 6 shows that sliced model also reduced the memory requirement needed by the SMV.

The conditioned slicing reduces the state space by removing part of the program that did not contain the solution causing SMV to avoid searching the part and consequently reducing the search time and the memory requirement. These parts, which were excluded from the conditioned slice are included in the static slice. For this reason, a small difference in the size of the model between static and conditioned slice cased a significant difference in CPU time and memory requirement.

For the ATPG-based BMC Formal in Table 7, we observed that despite of the size of the sliced model, Formal running on the sliced model could obtain a great deal of performance improvement. Running the

ATPG-based model checker Formal on the sliced model achieves average speed-up in 1 to 4 orders of magnitude over over Formal system running on the original unsliced design. The slicer removed codes from the original

Verilog which resulting in the search heuristics to be more meaningful. The sliced model reduced the memory requirement of Formal by an average 2 to

100 times over running Formal on the original Verilog model. The memory 6 EXPERIMENT 52 usage is shown in Table 8.

Using the proposed RTL slicer as the pre-processor to the Formal system resulted in changing the runtime drastically in some cases reduces the run time from hours to seconds. For example, it requires more than 4 hours (14400 second) for both Formal and SMV to verify property T7 with bound 100 and requires only 28 second and 21 second to run Formal on the static sliced model and conditioned model respectively. The sliced model changed the heuristics measures used to direct the search in Formal which resulted in a more meaningful search.

In general, the ATPG-based BMC Formal achieves average speed-up in 1 to 3 orders of magnitude over SMV when the proposed RTL slicer is used as pre-processor. 6 EXPERIMENT 53

Table 3: USB2.0 IP core property descriptions.

S1.2 Always enter SUSPEND state from NORMAL state when the device has been idle for 3 milliseconds in full-speed mode or low-speed mode. S8 Always enter SPEED NEG FS state from SPEED NEG K state if the chip count number is not six and SE0 signal is asserted. S25 Always enter SUSPEND state or RESET state from NORMAL state when the device has been idle. T4 Always enter RESET state when the device has been in RES SUSP state for 100 us and SE0 signal is asserted. T5 Always enter SPEED NEG FS state from SPEED NEG J state if the chip count number is not six and SE0 signal is asserted. S18 Always set CRC16 error interrupt when received data packet has the destination address that matches current end point, and has failed the Cyclic Redundant Check (CRC) test. S17 Always not to enter IDLE state if current state is TOKEN state or DATA state, and the received data is valid, active, and error-free. T6 Always enter IDLE state from TOKEN state when the received data is valid, active, and error-free. S12.1 Always remain in IDLE state when abort signal is asserted. S12.2 Always not to enter IDLE state if the memory is not ready for writing or reading. T7 Always enter IDLE state from IDLE state via WAIT MRD state, MEM WR state, and MEM WR1 state when the device carries out DMA store operation. T8 Always enter MEM RD1 state from IDLE state when the device retrieves data from memory using DMA. S2 Always return NACK handshake when the device is unable to accept data from the host or has no data to transmit to the host. S10.1 Always remain in IDLE state when unknown token is received. S15 If the decoded incoming token matches the code sequence of OUT token in the control end point, it is identiﬁed as OUT token by the PE. S24 Always enter IDLE state from OUT2A state when abort signal is asserted for 3 milliseconds in high-speed mode. T1 Always enter IDLE state in non-isochronous IN transaction when DMA operation is done and a timeout occurs waiting for ACK handshake. T2 Always enter IDLE state in non-isochronous IN transaction when DMA operation is done and ACK handshake is received. T3 Always issue ACK handshake when the device operates in high-speed mode in OUT transaction and the buﬀer is available. 6 EXPERIMENT 54

Table 4: Slice size for each USB2.0 IP core property.

Static Slice Conditioned Slice Original File 4484 S1.2 615 481 S8 615 486 S25 615 498 T4 615 486 T5 615 482 S18 1569 1426 S17 637 588 T6 616 588 S12.1 3411 3321 S12.2 3411 3315 T7 3411 3374 T8 3411 3335 S2 3421 3298 S10.1 3411 3290 S15 3412 3282 S24 3411 3291 T1 3411 3297 T2 3411 3294 T3 3421 3291 6 EXPERIMENT 55

Table 5: CPU time(second) of SMV.

CPU CPU CPU Mod Prop Le- Original Static Cond. Cou -ules -ties vel b= b= b= b= b= b= -nter? 50 100 50 100 50 100 utmi S8 2 32 246 15 133 1.6 2.6 No -ls S25 3 40 348 18 211 10 75 No T4 2 26 198 12 77 1.9 3.5 No S1.2 2 18 163 10 155 2.0 3.5 No T5 2 15 42 8.7 31 1.5 2.7 No pl S18 2 1195 >4h 739 >4h 89 231 No pd S17 2 8.4 32 2.7 4.3 1.0 1.5 No T6 2 6.4 8.1 1.9 3.5 0.7 1.1 No idma S12.1 2 2494 11850 1731 6711 99 213 No S12.2 2 3598 >4h 3041 >4h 216 196 No T7 5 1779 >4h 1582 >4h 891 13478 No T8 2 991 >4h 742 >4h 110 3340 No pe S2 1 161 986 139 939 81 180 No S10.1 2 10713 >4h 8962 >4h 72 167 No S15 2 7427 >4h 6310 >4h 283 >4h No S24 2 520 8107 467 6914 376 3179 No T1 3 3771 >4h 617 >4h 103 >4h No T2 5 4498 >4h 3675 >4h 72 171 No T3 4 505 >4h 473 >4h 325 >4h No 6 EXPERIMENT 56

Table 6: Memory usage(MB) of SMV.

MEM MEM MEM Mod Prop Original Static Cond. -ules -ties b= b= b= b= b= b= 50 100 50 100 50 100 utmi S8 76 159 61 137 <1 <1 -ls S25 77 140 63 110 11 33 T4 76 160 58 133 <1 <1 S1.2 23 102 21 97 <1 <1 T5 19 41 14 41 <1 <1 pl S18 558 >1293 524 >1287 88 205 pd S17 25 37 12 17 <1 <1 T6 15 31 9 15 <1 <1 idma S12.1 546 1190 503 871 120 176 S12.2 575 >1114 570 >1100 113 177 T7 545 >1183 542 >1131 117 981 T8 545 >1074 489 > 862 121 198 pe S2 210 325 133 257 113 156 S10.1 707 >1102 120 188 70 154 S15 649 >1101 637 >1081 263 > 728 S24 558 1213 552 1201 243 371 T1 571 >1297 518 >936 260 > 592 T2 582 >864 580 >855 61 160 T3 560 >1420 552 >1411 368 >677 6 EXPERIMENT 57

Table 7: CPU time(second) of Formal.

CPU CPU CPU Mod Prop Le- Original Static Cond. Cou -ules -ties vel b= b= b= b= b= b= -nter? 50 100 50 100 50 100 utmi S8 2 14 26 1.5 3.1 0.3 0.5 No -ls S25 3 15 27 1.6 3.1 0.5 0.8 No T4 2 14 27 1.6 3.3 0.1 0.2 No S1.2 2 89 108 2.3 3.8 0.5 0.8 No T5 2 20 38 2.0 3.3 0.3 0.5 No pl S18 2 26 50 1.1 1.9 0.8 1.4 No pd S17 2 49 95 0.2 0.3 0.1 0.1 No T6 2 15 26 0.2 0.4 0.1 0.1 No idma S12.1 2 19 36 12 22 9.5 16 No S12.2 2 14 26 9.5 16 7.3 10 No T7 5 >4h >4h 16 28 13 21 No T8 2 19 35 11 24 7.3 11 No pe S2 1 18 35 12 25 6.1 14 No S10.1 2 104 111 13 25 6.0 11 No S15 2 14 26 8.6 15 5.5 14 No S24 2 >4h >4h 40 77 19 37 No T1 3 191 196 13 25 7.1 13 No T2 5 2027 2097 16 29 4.5 8.1 No T3 4 15 26 11 19 8 12 No 6 EXPERIMENT 58

Table 8: Memory usage(MB) of Formal.

MEM MEM MEM Mod Prop Original Static Cond. -ules -ties b= b= b= b= b= b= 50 100 50 100 50 100 utmi S8 108 245 12 17 <1 <1 -ls S25 130 245 12 18 <1 <1 T4 109 250 11 21 <1 <1 S1.2 153 279 13 23 <1 <1 T5 128 255 13 22 <1 <1 pl S18 232 492 10 18 6 15 pd S17 157 275 5 7 <1 <1 T6 151 262 4 7 <1 <1 idma S12.1 144 279 87 158 71 124 S12.2 105 258 73 145 57 133 T7 256 374 147 219 124 182 T8 152 248 87 159 55 90 pe S2 118 242 86 158 51 93 S10.1 166 292 87 160 36 79 S15 131 267 73 150 31 58 S24 287 540 164 313 90 161 T1 155 282 89 161 33 90 T2 256 374 143 220 22 52 T3 162 253 90 162 73 127 7 CONCLUSIONS 59

7 CONCLUSIONS

In this work, we presented a technique to obtain a HDL executable design slice that is behaviorally equivalent to the original design. The slice is less complex than the original design and require less resources to analyze by a veriﬁcation tool. The principle contribution of this thesis is:

1. This is the ﬁrst fully automated conditioned HDL slicer.

2. The ﬁrst slicer that handles the inter-module signal dependency in a

hierarchical Verilog design.

3. Users do not need to specify the slicing variables location like the

conventional method. This allows designers with little knowledge of

the Verilog code to generate meaningful slices.

Both static and conditioned Verilog slicer is implemented in a computer program that is used as a pre-processor to SMV a SAT-based verification tool and Formal a ATPG-based verification tool. The results show a significant reduction in both CPU and memory overhead needed to verify the USB2.0 IP core by SMV and Formal. This show that the potential to deal with the complex design efficiently.

In the case of SAT-based BMC SMV, The speed-up in term of CPU time is more pronounced when the size of the sliced program in terms of number of lines is much smaller than the original unsliced Verilog program. 7 CONCLUSIONS 60

For the ATPG-based BMC Formal, we observed that despite of the size of the sliced model, Formal running on the sliced model could obtain a great deal of performance improvement. Running the ATPG-based model checker

Formal on the sliced model achieves average speed-up in 1 to 4 orders of magnitude over over Formal system running on the original unsliced design.

In general, the ATPG-based BMC Formal achieves average speed-up in 1 to 3 orders of magnitude over SMV when the proposed RTL slicer is used as pre-processor. REFERENCES 61

References

[1] E. M. Clarke M. Fujita A. Biere, A. Cimatti and Y. Zhu. Symbolic model checking using sat procedures instead of bdds. Proc. DAC, pages 317–320, 1999.

[2] E. M. Clarke O. Grumberg and D. Peled. Model Checking. The MIT Press, 1999.

[3] E. M. Clarke, O. Grumberg, and H. Hamaguchi. Another look at ltl model checking. Formal Methods in System Design, 10(1):57–71, February 1997.

[4] E. M. Clarke, E. A. Emerson, and A. P. Sistla. Automatic verification of finite-state concurrent systems using temporal logic specifications. ACM Trans. on Programming Language and Systems, 8(2), April 1986. 244-263.

[5] E. A. Emerson. Temporal and Modal Logic. Handbook of Theoretical Computer Science, 995–1072, 1990.

[6] A. R. Fasolino A. De Lucia and M. Munro. Understanding function behaviors through program slicing. Proc. of the 4th Int. Workshop on Program Comprehension(WPC ’96), page 9, 1996.

[7] M. Abramovici, M. A. Breuer, and A. D. Friedman. Digital Systems Testing and Testable Design. IEEE Press, 1990.

[8] Hiralal Agrawa. On slicing program with jump statements. Proc. of the ACM SIGPLAN’94 Conf. on Programming Language Design and Implementation, 1994.

[9] Hiralal Agrawal and Joseph R. Horgan. Dynamic program slicing. Proc. of the ACM SIGPLAN’90 Conf. on Programming Language Design and Implementation, pages 246–256, June 1990.

[10] B. Alpern and F. Schneider. Recognizing safety and liveness. Distributed Computing, pages 117–126, 1987.

[11] Thomas Ball and Susan Horwitz. Slicing program with arbitrary control-ﬂow. Proc. of the First Int. Workshop on Automated and Algorithmic Debugging, pages 206–222, 1993.

[12] David Binkley. Precise executable interprocedural slices. ACM Letters on Programming Languages and Systems, pages 31–45, 1993.

[13] K. T. Cheng and A. Kristic. Current directions in automatic test-generation. IEEE Design & Test, 32:58–64, 1999. REFERENCES 62

[14] Jong-Deok Choi and Jeanne Ferrante. Static slicing in the presence of goto statements. ACM Transactions on Programming Languages and Systems, pages 1097–1113, July 1994.

[15] Edmund M. Clarke, Masahiro Fujita, Sreeranga P. Rajan, Thomas W. Reps, Subash Shankar, and Tim Teitelbaum. Program slicing of hardware description languages. Technical Report CMU-CS99 -103, 1999.

[16] S. A. Cook. The complexity of theorem proving procedures. The 3rd Annual ACM Symposium on the Theory of Computation, pages 151–158, 1971.

[17] Intel Corporation. Usb 2.0 transceiver microcell interface speciﬁcation. 2001.

[18] J. A. Abraham D. G. Saab and V. M. Vedula. Formal veriﬁcation using bounded model checking: Sat versus sequential atpg engines. Proc.16th Intl. Conf. on VLSI Design, 2003.

[19] David A. Padua B. Leasure David J. Kuck, R. H. Kuhn and Michael Wolfe. Dependence graphs and compiler optimizations. Conf. Record of the Eighth ACM Symposium on Principles of Programming Languages, pages 207–218, 1981.

[20] M. Davis and H. Putnam. A computing procedure for quantiﬁcation theory. J. of the ACM, 7(3):201–215, 1960.

[21] A. Cimitile G. Canfora and A. De Lucia. Conditioned program slicing. Information and Software Technology Special Issue on Program Slicing, pages 595–607, 1998.

[22] A. De Lucia G. Canfora and M. C. Munro. An integrated environment for reuse reengineering c code. J. of Systems and Software, pages 153–164, 1998.

[23] A. De Lucia G. Canfora, A. Cimitile and G. Di Lucca. Software salvaging based on conditions. pages 424–433, 1994.

[24] C.-Y. Huang G. Parthasarathy and K.-T. Cheng. An analysis of atpg and sat algorithms for formal veriﬁcation. Proc. 6th IEEE Intl. High-Level Design Validation and Test Workshop, pages 177–182, 2001.

[25] C.-J. H. Seger and R. E. Bryant. Formal Veriﬁcation by Symbolic Evaluation of Partially-Ordered Trajectories. Formal Methods in System Design, 6(2):147–189, 1995.

[26] C.-J. H. Seger. An Introduction to Formal Hardware Veriﬁcation. Technical Report 92-13, UBC, Department of Computer Science, 1992. REFERENCES 63

[27] M. R. Garey and D. S. Johnson. Computers and intractability. W. H. Freeman and Co., New York, 1979.

[28] M. Hsiao and J. Jain. Practical use of sequential atpg for model checking: Going the extra mile does pay oﬀ. Proc. High Level Design Veriﬁcation & Test Workshop, pages 39–44, 2001.

[29] S.-Y. Huang and K.-T. Cheng. Formal Equivalence Checking and Design Debugging. Frontiers in Electronic Testing, 12, 1998.

[30] C.-Y. Huang and K.-T. Cheng. Using word-level atpg and modular arithmetic constraint-solving techniques for assertion property checking. IEEE Trans. on CAD, 20(3):381–391, 2001.

[31] V. M. Vedula J. A. Abraham and D. G. Saab. Verifying properties using sequential atpg. Proc. Intl. Test Conf., pages 194–202, 2002.

[32] Daniel Jackson and Eugene Rollins. A new model of program dependence for reverse engineering. Proc. of the Second ACM SIGSOFT Symposium no Foundations of Software Engineering, 19:2–10, Dec 1994.

[33] J. R. Burch, E. M. Clarke, K. L. McMillan, D. L. Dill, and J. Hwang. Symbolic Model Checking: 1020 States and Beyond. Information and Computation, 98(2):142–170, 1992.

[34] K. L. McMillan. Symbolic Model Checking. Kluwer Academic Publishers, 1993.

[35] N. K. Jha and S. Gupta. Testing of Digital Systems. Cambridge University Press, 2003.

[36] Karl J. Ottenstein Jeanne Ferrante and Joe D. Warren. The program dependence graph and its use in optimization. ACM Transactions on Programming Languages and Systems, pages 319–349, 1987.

[37] B. Korel and J. Lask. Dynamic slicing of computer programs. J. of Systems and Software, pages 187–195, 1990.

[38] B. Korel and J. Laski. Dynamic program slicing. Information Processing Letters, pages 155–163, 1988.

[39] Candence Berkeley Lab. Candence smv. http://www-cad.eecs.berkeley.edu/.

[40] Hareton K.N. Leung and Hassan K. Reghbati. Comments on program slicing. IEEE Transactions on Software Engineering, pages 1370–1371, 1987. REFERENCES 64

[41] Y. Zhao L. Zhang M. Moskewicz, C. Madigan and S. Malik. Chaﬀ: Engineering an eﬃcient sat solver. Proc. DAC, pages 530–535, 2001.

[42] Shigeru Ichinose Mizuho Iwaihara, Masaya Nomura and Hiroto Yasuura. Program slicing on vhdl descriptions and its applications. Proc. of Asian Paciﬁc Conf. on Hardware Description Languages, pages 132–139, 1996.

[43] Karl J. Ottenstein and Linda M. Ottenstein. The program dependence graph in a software development environment. Proc. of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments, pages 177–184, 1984.

[44] D. G. Saab Q. Qiang and J. A. Abraham. Checking nested properties using bounded model checking and sequential atpg. Proc. 19th Intl. Conf.on VLSI Design, 2006.

[45] D. G. Saab Q. Qiang, C.-L. Chang and J. A. Abraham. Case study of atpg-based bounded model checking: Verifying usb2.0 ip core. Proc. of ICCD, 2005.

[46] Mark Harman Sebastlan Danicic, Chris Fox and Rob Hierons. Consit: A conditioned program slicer. In IEEE Int. Conf. on Software Maintenance, pages 216–226, 2000.

[47] Li Shen. Vrm - verilog rtl model. http://www.ict.ac.cn.

[48] A. Silburt. Functional veriﬁcation of silicon intensive system. On-Chip System Design Conf., 1998.

[49] J. M. Silva and K. A. Sakallah. Grasp—a new search algorithm for satisﬁability. Proc. ICCAD, 1996.

[50] Thomas Reps Susan Horwitz and David Binkly. Interprocedural slicing using dependency graphs. ACM Transaction on Programming Languages and Systems, pages 26–60, 1990.

[51] Yang Guo Tun Li and Sikun Li. An automatic circuit extractor for rtl veriﬁcation. Proc. of the 12th Asian Test Symposium, 2003.

[52] K. Takayama V. Boppana, S. P. Rajan and M. Fujita. Model checking based on sequential atpg. Proc. 11th Intl. Computer Aided Veriﬁcation Conf., pages 418–430, 1999.

[53] Vivekananda M. Vedula and Jayanta Bhadra Jacob A. Abraham. Program slicing for hierarchical test generation. Proc. of the 20th IEEE VTS, pages 237–246, 2002. REFERENCES 65

[54] Whitney J. Townsend Vivekananda M. Vedula and Jacob A. Abraham. Program slicing for atpg-based property checking. Proc. of the 17th Int. Conf. on VLSI Design, 2004.

[55] M. Weise. Program slicing. IEEE Transactions on Software Engineering, pages 352–357, 1984.

[56] R. P. Kurshan. Computer-aided veriﬁcation of coordinating processes: the automata-theoretic approach. Princeton University Press, 1994.

[57] S. Williams. The icarus verilog compilation system. http://icarus.com/eda/verilog.

[58] R. Zabih and D. A. McAllester. A rearrangement search strategy for determining propositional satisﬁability. Proc. of the National Conf. on Artiﬁcial Intelligence, pages 155–160, 1988.

[59] R. S. Boyer and J. S. Moore. A Computational Logic Handbook. NewYork: Academic Press, 1988.

[60] H. Zhang. Sato: An eﬃcient propositional prover. Intl. Conf. on Automated Deduction, pages 272–275, 1997.

[61] A. Pnueli. The temporal semantics of concurrent programs. Proc. 18th Symposium on Foundations of Computer Science, 1977.

[62] L. Lamport. Proving the Correctness of Multiprocess Programs. IEEE Trans. Software Engineering, 3(2):124–143, 1977.

[63] S. Kang and S. A. Szygenda. The Simulation Automation System(SAS): Concepts, Implementation, and Results. IEEE Trans. VLSI Systems, 89–99, Mar 1994.

[64] M. R. A. Huth and M. D. Ryan. Logic in Computer Science: Modelling and Reasoning about Systems. Cambridge University Press, 2000.