Semantics of RTL and Validation of Synthesized RTL ... - CiteSeerX

Semantics of RTL and Validation of Synthesized RTL Designs using Formal Verification in Reconfigurable Computing Systems Phan C. Vinh and Jonathan P. Bowen London South Bank University Centre for Applied Formal Methods, Institute for Computing Research Faculty of BCIM, 103 Borough Road, London SE1 0AA, UK URL: http://www.cafm.lsbu.ac.uk/ Email: {phanvc,bowenjp}@lsbu.ac.uk

Abstract The functional validation of a state-of-the-art reconfigurable computing system design is usually a laborious, ad hoc and open-ended task. It can be accomplished through two basic approaches: simulation and formal verification. In validation using a formal verification approach, it attempts to establish that the Register Transfer Level (RTL) design synthesized from the algorithmic behavioral specification is mathematically correct. Therefore, finding the verification methods to provide accurate and fast validation easily would be very useful. In this paper, we develop a semantics based on a Partial Order Based Model (POM) for RTL and, through this semantics, propose a formal verification method to prove the correctness of the RTL synthesis result. This method can be used to achieve the following. On one hand, it can accurately verify an RTL description with respect to a behavioral specification of the system; on the other hand, it can decide whether two processes, which are supposed to implement the same function, have the same interactive behaviors so that one can be replaced by the other.

1

Introduction

As high-level synthesis (HLS) in reconfigurable computing systems become more sophisticated and synthesized designs get more complex, it is important that we develop a systematic approach to the validation of synthesized Register Transfer Level (RTL) designs [13, 14]. Functional validation of a synthesized RTL design can be usually accomplished through two basic approaches: simulation and formal verification [4, 6, 7]. In this paper, we present our efforts to develop a Partial Order Based Model (POM) based semantics for RTL and, through these, to verify formally the RTL designs generated by an HLS system that accepts algorithmic behavioral specifications written in a subset of VHDL and generates a register transfer level design, also

expressed in VHDL. Validation using formal verification methods attempts to establish that the RTL design synthesized from the algorithmic behavioral specification is mathematically correct. Theorem proving and model checking are two popular formal verification approaches. Our approach is to model the behavior using a POM notion and use this model to develop interesting properties of the model that should hold both at the behavior and register transfer levels. After the RTL design is synthesized, we will verify whether the same properties continue to hold for the RTL design. This paper is organized as follows. Section 2 will draw some main shapes of related work. Section 3 will present some basic definitions of POM notion. Section 4 gives the POM semantics for the RTL model. A verification algorithm for the RTL synthesis results in reconfigurable computing systems using a POM is presented in section 5 and a short conclusion is given in section 6.

2

Related Work

Another validation methodology of synthesized RTL designs is to use a simulation approach, as presented informally in [6, 7], for comparing simulation results of an algorithmic VHDL specification and a synthesized RTL design, also represented as a VHDL description, which allows a change in the cycle-by-cycle behavior without significant limitations. To enable this comparison, a common set of simulation vectors is used. The information given in this vector set serves as input to its POM, with which the comparison is executed. Recently, a number of researchers have been investigating techniques known as partial-order methods that can significantly reduce the running time of formal validation by avoiding redundant exploration of execution scenarios. The results in [4] describe the design of a partial-order algorithm for the validation tool and discuss its effectiveness. It shows

that a careful compile-time static analysis of process communication behavior yields information that can be used during validation to dramatically improve its performance.

state x and R(a, x) = 0, otherwise. Each state xi ∈ 2A is defined in terms of R as:

3

The POM in Figure 2 has three events, {a, b, c}, and six states, {x0 , x1 , x2 , x3 , x4 , x5 }. It represents a system where any event of {a, b, c} occurs and according to the information computed by that event, one of two rest events will occur. In state x0 , the event c has occurred; x2 represents the state where b has occurred after c or c has occurred after b. And so on. We can represent the POM in the form of a matrix or as a logical formula or as a Hasse diagram [11]. In the matrix, each entry (a, x) contains the value of the occurrence relation. Thus, the rows of the matrix correspond to the states of the POM and the columns correspond to the events of the POM. Considering the matrix as a truth table, we can have a logical formula representing the POM. The pictorial representation as a Hasse diagram illustrates the partial order existing between the states.

Some definitions

Definition 3.1 (Chu space) A Chu space is a binary relation between two sets A and X. It is written as a triple (A, X, R), where R : A × X → {0, 1} is the binary relation as a characteristic function of a subset of A × X. A Chu space [5] does not impose any cardinality restrictions on A and X. Thus all arguments given below will work for all cardinalities. We can think of A as the set of events (representing the actions) and X as the set of states (representing the possible or permitted states). A state is defined in terms of an occurrence relation R(a, x) that is true when the event a has occurred in the state x. Thus, each state x is a subset of A containing the events that has occurred in the state. The visual way to write out a Chu space explicitly is as a binary matrix of dimension |A| × |X|, with each entry giving the value of the relation R on its pair of coordinates. A is written at the top and X on the side. Figure 1 gives examples of some Chu spaces. The elements of A are denoted by a, b, c, d, . . ., and u, v, w, x, . . . for elements of X. Matrix R a b x0 1 1

