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 0

where n = |X| and fxi is the logical formula corresponding to xi ∈ X, defined as follows: V V V fxi = ( {a|a ∈ A} and R(a, xi ) = 1) ( {a|a ∈ A} and R(a, xi ) = 0) In the logical representation, we have the events as variables, the states as terms of the formula and the relation R determines whether the variable appears complemented or not. The logical formula f is true for each state that is permitted in the POM.

4

POM-based semantics for RTL

Ck

ini

i

As a starting point, we deal with the problem of oneto-one synchronization with a value exchange, irrespective of the value actually exchanged [3, 2]. Synthesis of the complex synchronization into RTL form requires the use of several signals to guarantee the semantic correctness of the synthesis. So each synchronization operation (event) is associated with three signals, one for the exchange of the data itself and two others to manage the synchronization (a ready and an acknowledgment signal). The need for two signals for synchronization is due to the fact that communication is a rendezvous between events. Let us assume we have two processes, S and R, which respectively offer and are able to accept a value v through a gate g at a certain time. In this case, two gates are involved in the synchronization, one of which offers a value (expressed by the symbol “!”), while the other accepts a value (indicated by “?”). This situation is expressed as in the two following sets of events: S kg R where S = {. . . g!v . . .} R = {. . . g?v . . .} Schematically, synthesis of the events g!v and g?v can be represented as in Figure 3. The signal ini (inj ) represents the signal enabling execution of block i(j) and signal outi (outj ) represents the termination of block i(j) (which coincides with the signal enabling execution of the block i + 1). The signal gn is needed when a choice operation is involved in the synchronization. The blocks i and j are synthesized into the RTL language as in Figure 3. The transmitter waits for the receiver to be available for synchronization, after which it acknowledges the synchronization and exchanges the value (if any); vT represents the variable containing the value to be transferred, which in RTL is equivalent to a register. The behavior of the receiver complements that of the transmitter; vR is the register that, following synchronization, will contain the value exchanged. According to the synthesis scheme used, the transmitter is translated in four RTL steps and the receiver in three steps.

4.1

Set of events

Let us consider the one-to-one synchronization with a value exchange described above. Each synchronization event is associated with three signals: one for the exchange of the data itself (gn ), and two others to manage the synchronization (grdy and gack ). In the sequel, we consider the finite event set A = {(¬grdy , ¬gack , ¬gn ), (¬grdy , ¬gack , gn ), (¬grdy , gack , ¬gn ), (¬grdy , gack , gn ), (grdy , ¬gack , ¬gn ), (grdy , ¬gack ,

gn

Ck gack

gack

gv

gv

!

gn

grdy

outi

outj

(a)

(b)

: : if(¬grdy ; grdy) goto(x ; x+1)

x+1 : gack 1 x+2 : if(¬gn ; gn) goto(x ; x+3) x+3 : gv ... :

j

? grdy

... x

inj

vT

// Wait for the receiver to be ready to synchronize // Acknowledges the synchronization // Wait for the synchronization to be correctly concluded by the receiver (gn=1) // Exchanges the value

(c) Translation of 3(a) ... y

: : grdy 1 ; if(¬gack ; gack) goto(y ; y+1)

y+1

: gn

1

y+2 ...

: vR :

gv

// Warns the transmitter to be ready for synchronization and simultaneously sends an ack signal // Informs transmitter that synchronization has actually occurred // Accepts the value

(d) Translation of 3(b)

Figure 3. The basic interaction events and RTL language

gn ), (grdy , gack , ¬gn ), (grdy , gack , gn )}. At each rising edge of the clock, an action must be executed. The meaning of the event set is that the action (¬grdy , ¬gack , ¬gn ) is executed when no grdy , no gack and no gn occur; (¬grdy , ¬gack , gn ) is executed when no grdy and no gack occur but only gn occurs; and so on. Definition 4.1 (Computation) A finite sequence of actions is a computation over A and the set of all computations is denoted by A*.