Hasse Diagram 11 b a 10 01 a b

Matrix R a b x0 0 0 x1 1 1

Hasse Diagram 11 b a 10 01 a b 00

00

R x0 x1 x2 x3 x4 x5

Matrix a b 0 0 0 1 0 1 1 0 1 0 1 1

xi = {a|a ∈ A and R(a, xi ) = 1}

POM=(A,X,R) where A={a,b,c} X={{c},{b},{b,c},{a},{a,c},{a,b}} R(A,X) is represented by the following binary matrix.

x0 x1 x2 x3 x4 x5

a 0 0 0 1 1 1

Matrix b c 0 1 1 0 1 1 0 0 0 1 1 0

Logical formula fPOM= {c} abc + {b} abc + {b,c} abc + {a} abc + {a,c} abc + {a,b} abc

Hasse Diagram 111 b 101

b 101

c

c 100

011

a b

c

001 a

010 c

b 000

b

011

a b

c

001 a

b

a 110

a

a

100

111

a 110

c

Hasse Diagram c 1 0 1 0 1 0

c

Figure 2. POM and its representations

010 c

b 000

Figure 1. Chu spaces and its representations

Definition 3.2 (POM) A POM is a Chu space C given by the tuple (A, X, R), where • A = {a0 , a1 , . . . , an } is a set of events, • X = {x0 , x1 , . . . , xn } is a set of states, and • R : A × X → {0, 1} represents the occurrence relation; i.e., R(a, x) = 1 if the event a has occurred in the

Definition 3.3 (Logical Representation) We define the logical representation fC of the POM C as: _ fC = fxi 0B) then C:=A+B; else C:=abs(A-2*B); end if; send(C, channel1); end process;

events ---------a0 ---------a1 ---------a2 ----------

a3

----------

a4

Figure 7. A process and its event list Dynamically reconfigurable computing expresses the notion that the dynamic selection of if . . . then . . . else describes the reconfiguration in similar way to the RC MUX dynamic reconfiguration abstraction proposed by Luk et al., reported in [10] and to a lesser extent in [9], which requires all the alternatives to have inputs of the same type and an output of the same type. This dynamic selection is also similar to the scheme presented in [12], which is a little more general than RC MUX mechanism. The scheme in [12] can describe dynamic selection between behaviors with totally different types. The design of Flexible Array Blocks (FABs) [8] and Reduced Flexible Array Blocks (RFABs) [15] can be expressed using dynamic selection because the reconfiguration behavior is controlled by four configuration bits, which are inputs to the dynamic selec-

Creating the POMSP EC

The main task is the generation of the partial order description of the program statements created in section 5.2. In other words, this description is used to indicate the data dependencies of statements necessary for the generation of the possible POM description of the algorithmic specification, namely (POMSP EC ). To fulfill this task, we need to explain some terminologies in terms of the following basic relations between events: independence, precedence, conflict and disjunctive enable relation [11]. Definition 5.1 (Independence relation) The independence relation (a∇b) represents the independent execution of two events a and b. The POM for this relation is shown in Figure 8, where all states are permitted; that is, all subsets of A are valid states. No order is imposed to the occurrence of the events a and b.

∇ x0 x1 x2 x3

a 0 0 1 1

b 0 1 0 1

p a b x0 0 0 x1 1 0 x2 1 1

f∇= ab + ab +

ab + ab =1 # x0 x1 x2

a 0 0 1

b 0 1 0

f#= ab + ab + ab = a +b

fp= ab + ab + ab = a+b

den x0 x1 x2 x3 x4 x5 x6

a 0 0 0 0 1 1 1

b 0 1 0 1 0 1 1

c 0 0 1 1 1 0 1

fden= ab c + a bc + ab c + a bc + ab c + abc + abc = a +b+c

Figure 8. Some basic relations between events Definition 5.2 (Precedence relation) The precedence relation (a ≺ b) represents the occurrence of the event a followed by the occurrence of the event b. The POM representation for the relation can be seen in Figure 8. This relation is used to model the sequential execution of events. Definition 5.3 (Conflict relation) The conflict relation (a#b) represents either the occurrence of a or the occurrence of b. The corresponding POM and logical formula are shown in Figure 8. A conflict relation between two events a and b means that both a and b can never occur in a same computation of the POM. Definition 5.4 (Disjunctive enable relation) The disjunctive enable relation permits the representation

of two events, whose executions disjunctively enable a third event; i.e., den(a, b, c) means the execution of b OR c enables the occurrence of a. This relation is needed, together with the conflict relation explained above, to enable the events that follow an if. . . then. . . else statement. Figure 8 presents the POM and its corresponding logical formula. In our practical approach to creating POMSP EC , we use the relations between events. These relations can be extracted from the system specification given in a high-level programming language as in section 5.2. Let there be a process P with a set of events A, together with R relations between events, which were extracted from that process specification as follows. In Figure 7, we have five events, where a0 precedes a1 , a1 precedes a2 , a1 precedes a3 , a2 and a3 are in conflict, and the execution of a2 OR a3 enables the occurrence of a4 . The conjunction them give us the POM for the process P. Formally, POMSP EC is described as POMSP EC = {a0 ≺ a1 , a1 ≺ a2 , a1 ≺ a3 , a2 #a3 , den(a4 , a2 , a3 )}

5.5

RTL Synthesis Result

This is an RTL synthesis result of the algorithmic behavioral specification. This result has been created from the synthesis stage and is transferred into the current verification. The RTL module [1, 3] is defined by the following: • Components: contains the declaration of the components that make up the processing unit. • Control sequence: defines the internal command sequence that must be emitted by the control unit. • Permanent assignment: defines an operation that must be repeated every clock cycle. The control sequence is made up of steps; each one is numbered and must be executed in a single clock unit. Figure 10 shows this control sequence for the process P.

0

(a0 , a1 , a2 , a3 , a4 ) ( a 0 , a1 , a 2 , a 3 , a 4 )

1 ( a 0 , a1 , a 2 , a 3 , a 4 )

2

5.4

( a 0 , a1 , a 2 , a 3 , a 4 )

Creating the POMSP EC -automaton

( a 0 , a1 , a 2 , a 3 , a 4 )

and POMSPEC- a0 a1 a2 a3 a4 automaton x0 0 0 0 0 0 x1 1 0 0 0 0 x2 1 1 0 0 0 x3 1 1 1 0 0 1 1 1 0 1 x4 x5 1 1 0 1 0 1 1 0 1 1 x6 Logical formula: f = fa0 p a1 Λ fa1 p a2 Λ fa1 p a3 Λ fa2 # a3 Λ fden(a4, a2, a3) = ( a 0 + a1 ) Λ ( a1 + a 2 ) Λ ( a1 + a3 ) Λ ( a 2 + a 3 ) Λ ( a 4 + a 2 + a3 ) = a 0 a1a 2 a 4 + a 0 a 2 a 3 a 4 + a 0 a1 a 3 a 4 +

a1a 2 a 3 a 4 + a0 a1a 2 a3 + a0 a1a 2 a3

Figure 9. POMSP EC -automaton of process P

( a 0 , a1 , a 2 , a 3 , a 4 ) ∧ ( a 0 , a1 , a 2 , a 3 , a 4 )

(a0 , a1 , a 2 , a3 , a4 )

3

4

( a 0 , a1 , a 2 , a 3 , a 4 )

From the event list and dependency relations between the events created in section 5.3, an automaton of the POMSP EC is created (see Figure 9). POMSPEC = {a0 p a1, a1 p a2, a1 p a3, a2 # a3, den(a4,a2,a3)}

( a 0 , a1 , a 2 , a 3 , a 4 )

( a 0 , a1 , a 2 , a 3 , a 4 )

( a 0 , a1 , a 2 , a 3 , a 4 )

5

Figure 10. RTL control of process P

5.6

Creating the POMRT L -automaton

A POM-automaton needs to be generated from the RTL synthesis result. From the RTL of process P as shown in Figure 10, a POMRT L -automaton is created as in Figure 11.

POMRTL- a0 a1 a2 a3 a4 automaton S0 0 0 0 0 0 S1 1 0 0 0 0 S2 1 1 0 0 0 S3 1 1 1 0 0 S4 1 1 0 1 0 S5 1 1 x y 1 where: x,y ∈{0,1} and x ≠y Figure 11. POMRT L -automaton of process P

5.7

Comparison between the POMSP EC automaton and POMRT L -automaton

In comparing the POM specification and RTL automata, we need to determine the following to verify the correctness of an RTL synthesis result. Definition 5.5 (Correctness of an RTL Synthesis result) An RTL synthesis result using a POM is correct iff it satisfies all requirements of the POM specification. Theorem 5.1 An RTL synthesis result using a POM is correct iff L(RT L) = L(SPEC). In other words, the set of all computations accepted by RT L is equal to the ones accepted by SPEC. Proof 5.2 “if” part. By definition 5.5, when L(RT L) is equal to L(SPEC) then an RTL synthesis result is correct. To prove the “only if” part, we need to prove that if L(RT L) 6= L(SPEC) then the RTL synthesis result is not correct. There are two cases as follows: If L(RT L) ⊂ L(SPEC) then there exists a requirement of computation Γ ∈ L(SPEC)\L(RT L) that is not synthesized in the RTL result. By definition 5.5, the RTL synthesis result is not correct. If L(SPEC) ⊂ L(RT L) then the specification and RTL synthesis are not equivalent. In consequence of this, their computing behaviors are distinct. In other words, the RTL synthesis result is not correct as well.  This consideration shows that if the synthesis process has generated a valid RTL result, then a comparison is carried out here as an examination that checks whether a POMRT L automaton is equivalent to a POMSP EC -automaton. Indeed, Figures 9 and 11 show that L(RT L) = L(SPEC); thus the verification indicates the correctness of the RTL synthesis results for the process P.

6

Summary

In this paper, a Partial Order Based Model (POM) based semantics for a Register Transfer Level (RTL) description and a verification algorithm have been developed for validating the RTL synthesis results. Some key features of this approach are that, firstly, the notion of a POM (as a Chu space) is considered as a semantic basic for RTL and, secondly, the notion of POM-automata is dedicated towards formal correctness of the synthesis result at the register transfer level. The formal verification method is based on functional equivalence checking to determine if the POMRT L -automaton is equivalent to the POMSP EC automaton. In other words, a comparison is defined as an examination that checks whether the synthesis process has generated a valid RTL description.

References [1] B. Bailey and D. Gajski. RTL semantics and methodology. In Proc. 14th International Symposium on Systems Synthesis, pages 69–74, Montreal, Canada, 30 September – 3 October 2001. [2] V. Carchiolo, M. Malgeri, and G. Mangioni. An algorithm for direct synthesis of formal specifications. In Proc. 8th IEEE International Workshop on Rapid System Prototyping, pages 28–38, 24–26 June 1997. [3] V. Carchiolo, M. Malgeri, and G. Mangioni. Hardware/software synthesis of formal specifications in codesign of embedded systems. ACM Transactions on Design Automation of Electronic Systems, 5(3):399–432, July 2000. [4] P. Godefroid, D. Peled, and M. Staskauskas. Using partialorder methods in the formal validation of industrial concurrent programs. IEEE Transactions on Software Engineering, 22(7):496–507, July 1996. [5] V. Gupta. Chu Spaces: A Model of Concurrency. PhD thesis, Stanford University, USA, 1994. [6] C. Hansen, A. Kunzmann, and W. Rosenstiel. Verification by simulation comparison using interface synthesis. In Proc. Design, Automation and Test in Europe (DATE), pages 436– 443, 23–26 February 1998. [7] C. Hansen, F. A. M. D. Nascimento, and W. Rosenstiel. Verifying high level synthesis results using a partial order based model. In Proc. Hardware Languages, Design, Verification and Test (HLDVT), San Diego, CA, USA, November 1998. [8] S. D. Haynes and P. Y. K. Cheung. A reconfigurable multiplier array for video image processing tasks, suitable for embedding in an FPGA structure. In Proc. IEEE Symposium on FPGAs for Custom Computing Machines, pages 226–234, 15–17 April 1998. [9] W. Luk, N. Shirazi, and P. Y. K. Cheung. Compilation tools for run-time reconfigurable designs. In Proc. 5th Annual IEEE Symposium on FPGAs for Custom Computing Machines, pages 56–65, 16–18 April 1997. [10] W. Luk, N. Shirzi, and P. Y. K. Cheung. Modelling and optimising run-time reconfigurable systems. In Proc. IEEE Symposium on FPGAs for Custom Computing Machines, pages 167–176, 17–19 April 1996. [11] F. A. M. D. Nascimento and W. Rosenstiel. Partial order based modeling of concurrency at the system level. In Proc. International Workshop on Conjoint Systems Engineering (CONSYSE), BadT¨olz, Germany, March 1997. [12] S. Singh. Interface specification for reconfigurable components. In Proc. IEEE/ACM International Conference on Computer Aided Design (ICCAD), pages 102–109, San Jose, USA, 10–14 November 2002. [13] P. C. Vinh and J. P. Bowen. An algorithmic approach by heuristics to dynamical reconfiguration of logic resources on reconfigurable FPGAs. In Proc. ACM/SIGDA 12th International Symposium on Field Programmable Gate Arrays, page 254, Monterey, USA, 22–24 February 2004. [14] P. C. Vinh and J. P. Bowen. On the visual representation of configuration in reconfigurable computing. Electronic Notes in Theoretical Computer Science (ENTCS), 109:3–15, 2004. [15] C. Visavakul, P. Y. K. Cheung, and W. Luk. A digit-serial structure for reconfigurable multipliers. In G. J. Brebner and R. Woods, editors, Field-Programmable Logic and Applications, volume 2147 of Lecture Notes in Computer Science, pages 565–573. Springer-Verlag, 2001.