4.2

Set of States

Let X be the set of states representing the possible or permitted states. A state y ∈ X is defined in terms of a transition relation T (a, x) when the event a ∈ A can make a transition from the state x ∈ X to y. Thus, each state y is a subset of A containing the events that can make a transition from that state x, that is y = {a|a ∈ A and T (a, x) = y} Definition 4.2 (Successor and Predecessor States) A state xi ∈ X is a predecessor of a state xj ∈ X if T (a, xi ) = xj . Thus, xj is a successor of xi .

Definition 4.3 (Initial State) A state xi ∈ X is a initial state when it has no predecessors; i.e., there is no state xj ∈ X such that T (a, xj ) = xi . Definition 4.4 (Final State) A state xi ∈ X is a final state when it has no successors; i.e., there is no state xj ∈ X such that T (a, xi ) = xj . Indeed, the triple (A, X, T ) is a POM as defined in section 3 and the computation in definition 4.1 can be also understood as follows: a computation Γ of a POM (A, X, T ) is a partial order on X under transition relation T ; i.e., Γ = (x0 , x1 , ..., xn ) where for all xi , xi+1 ∈ Γ, xi+1 is a successor of xi .

(gack = 1) and state 3 (or xS3 ) to the to the correct conclusion of the synchronization by the receiver (gn = 1). In Figure 4(b), the state named state 0 (or xR 0 ) corresponds to warning the transmitter to be ready for synchronization and simultaneously sends an ack signal (grdy = 1); state 1 (or xR 1 ) corresponds to acknowledgement of the synchronization (gack = 1), and state 2 (or xR 2 ) to informing the transmitter that synchronization has actually occurred (gn = 1).

Definition 4.5 (POM Execution) An execution α of a POM (A, X, T ) is an infinite sequence of computations Γi of (A, X, T ).

! State 0( x0S )

grdy 0

gack z

gn z

State 1( x1S )

1

0

z

State 2( x 2S ) State 3( x3S )

1 1

1 1

0 1

where: z∈{0,1} (0,z,z)

From this observation we will develop the notion of POMautomata in the sections below.

x0S

(1,0,z)

x1S

(1,0,z)

4.3

(1,1,0)

x2S

(1,1,0)

(1,1,1)

x3S

(1,1,1)

POM-Automata (a)

A POM-automaton is a triple A = (X, x0 , T ) where • X is a finite set of states, • x0 is the initial state, • T is a function from X ×A into X ∪{⊥}, the transition function. If T (x, a) =⊥, no transition labeled by a can be fired from state x. (⊥ can be viewed as a sink state). A computation Γ = a1 . . . an is accepted by the automaton if there exists x1 , . . . , xn ∈ X such that: • T (x0 , a1 ) = x1 • ∀i > 1, T (xi−1 , ai ) = xi This will be denoted by: a1

a2

gack 0

gn z

State 1( x1R )

1 1

1 1

0 1

State 2( x ) where: z∈{0,1}

(1,0,z) x0R

(1,1,0)

x1R

(1,1,1)

x 2R

(1,1,1)

(1,1,0)

(b)

an

If it is not the case, there exists 1 6 k 6 n and a sequence of states such that: a2

grdy 1

R 2

x0 −→ x1 −→ x2 . . . xn−1 −→ xn

a1

? State 0( x0R )

ak

x0 −→ x1 −→ x2 . . . xk−1 −→⊥ Such a path through an automaton is called the run of the automaton over the computation Γ. The set of all computations accepted by A will be denoted by L(A). The POMautomata of transmitters and receivers consist of four states and three states, respectively, as in Figure 4. In Figure 4(a), the state named state 0 (or xS0 ) corresponds to waiting for the receiver to be ready to synchronize (grdy = 0), state 1 (or xS1 ) corresponds to the enabled transmitter due to a ready signal from the receiver (grdy = 1), state 2 (or xS2 ) to acknowledgement of the synchronization

Figure 4. POM-automaton representations We now present an automata product that allows a modular description of a more complex process. Each subprocess can be modeled b an automaton and the model of the complete process can be obtained by computing the product of all sub-process automata.

4.4

POM-Automata Product

The processes S and R can be connected as in Figure 5. R Let S = (X S ; xS0 ; T S ) and R = (X R ; xR 0 ; T ) be the automata that model the processes S and R respectively. We define the product, S × R, of S and R to model the process obtained by linking S to R. We want to synchronize outputs

of S with inputs of R so that when a data transfer between S and R is possible then this transfer must happen. This leads to the following definition of the product of S and R, over the same event set A: S × R = (X, x0 , T )

S×R S

gn

=⊥

S×R x0 = ( x1S × x0R )

grdy 1

gack 0

gn z

x1 = ( x2S × x1R ) x2 = ( x3S × x2R )

1 1

1 1

0 1

(1,1,1)

x2

where: z∈{0,1}

Let us assume the input (output) width of S is equal to the output (input) width of R, so that these processes can be connected as in Figure 5. Each state in S × R is a pair consisting of a state from S and a state from R. The run of S × R over the accepted computation Γ = (1, 1, 0)(1, 1, 1) is denoted as below:

(1,0,z)

x0

(1,1,0)

x1

(1,1,1)

(1,1,0)

(1,1,1)

S R S R (xS1 , xR 0 ) −→ (x2 , x1 ) −→ (x3 , x2 )

(b)

This means that in the state (xS1 , xR 0 ) on event (1,1,0), the automaton S × R proceeds by executing S from xS1 and in parallel, executing R from xR 0 , and so on.

Figure 5. The connection of processes S and R and its POM-automaton

Equivalence of processes 0

0

Let A and A be two processes and A and A be their associated POM-automata. 0 0 A and A are equivalent ⇔ L(A) = L(A ) 0 In other words, the processes A and A are equivalent if they cannot be distinguished by their external behaviors.

4.6

?

(a)

Otherwise, we set

4.5

gn

gv grdy

S R T ((xSj , xR k ), a) = (xj+1 , xk+1 )

(1,1,0)

gv

!

where X = XS × XR x0 = xS0 × xR 0 T is defined in the following way: Let xi = (xSj , xR k ) be in X and a in A. If there exist S S R S S S xj+1 ∈ X and xR k+1 ∈ X such that T (xj , a) = xj+1 R R R and T (xk , a) = xk+1 , we set

T ((xSj , xR k ), a)

R

gack

The POM of each relation between states is considered as a property of the POM-automaton. Thus, a conjunction of the properties will result in the POM-automaton.

5

POM Semantics

A POM can be interpreted as a POM-automaton with set of events A and set of possible states X. Being in a state x, the POM-automaton executes some transitions over events to reach a successor state of x. Each possible computation of the POM corresponds to each run of the POM-automaton and the execution of the POM represents the set of POMautomaton runs. A POM-automaton in terms of a POM model is represented by the set of events A and the events occur at each state; i.e., the transition relation T . A more practical approach based on relations between states is that each POMautomaton is modeled as a set of relations between states and for each such relation we have a corresponding POM.

5.1

Verification Algorithm for the RTL Synthesis Results Steps of the algorithm

Our verification algorithm is shown diagrammatically in Figure 6. The steps of the algorithm will be considered in the subsections below.

5.2

Algorithmic behavioral specification

The algorithmic description is specified using an appropriate high-level language. A major task during this step is the realization of the different scheduling modes. In other words, a program is created in this step.

tions and essentially enable a dynamic selection.

Algorithmic behavioral specification

RTL

5.3 Create POMSPEC

Create POMSPEC automaton

Comparison

Create POMRTL automaton

Result

Figure 6. The verification algorithm the RTL synthesis results using a POM

In the VHDL example shown in the Figure 7, we have a process P with five events related to the statements of P, in which each statement is considered as an event.

P: process begin read(A,B); if (A>B) 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.