Component-Based Asynchronous Circuit Design in B

Component-Based Asynchronous Circuit Design in B J.Plosila University of Turku and Turku Centre for Computer Science (TUCS), FIN-20520 Turku, Finland

K. Sere ˚ Abo Akademi University and Turku Centre for Computer Science (TUCS), FIN-20520 Turku, Finland

M. Wald´en ˚ Abo Akademi University and Turku Centre for Computer Science (TUCS), FIN-20520 Turku, Finland Financing via the Academy of Finland

TUCS

Turku Centre for Computer Science TUCS Technical Report No 377 December 2000 ISBN 952-12-0755-8 ISSN 1239-1891

Abstract Action systems offer a component-based approach to circuit design. Component-based approaches are well established in hardware design, but are only recently more established in software design. However, software oriented methods allow a higher level of abstraction than the often quite low-level hardware design methods used today. We propose a method to organise a large circuit derivation within the B Method via its library facilities as provided by the tools. The developer proceeds from an abstract high-level specification of the intended behaviour of the target circuit via correctnesspreserving transformation steps towards an implementable circuit description. At each step some part of the specification is implemented using a library component chosen by the designer and the correctness of the step is proved using the tool support of the B Method. We develop the needed program transformation rules that the designer can appeal to when using library components in his or her design.

Keywords: Asynchronous circuits, the B Method, action systems, data refinement

TUCS Research Group Programming Methodology Research Group

1

Introduction

When carrying out formal specification and derivation of systems we can apply methods that allow a high-level abstract specification of a system to be stepwise developed into a more concrete version by correctness-preserving transformations. Hence, these methods provide a top-down approach to system design where the initial design is a very abstract view of the system to be built. Details about the intended functionality and hardware/software components of the system are stepwise added to the specification during the design while preserving the intended behaviour of the original design. While this approach is very appealing from the designer’s point of view as it allows the system to be developed and verified in manageable tasks, it still lacks e.g. good tool support. In this paper we concentrate on formal specification and derivation of systems within so called action systems. Action systems [2] and the associated refinement calculus [4], which provides a mathematical reasoning basis for the stepwise development of action systems, have shown their value in the design of reliable and correct systems in many ways [21]. The formal design methods supporting action systems and reasoning about them are heavily influenced by approaches to parallel and distributed program design as well as approaches to object-oriented programming [2, 8]. Recently, methods to derive systems from an abstract specification all the way down to VLSIchips within action systems have received considerable attention [16]. For instance asynchronous circuits, which provide interesting potential for modern wireless communication devices, can be designed within the framework. Utilisation of formal methods is particularly important when designing such complex VLSI chips, as it potentially reduces the design costs by eliminating errors and wrong design decisions at an early stage of the design process, before the chip has been fabricated. Plosila et al. [17] extended the action systems/refinement calculus framework to the development of asynchronous circuits in a stepwise manner from a high-level functional description of the circuit to its implementation. This work builds on the compilation method of Martin [13] which is a novel approach to formal design of asynchronous VLSI circuits. Both methods focus on a transformational style for the design: the circuit to be designed is first implemented as a concurrent program that fulfills the logical specification of the circuit. The program is then compiled, manually or automatically, into a circuit by applying correctness-preserving program transformations. Hence, the obtained circuit is logically correct by construction. The method has been successfully applied to the design of several non-trivial circuits [3, 18, 19]. Action systems, like many other similar formal methods, still lack good tool support or the methods and tools that are available have not been well integrated with the current engineering practice. An approach that has 1

been accepted by many industrial organisations is the B Method and its supporting tools [1, 14, 22]. The B Method, similarly to action systems, supports stepwise derivation of programs. Moreover, the B Method offers automatic proof-support for the verification of the correctness of each step as well as tools to manage and administrate a derivation task. However, the method is intended for the specification and design of software and focuses on conventional sequential programs. The action systems and the B Method have essentially the same structure, both are state-based systems as opposed to event-based process calculi, and both support the stepwise refinement paradigm to program construction. This gives a solid background for combining the two methods. Recently, Wald´en et al. [10, 23] have shown how action systems can be modelled with the B Method. Hence, the very well-developed and rich theory for action systems can utilise the mechanical tool support provided by the B Method. This link is not yet supported by the tools in all its details, but seems to be a promising solution to the problem at hand. Moreover, via action systems we can model parallel and distributed computations with the B Method. There are two mechanical tools that support the B Method and hence, can be used to develop action systems: Atelier B [22] developed by digilog and the B-Toolkit [14] developed by B-Core. In this paper we will further extend the applicability area of the B Method to provide support for formal circuit design. We explore the potentials of the tool support of the B Method enhanced with action systems in the circuit design flow focusing on asynchronous design and the most important, initial design steps in the design flow. Action systems offer a component-based approach to circuit design. Component-based approaches are well established in hardware design but are only recently more established in software design. However, the software oriented approaches allow a higher level of abstraction than the often quite low level hardware design methods used today. We propose a method to organise a large circuit derivation within the B Method via its library facilities as provided by the tools. We develop the needed program transformation rules that the designer can appeal to when using such library components in his or her design. The developer proceeds from an abstract high-level specification of the intended behaviour of the target circuit via correctness-preserving transformation steps towards an implementable circuit description. At each step a part of the specification is implemented using a library component chosen by the designer. The scheduling of actions in action systems and also in the B Method is non-deterministic by default. However, often and especially in circuit derivation one needs more specific and deterministic ways to schedule actions. For this purpose a set of high-level scheduling policies in terms of derived operators have been identified for action systems. In the B Method this problem turns out to be more complicated and the scheduling needs to be encoded in the actions. In this paper we show, however, how 2

a combination of a CSP-inspired event-based reasoning approach with the usual state-based reasoning supported by the method can be used to model alternative scheduling policies in a novel manner using the facilities of the B Method. We proceed as follows. We start in section 2 by describing a way to model parallel and distributed systems in the B Method using the action systems approach. We also propose a couple of derived B construct to handle the scheduling of actions and refinement. In section 3 we develop the component-based ideas needed in the design of asynchronous circuits in a quite high level of abstraction. A larger case study on component-based design is given in section 4. We end in section 5 with comparisons to related work and some concluding remarks. A small library of components is given in appendix A and the decomposition steps of the case study in section 4 are given in appendix B.

2

Asynchronous Circuits in B

Action systems have been used for top-down circuit design in a stepwise manner from a high-level functional description of the circuit to its implementation [17]. At each refinement step a correctness-preserving transformation accompanied with a number of proof obligations is applied. In order to give more confidence in the correctness proof of a refinement step in this design we want to use a mechanical tool. The Atelier B [22] and the BToolkit [14] provide this kind of tool. They both comprise a set of tools which support the software development method the B Method [1]. The action systems and the B Method have essentially the same structure, both are state-based systems as opposed to event-based process calculi, and both support the stepwise refinement paradigm to program construction. This gives a solid background for combining the two methods. The B Method is a mathematical method which gives a model oriented approach to software construction. The method is based on set theory and relies on an extension of the weakest precondition calculus. A program derivation in the B Method consists of a high-level specification, possibly a number of refinements and an implementation. The specification, the refinements and the implementation are all represented as abstract machines consisting of state variables and of operations on these variables. During the program derivation the user supplies the tool, the Atelier B or the B-Toolkit, with the specification and a number of refinements of this specification. The verification conditions, the proof obligations, needed for proving the consistency of the specification and the correctness of the refinement steps can be automatically generated. Furthermore, these verification conditions can be automatically or interactively proved using the so called autoprover or interprover, respectively. Hence, by using the B Method for 3

designing circuits we will have tool support with proving facilities for correct design.

2.1

Modelling Asynchronous Circuits

We model asynchronous circuits via so called abstract machines. The main components of an abstract machine are the state variables, the operations on the state variables and the invariant giving the properties of these variables. For specifying the operations we use substitutions, for example, skip-substitution, simple substitution (x := e), multiple substitution (x := e || y := f ), action (also called guarded substitution) (SELECT P THEN S END), or non-deterministic substitution (ANY x WHERE P THEN S END), where x and y are variables, e and f are expressions, P is a predicate, and S is a substitution. Each substitution S is defined as a predicate transformer which transforms a postcondition Q into the weakest precondition for S to establish Q, wp(S, Q) [11], the initial states from which S is guaranteed to terminate. The substitutions above are defined as follows: wp(skip, Q) wp(x := e, Q) wp(x := e || y := f, Q) wp(SELECT P THEN S END, Q) wp(ANY x WHERE P THEN S END, Q)

= = = =

Q Q[x := e] Q[x, y := e, f ] P ⇒ wp(S, Q)

=

∀x.P ⇒ wp(S, Q)

The abstract machine A given below MACHINE A VARIABLES x INVARIANT I(x) INITIALISATION x := x0 OPERATIONS A1 = ˆ SELECT P1 THEN S1 END; . . . Am = ˆ SELECT Pm THEN Sm END END

where every operation in the operations-clause is an action, is called an action system. An action system is identified by a unique name, here A. The variable(s) x of the action system are given in the variables-clause. The invariant I(x) in the invariant-clause gives invariance properties for the variables. The variables are assigned initial values in the initialisationclause. In the operations-clause each action Ai is given as a named operation. Each operation might have value parameters and/or return a result. An action A with the value parameter a and the result parameter b is denoted 4

b ← A(a). This feature is used later to model communication in the form of message-passing between action systems. Action systems are used as a model for parallel and distributed systems [2, 23] with the basic idea that actions are selected for execution in a non-deterministic way. Only actions that are enabled, i.e., when the predicate P holds for the action in a given state, are considered for execution. The execution terminates when there are no enabled actions. If two action do not share any variables, they can be executed in any order or in parallel. Hence, we have an interleaving semantics for action systems. As asynchronous circuits form a sub-class of action systems [17] we can use the above also for this purpose. In the following example we have a high-level action system specification of a simple asynchronous circuit unit which computes a new value for data dout whenever the action E is selected for execution. Asynchronous behavior is modeled by using the parameters l and r as two-directional communication signals between the system E and its environment. In other words, when E assigns a value to l or r, the environment eventually responds by assigning another value, and vice versa. The values l and r can be assigned are req and ack. MACHINE E DEFINITIONS F (· · ·) == . . . OPERATIONS l, r, dout ← E(l, din, r, dout) = ˆ SELECT l = req ∧ r = ack THEN ANY dout′ WHERE F (dout′ , din, dout) THEN dout := dout′ END || r := req || l := ack END END

Scheduling of actions Implicitely there is a nondeterministic choice between enabled actions in the operations-clause as explained above. This can be explicitely given in a scheduling-clause of an action system. In this clause we can also state other more specific scheduling policies like sequential composition or some prioritised or probabilistic composition between actions. The clause is optional, but in case a scheduling-clause appears in an action system, all the actions of the machine must be included. The scheduling has the same name as the abstract machine. If the actions have parameters, these will also be parameters of the scheduling MACHINE A . . . SCHEDULING A= ˆ A1 * . . . * Am END

5

In this paper we focus on two composition operators between actions and consider each occurrence of * to be either a sequential composition, ;, or nondeterministic choice, []. For example, let the action system A have three actions A1 , A2 and A3 . ˆ ((A1 ; A2 ) [] A3 ), restricts the exeThen the scheduling clause of A, A = cution of the system so that A1 and A2 always are executed in a sequence interleaved with A3 . The scheduling A(b, c, d) = ˆ A1 ; A2 denotes a sequential execution order between the two actions A1 (b) and d ← A2 (c) with associated value and result parameters b, c and d, respectively. In the machine Reg below the operations Reg1 and Reg2 are sequentially composed. MACHINE Reg OPERATIONS b, dout ← Reg1 (a, din) = ˆ SELECT a = req THEN dout := din || b := req END; a ← Reg2 (b) = ˆ SELECT b = ack THEN a := ack END SCHEDULING Reg(a, din, b, dout) = Reg1 ; Reg2 END

Parallel composition Action systems can be composed into parallel systems [5]. The parallel composition of the action systems A and B can be presented in the B Method using the extends-clause. MACHINE B VARIABLES y INVARIANT J(y) INITIALISATION y := y0 OPERATIONS B = ˆ SELECT Q THEN T END SCHEDULING B= ˆ B END

MACHINE A EXTENDS B VARIABLES x INVARIANT I(x) INITIALISATION x := x0 OPERATIONS A = ˆ SELECT P THEN S END SCHEDULING A= ˆ A [] B END

Here the action system A includes the system B by the extends-clause indicating that A is considered to be composed in parallel with B. The scheduling of A is then (A1 * A2 ) [] (B1 * B2 ). Hence, actions from the two component systems are executed in an interleaving manner. This also gives us our model of parallelism: when two action are simultaneously enabled and they do not refer to the same variables they can also be executed simultaneously by an implementation. As an example of a parallel composition let us consider an action system E 1 composed in parallel with the previously given system Reg. The scheduling of E 1 is then ((E11 ; E13 ) [] E12 ) [] (Reg1 ; Reg2 ). 6

MACHINE E 1 SETS data, com PROPERTIES com = {req, ack} EXTENDS Reg VARIABLES c1 , c2 , dm INVARIANT c1 ∈ com ∧ c2 ∈ com ∧ dm ∈ data DEFINITIONS F (· · ·) == . . . INITIALISATION c1 := ack || c2 := ack || dm :∈ data OPERATIONS E11 (l, din, dout) = ˆ SELECT l = req ∧ r = ack THEN ANY dm′ WHERE F (dm′ , din, dout) THEN dm := dm′ END || c1 := req END; r ← E12 = ˆ

SELECT c2 = req THEN c2 := ack || r := req END;

l ← E13 = ˆ SELECT c1 = ack THEN l := ack END SCHEDULING E 1 (l, din, r, dout) = ˆ (E11 ; E13 ) [] E12 [] Reg(c1 , dm, c2 , dout) END

2.2

Abstract Machine Refinement

Abstract machines usually contain abstract data structures that are not directly implementable in a programming language. A refinement in the B Method may either be a data refinement or an algorithmic refinement. The data refinement is achieved by changing the local variables of the abstract machine with concrete variables that are more easily implemented as well as changing the operations on the variables. The algorithmic refinement, on the other hand, allows the operations to be reformulated, thereby, making them more concrete without changing the state space. The refinement relation is transitive and monotonic. Let us consider the action system A and its refinement A′ . 7

REFINEMENT A′ REFINES A VARIABLES x′ INVARIANT R(x, x′ ) INITIALISATION x′ := x′0 OPERATIONS ˆ SELECT P1′ THEN S1′ END; A′1 = .. . ′ END ˆ SELECT Pn′ THEN Sn A′n = SCHEDULING A′ = ˆ A′1 * . . . * A′n END

MACHINE A VARIABLES x INVARIANT I(x) INITIALISATION x := x0 OPERATIONS A1 = ˆ SELECT P1 THEN S1 END; .. . Am = ˆ SELECT Pm THEN Sm END SCHEDULING A= ˆ A1 * . . . * Am END

The machine refinement states in the refines-clause what it refines, an abstract machine or another machine refinement. Above the refinement A′ refines the abstract machine A. The invariant R(x, x′ ) of the refinement gives the relation between the variable(s) x in the action system A and the variable(s) x′ in its refinement A′ for replacing abstract statements with more concrete ones. For asynchronous circuit design we only add variables during the refinement process. This means that the variable(s) x′ in A′ actually can be given as x, y and the invariant as R(x, y), where the variable(s) x are the same in A and A′ and y are the new variables in A′ . The refined actions A′i are given in the operations-clause and the scheduling-clause indicates how these actions are composed. In order to prove that the refinement A′ on the variables x′ is a refinement of the action system A on the variables x using the invariant R(x, x′ ), a number of proof obligations must be satisfied [1]. The invariant R of the refinement should not contradict the invariant I of the specification. (∃(x, x′ ). I ∧ R)

(1)

Furthermore, the initialisation x′ := x′0 in A′ establishes a situation where the initialisation x := x0 in A cannot fail to establish the invariant R. wp(x′ := x′0 , ¬wp(x := x0 , ¬R))

(2)

Moreover, we need to prove that the actions in A are data refined by the actions in A′ . In case each action Ai in A corresponds to an action A′i in A′ , (n = m), the action Ai is data refined by A′i under invariant R. Hence, it should be proven for each pair of actions Ai and A′i (i = 1, . . . , m) that the action A′i establishes a situation where Ai cannot fail to maintain R. (∀(x, x′ ). I ∧ R ⇒ wp(A′i , ¬wp(Ai , ¬R)))

(3)

In this case the scheduling of the actions should be the same in A and A′ , i.e. if A = ˆ A1 [] A2 then A′ = ˆ A′1 [] A′2 . 8

In circuit design we often rely on atomicity refinement and, therefore, need to introduce new actions during the refinement process. In case we introduce new actions in A′ , (n > m), we have the case that an action in A is refined by more than one action in A′ . Hence, we explicitely need to indicate which actions of A′ refine each action of A. This can be given in a mappings-clause in A′ as follows. MAPPINGS ... Ai ≤ A′i ∗ . . . ∗ A′j , ...

where 1 ≤ i ≤ m and 1 ≤ j ≤ n and each* stands for [] or ; depending on how the actions A′i , . . . , A′j of A′ are composed within the schedulingclause. However, since we use sequential composition of actions, we might not always be able to refine each action separately in A by some actions in A′ . Hence, also a composition of actions in A could be refined by a composition of actions in A′ . MAPPINGS ... Ai ∗ . . . ∗ Ak ≤ A′i ∗ . . . ∗ A′j , ...

where 1 ≤ i, k ≤ m and 1 ≤ j ≤ n and each * is [] or ; depending on how the corresponding actions in A and A′ are composed. Each action of A and A′ should appear once in the mappings-clause. If we denote the composed actions Ai ∗ . . . ∗ Ak as Ci and A′i ∗ . . . ∗ A′j as Di , we can write the proof obligation for refinement using composed actions as (∀(x, x′ ). I ∧ R ⇒ wp(Di , ¬wp(Ci , ¬R))),

(4)

for each entry Ci ≤ Di in the mappings-clause. Hence, for each composed action Ci of A the composed actions Di of A′ should establish such a situation that Ci cannot fail to maintain R. We can note that in case the refined action system A′ is composed in parallel with another action system B and B contains the scheduling B = ˆ B1 ; B2 , then either B, or both B1 and B2 should appear within the composed actions Ci in the mappings-clause of A′ . If action A1 in A is refined by (A′1 [] B) in A′ then we actually consider A1 to be refined by A′1 and the composition of all the actions in B, A1 ≤ (A′1 [] (B1 ; B2 )). Studying the examples given previously in this section we can note that the action system E 1 composed in parallel with Reg is actually a refinement of the action system E. Since E has fewer actions than E 1 , the refinement of the actions is given in the mappings-clause as follows. 9

REFINEMENT E 1 REFINES E EXTENDS Reg VARIABLES . .. SCHEDULING E1 = ˆ (E11 ; E13 ) [] E12 [] Reg(c1 , dm, c2 , dout) MAPPINGS E1 ≤ ((E11 ; E13 ) [] E12 [] Reg(c1 , c2 , dm, dout)) END

The proof obligations (1), (2) and (3) can be generated automatically and checked using the theorem-proving environments associated with the B Method [1, 14]. See Wald´en and Sere [23] for further details on refining action systems within B. The mappings-clause makes an automatic generation also of proof obligation (4) possible. We can observe that the parallel composition of action systems is monotonic with respect to refinement. Thus, if action system A is refined by A′ and action system B is refined by B ′ , then the parallel composition of A and B is refined by the parallel composition of A′ and B ′ . This means that the subsystems in a parallel composition may be refined independently.

3

Component-based design

Top-down circuit design starts from a high-level action system specification of the basic functionality of the target circuit. The initial specification is decomposed, within the refinement calculus framework, into a number of manageable action system components each of which models a functional unit of the final circuit. Such a unit could be, for example, an arithmeticlogical unit, an interface module, a memory block, or a controller of a set of other units. The decomposition procedure is then completed by splitting the obtained functional units further into compositions of pre-defined action systems representing library components available to the designer. The component-based approach speeds up the design flow, because the predefined action system components have fixed circuit realizations, and hence the actual implementation of the system is obvious after the extraction of the components. At the lowest abstraction level, these components are digital gates and memory elements that are constructed from physical transistors. In general, a library component can be arbitrarily complex. For instance, a modern system-on-chip design may consist of very large pre-defined modules, such as microprocessor cores. Here, however, we study the componentbased design approach in terms of simple action system modules which have specific communication channel interfaces and are meant for design of asynchronous (self-timed) sequential circuits. These building blocks are called 10

handshake components [6] each of which is a pre-defined action system that carries out a specific pattern of communication cycles on a set of communication channels. A circuit specification built out of handshake components, i.e., a handshake circuit, corresponds to a parallel composition of these simple action system components. Naturally, when splitting a system specification into a network of fixed library components, the designer is not completely free in his or her decisions, but the implementation is restricted by the contents of the applied component library. The design process proposed here is based on mapping action systems against pre-defined asynchronous handshake components. When a suitable library component is identified the action system specification is decomposed by introducing the needed communication channels which instantiate the library component.

3.1

Asynchronous communication channels

In the asynchronous design approach, interaction between two subsystems of a parallel composition is arranged via an asynchronous communication channel composed of the value and result parameters of the actions. In our design framework, a communication channel c(d), or a channel c in short, is defined to be a tuple (c, d), where c is a communication variable and d the list of those data variables whose values are transfered from a system unit to another by communicating via c. If the list d is empty, c is called a control channel . Otherwise we have a data channel c(d). Furthermore, when refering to a single party of communication, we talk about communication ports rather than channels. Generally, a communication variable c is of the enumerated type comm,n defined by comm,n = b (req1 , . . . , reqm , ack1 , . . . , ackn ) where req1 , . . . , reqm and ack1 , . . . , ackn are request and acknowledgement states (values), respectively. A variable c ∈ comm,n is initialized to one of its acknowledgement states ackj . The sets of the request and acknowledgement states of c are denoted by REQm and ACKn : REQm = b {req1 , . . . , reqm } ACKn = b {ack1 , . . . , ackn } If m = 1 or n = 1, the default value is just req or ack, respectively. Hence, the simplest and the most usual type com1,1 is equivalent to (req, ack) by default. We often denote com1,1 simply by com. A communication channel connects two action system components, one of which acts as the master and the other as the server . The master side of a channel is called an active communication port, and the server side is 11

referred to as a passive communication port. A communication cycle on a channel c(d) includes two main phases. When the active party, the master, initiates the cycle by setting c to a request state reqi , the cycle is said to be in the request phase. Correspondingly, when the passive party, the server, responds by setting c to an acknowledgement state ackj , the communication cycle on c is said to be in the acknowledgement phase. The data d can be transfered either in the request phase from the master to the server (push channel ), in the acknowledgement phase from the server to the master (pull channel ), or in both phases bidirectionally (biput channel ) [15]. As an example, the above machines E 1 and Reg communicate via the push channels c1 (dm) ∈ com and c2 (dout) ∈ com. When the system E 1 transfers data dm to Reg by setting c1 to the request state req, it acts as the master towards the machine Reg which sets c1 to the acknowledgement state ack as a response. On the other hand, when data dout is transferred from Reg to E 1 via the channel c2 , the system Reg is the active party and E 1 acts as the server.

3.2

Decomposition step

The decomposition process is based on introducing communication channels into the system. Each decomposition step creates at least one channel through which the extracted components interact. Let us sketch a tranformation rule that given an action system specification, a library component and an action that we want to implement with this component decomposes the specification. We study here a general case, more specific applications of the transformation are discussed in the following section. Moreover, more specific transformation rules can be derived for each particular case. Consider an action system C, which contains an atomic action C defined as follows: MACHINE C .. . OPERATIONS C = ˆ SELECT P THEN A(d); B(d) END; . . . SCHEDULING C = ˆ C ... END

Here A and B are actions sharing a data variable d. Let us assume that we want to decompose the system C into a parallel composition of two systems C and M such that the action A belongs to C and the action B is implemented by the library component M, respectively. Let the library module be 12

MACHINE M .. . OPERATIONS m ← M od(m, d) = ˆ SCHEDULING M(m, d) = ˆ M od END

SELECT m = req THEN B(d) || m := ack END;

The library module has a passive communication port as m = req appears in the guard of the operation. Hence, it behaves as a slave towards C and puts the corresponding communication cycle in its acknowledgement phase. In order to implement an active communication port in C, we introduce a fresh communication variable c(d) : com, initialized to ack, and refine the action system C into a parallel composition of C ′ below and M. REFINEMENT C ′ REFINES C EXTENDS M . .. OPERATIONS C ′′ = ˆ SELECT P ∧ c = ack THEN A(d) || c := req END; .. . SCHEDULING C′ = ˆ (C ′′ . . .) [] M(c, d) MAPPINGS C ≤ C ′′ [] M(c, d) END

Let us study the new system C ′ . Upon executing the action C ′′ it initiates a communication cycle on c(d) by turning c to req. Hence, it puts the cycle in its request phase. Thereafter the library component takes over the cycle. There are no changes in the action schedules. In order to show the correctness of the transformation as a refinement step we need to verify the proof obligations (1)-(4) from the previous section. For this we need to find a suitable invariant R which is application dependent. Let us here, however, give an intuitive justification for the step. When starting from the specification C our first task is to introduce the communication channel c. Hence, the action C is transformed into the action C′ = ˆ

SELECT P ∧ c = ack THEN A(d) || c := req WHEN c = req THEN B(d) || c := ack END

Secondly, the action C ′ is split within the refinement calculus into the choice of two separate atomic actions C ′′ and B ′ : C ′′ = ˆ B′ = ˆ

SELECT P ∧ c = ack THEN A(d) || c := req END SELECT c = req THEN B(d) || c := ack END

13

Here the action C ′ is replaced with two distinct actions. Hence, the transformation is correct provided we can show the correctness of refining C into C ′′ [] B ′ as required by the proof obligation (4). The invariant used in the proof is as before. Finally, the resulting system is partitioned into the parallel composition of C ′ containing the action C ′′ and a system containing the action B ′ . In this way we can for instance add the newly created system into our library and re-use it from there. However, in order for the existing library component M to implement B ′ and c we need to have that C is refined by C ′′ [] M(c, d) as given in the mappings-clause of the system C ′ . Note that the above example demonstrates the simplest possible decomposition step, where the procedure splits only one action of C, and the library component M consists of a single action. In general, the extraction of a component may involve several actions of the system C. Furthermore, the communication variable c may have more values than the two (req, ack) needed above, and the decomposition operation can require several distinct communication variables rather than just one, and maybe a number of fresh data variables as well. Consequently, a set of transformation rules has to be sketched in order to cover all the basic cases.

3.3

Handshake components

Let us now specify a small library of handshake components in a B Method library. The handshake components can be divided into two main classes: control path and data path components. A control path component is an action system which does not write onto data variables. Furthermore, a component which does not even read data variables is called a pure control path component, while one that reads data variables is refered to as a mixed (control path) component. Whenever a component writes onto data variables, it is called a data path component. We specify below the handshake components needed in the case study presented in Section 4. Of these Seq4 , If2 , Conv1,1→1 , and R are pure control path components, Susp is a mixed component, and Func, Mux2 , and Reg are data path components. The component Reg is given below. The rest of the components can be found in Appendix A. The register component Reg implements the copying assignment dout := din It is used as an intermediate temporary data storage and it has only one passive communication port a(din, dout). The input data din arrives in the request phase of the cycle on a and is copied to the output dout. The output data dout, in turn, is considered valid whenever a is in the acknowledgement state. 14

MACHINE Reg SEES Channel Data OPERATIONS a, dout ← Reg1 (a, din) = ˆ SCHEDULING Reg(a, din, dout) = Reg1 END

SELECT a = req THEN dout := din || a := ack END

The seen machine Channel Data contains the channel types needed for the components presented in this paper. MACHINE Channel Data SETS data, com, com1,2 , com2,1 , ACK2 PROPERTIES com = {req, ack} ∧ com1,2 = {req, ack1 , ack2 } ∧ com2,1 = {req1 , req2 , ack} ∧ ACK2 = {ack1 , ack2 } END

4

Extracting components

As an example, consider the composition of the action systems A and PA where the system A is given as MACHINE A SEES Channel Data DEFINITIONS F1 (a, b, c) == . . . ; F2 (d, e, f ) == . . . OPERATIONS m ← A1 (l) = ˆ SELECT l = req THEN m := req END; l, r, dout ← A2 (m, din, r, dout) = ˆ SELECT r = ack THEN SELECT m = ack1 THEN ANY dout′ WHERE F1 (dout′ , dout, din) THEN dout := dout′ END WHEN m = ack2 THEN ANY dout′ WHERE F2 (dout′ , dout, din) THEN dout := dout′ END END || r := req || l := ack END SCHEDULING A(l, din, m, r, dout) = ˆ A1 ; A2 END

and its abstract environment or protocol system PA [16] is given as 15

MACHINE PA SEES Channel Data EXTENDS A VARIABLES l, r, m, din, dout, x INVARIANT l ∈ com ∧ r ∈ com ∧ m ∈ com1,2 ∧ din ∈ data ∧ dout ∈ data ∧ x ∈ data INITIALISATION l := ack || r := ack || m :∈ ACK2 || din :∈ data || dout :∈ data || x :∈ data OPERATIONS P1 = ˆ SELECT l = ack THEN l := req END, P2 = ˆ

SELECT m = req THEN m :∈ {ack1 , ack2 } || din :∈ data END;

P3 = ˆ SELECT r = req THEN x := dout || r := ack END SCHEDULING PA = ˆ P1 [] P2 [] P3 [] A(l, din, m, r, dout) END

Here the machine A is the circuit specification we want to implement with a set of pre-defined handshake components. The machine PA , in turn, models the responses of the environment in which the circuit modeled by A is assumed to operate. A has one passive port l and two active ports: the input m(din) and the output r(dout). The behavior of the composition is the following. First, the environment activates the machine A by setting the control channel l to the request state req. Then A sends a request through the pull channel m and awaits an acknowledgement and data input din from the environment. When PA has assigned din a new value and set m to an acknowledgement state acki , where i ∈ {1, 2}, the machine A computes a new value for the data output dout using the relation Fi . Observe that the alternative relations F1 and F2 are not specified in this generic example. The data dout is sent to the environment via the push channel r by setting r to the request state. Simultaneously, an acknowledgement is issued through the control channel l. This indicates that the environment PA may reactivate the machine A via l, but a new communication cycle on m is blocked by A until the environment has stored the sent value of dout and issued an acknowledgement through r. The abstract machine A is decomposed stepwise into a construct of 9 handshake components. The library components needed in this specific case study are introduced in Section 3 and in Appendix A. We show below the details of the first decomposition step only — the other steps are presented in Appendix B. Extraction of a register component The decomposition process of A is started by extracting a register component Reg for the output data variable dout following the approach given in Section 3. The need for this particular 16

device is obvious, as the predicates F1 and F2 in the operation A2 of the machine A refer also to the variable dout itself. In other words, the next value of dout depends on the current value of dout. This means that a storage element, a register, is needed for the variable at the circuit level. As the result of the decomposition step we obtain the machine A1 which is a refinement of the original abstract machine A. The new system is defined by REFINEMENT A1 REFINES A SEES Channel Data EXTENDS Reg VARIABLES c1 , dm INVARIANT c1 ∈ com ∧ dm ∈ data DEFINITIONS F1 (. . .) == . . . ; F2 (. . .) == . . . INITIALISATION c1 := ack || dm :∈ data OPERATIONS m ← A11 (l) = ˆ SELECT l = req THEN m := req END; A12 (m, din, r, dout)

= ˆ

SELECT r = ack THEN SELECT m = ack1 THEN ANY dm′ WHERE F1 (dm′ , dout, din) THEN dm := dm′ END WHEN m = ack2 THEN ANY dm′ WHERE F2 (dm′ , dout, din) THEN dm := dm′ END END || c1 := req END;

l, r ← A13 = ˆ SELECT c1 = ack THEN r := req || l := ack END SCHEDULING A1 (l, din, m, r, dout) = ˆ (A11 ; A12 ; A13 ) [] Reg(c1 , dm, dout) MAPPINGS A1 ≤ A11 , A2 ≤ ((A12 ; A13 ) [] Reg(c1 , dm, dout)) END

Hence, the extraction procedure splits the operation A2 of A into three separate parts, one of which belongs to the extracted register component Reg and the others (A12 , A13 ) to the refined machine A1 shown above. For this, we have introduced a fresh communication variable c1 : com through which A1 and Reg communicate. Furthermore, the refinement step includes the introduction of the intermediate data variable dm which acts as the data input of the extracted register component, so that Reg performs the copying 17

assignment dout := dm. The machine A1 activates Reg by computing a new value for the data variable dm and setting the channel c1 to the request state in the operation A12 . Then A1 awaits an acknowledgement from the register component and executes finally the operation A13 , where the channels r and l are set to the request and acknowledgement states, respectively. Final system The decomposition process continues similarly. For example, the choice of two assignments to the data variable dm in the machine A1 indicates that a selection composer If2 and a multiplexer component Mux2 are to be extracted. On the other hand, the presence of the two data assignments means that two function components Func are needed as well. Furthermore, as the communication cycles on the channels l and r can proceed partly in parallel, a pipelining component R (“R-element”) and a related suspend component Susp are introduced. The order in which the components are extracted is not fixed, but the same result can be obtained through several paths. Every refinement step creates at least one new communication channel, so that finally the system consists of nine handshake components which interact via nine communication channels c1 , . . . , c9 . The last extraction procedure is an exception, because the operations of the final abstract machine A5 match directly the operations of a 4-channel sequencer Seq4 , and hence new channels are not created. The resulting system A6 is REFINEMENT A6 REFINES A5 SEES Channel Data, Bool T Y P E EXTENDS Reg, Mux2 , Conv1,1←1 , F unc, If2 , R, Susp, Seq4 VARIABLES c1 , c2 , c3 , c4 , c5 , c6 , c7 , c8 , c9 , dm, dm1 , dm2 , bsy DEFINITIONS F1 (. . .) == . . . ; F2 (. . .) == . . . INITIALISATION c1 := ack || c2 := ack || c3 := ack || c4 := ack || c5 := ack || c6 := ack ||c7 := ack || c8 := ack || c9 := ack || dm :∈ data || dm1 :∈ data || dm2 :∈ data || bsy := f alse SCHEDULING A6 (l, din, m, r, dout) = ˆ Reg(c1 , dm, dout) [] Mux2 (c2 , dm1 , dm2 , dm) [] Conv1,1→1 (c3 , c4 , c2 ) [] F unc(c5 , c3 , < din, dout >, dm1 , F1 (. . .)) [] F unc(c6 , c4 , < din, dout >, dm2 , F2 (. . .)) [] If2 (c7 , m, c5 , c6 ) [] Susp(c9 , bsy, ¬(. . .)) [] R(c8 , r, bsy) [] Seq4 (l, c7 , c9 , c1 , c8 ) MAPPINGS (A51 ; A52 ; A53 ; A54 ; A55 ) ≤ Seq4 (l, c7 , c9 , c1 , c8 ) END

The fact that A6 does not contain any operations of its own, but they all come from the handshake components, indicates that the extraction process has been completed. 18

5

Conclusions

We have proposed an approach to component-based asynchronous circuit design within the B Method and its supporting tools. We have used the method almost as such with minor extensions mainly needed to specify alternative scheduling strategies for actions in a scheduling-clause and explicitely giving refinement relations in the mappings-clause. The first clause is mainly syntactic suggering as every scheduling could be coded in the actions of the operations-clause. The second clause is a real extension, but also it can be easily supported by the tools. The scheduling-clause is inspired by the work of Butler [9] who studies a more general process-concept for the B Method to tie it together with the CSP-approach. The Refinement Calculator [24] is a tool that supports development of correct programs within the refinement calculus framework. It is a tool for program refinement based on the HOL theorem prover. Until now, the tool does not have proper support for action systems. However, a method to prove the correctness of the implementations of handshake components has been mechanized within the HOL theorem prover [20] which supports more general verification techniques than the tools studied in this paper. In the future we can envisage a situation where the verification of the low level implementations are carried out within HOL and the high-level design and component libraries are supported by the tools of the B Method. The idea of handshake components comes from Tangram [7], a CSPbased [12] programming language for asynchronous VLSI design. A Tangram specification is compiled automatically into a so called handshake circuit which is a network of primitive communicating processes, namely handshake components. To our knowledge, the Tangram framework contains currently about 30 different handshake components. In [16] the action system specifications of the most essential handshake components needed in our design methodology are presented. This library consists of 29 distinct components. It is important to notice, however, that even though our approach is inspired by Tangram and the idea of handshake circuits, the components and their usage in our method differ from the original Tangram components and their usage. This is because the action systems is a statebased formalism in which communication channels are modeled by shared variables, while Tangram uses event-based modeling with a genuine channel concept.

Acknowledgement We would like to thank Minna Simola who assisted us in writing the example in B format. 19

A

Handshake components • The 4-channel sequencer Seq4 implements a sequential composition of four communication cycles. First it receives a request through the passive port a. Then it performs sequentially communication cycles on the active ports b1 , . . . , b4 starting from b1 , after which it completes the cycle on a by sending an acknowledgement. MACHINE Seq4 SEES Channel Data OPERATIONS b1 ← Seq1 (a) = ˆ SELECT a = req THEN b1 := req END; b2 ← Seq2 (b1 ) = ˆ SELECT b1 = ack THEN b2 := req END; b3 ← Seq3 (b2 ) = ˆ SELECT b2 = ack THEN b3 := req END; b4 ← Seq4 (b3 ) = ˆ SELECT b3 = ack THEN b4 := req END; a ← Seq5 (b4 ) = ˆ SELECT b4 = ack THEN a := ack END SCHEDULING Seq4 (a, b1 , b2 , b3 , b4 ) = Seq1 ; Seq2 ; Seq3 ; Seq4 ; Seq5 END

• The selection composer If2 implements a deterministic choice between two communication cycles. First it awaits a request on the passive port a and then sends a request through the active port b which has two possible acknowledgement values. When the acknowledgement acki (i = 1, 2) is received through b, a communication cycle on the active port ci is performed. After this an acknowledgement is issued through a.

MACHINE If2 SEES Channel Data OPERATIONS b ← If1 (a) = ˆ SELECT a = req THEN b := req END; c1 ← If2 (b) = ˆ SELECT b = ack1 THEN c1 := req END; c2 ← If3 (b) = ˆ SELECT b = ack2 THEN c2 := req END; a ← If4 (c1 , c2 ) = ˆ SELECT c1 = ack ∧ c2 = ack THEN a := ack END SCHEDULING If2 (a, b, c1 , c2 ) = If1 ; (If2 [] If3 ) ; If4 END

• The channel converter Conv1,1→1 is a device that transforms its two passive ports a1 and a2 of the type com into the single active port b of the type com2,1 , where the request states req1 and req2 correspond to the request states of a1 and a2 , respectively. The communication cycles on the passive ports are assumed to be mutually exclusive, enforced by the environment. 20

MACHINE Conv1,1→1 SEES Channel Data OPERATIONS b ← Conv1 (a1 ) = ˆ SELECT a1 = req THEN b := req1 END; a1 ← Conv2 (b) = ˆ SELECT b = ack THEN a1 := ack END; b ← Conv3 (a2 ) = ˆ SELECT a2 = req THEN b := req2 END; a2 ← Conv4 (b) = ˆ SELECT b = ack THEN a2 := ack END SCHEDULING Conv1,1→1 (a1 , a2 , b) = (Conv1 ; Conv2 ) [] (Conv3 ; Conv4 ) END

• The release (R) element R awaits first a request on the passive port a and initiates then a communication cycle on the active port b issuing a fast acknowledgement through a. This releases the systems connected to the ports a and b to operate in parallel. Hence, the R element is an important building block in pipeline designs. Note that an auxiliary boolean status signal bsy (‘busy’) is introduced. MACHINE R SEES Channel Data, Bool T Y P E OPERATIONS b, bsy ← R1 (a) = ˆ SELECT a = req THEN b, bsy := req, true END; a ← R2 (bsy) = ˆ SELECT bsy = true THEN a := ack END; bsy ← R3 (b) = ˆ SELECT b = ack THEN bsy := false END SCHEDULING R(a, b, bsy) = R1 ; R2 ; R3 END

The environment is required to postpone the reactivation of a cycle on a until the status signal bsy has become false, i.e., the environment must satisfy the protocol ((apre = ack) ∧ (apost = req)) ⇒ (¬bsy pre ∧ ¬bsy post ) This condition is often met with the help of the suspend component Susp introduced next. • The suspend component Susp awaits, after receiving a request through the passive port a, a boolean condition P (din) to become true. When this happens, an acknowledgement is sent through a. MACHINE Susp SEES Channel Data OPERATIONS a ← Susp1 (a, din) = ˆ SELECT a = req ∧ P (din) THEN a := ack END SCHEDULING Susp(a, din, P (e)) = Susp1 END

21

This component operates correctly, if the action Susp1 in the above description excludes any action B (in the environment) that falsifies the predicate P , or: ∀B.((P ⇒ wp(B, ¬P )) ⇒ (Susp1 excludes B)) • The function component Func implements a data assignment ANY dout′ WHERE F (dout′ , din) THEN dout := dout′ END

where dout is the data output of the component, and F is a relation between dout′ and the data input din. We require that din and dout are distinct (lists of) variables. The function component specified below has a passive input port a(din) through which the input data din arrives, and an active output port b(dout) through which the result data dout is sent out. MACHINE F unc SEES Channel Data OPERATIONS b, dout ← F unc1 (a, din) = ˆ

SELECT a = req THEN ANY dout′ WHERE F (dout′ , din) THEN dout := dout′ END || b := req END; SELECT b = ack THEN a := ack END

a ← F unc2 (b) = ˆ SCHEDULING F unc(a, b, din, dout, F (e, f ) = F unc1 ; F unc2 END

• The multiplexer Mux2 implements a deterministic choice between two copying assignments to the data variable dout. In other words, it passes one of its data inputs dini , i = 1, 2, to the output dout. The selection is based on the request state of the port a, i.e., a = reqi indicates that the input data dini is passed. Observe that the multiplexer version presented below has, unlike the above function component, only a passive communication port a(din, dout) through which the input and output data is transfered (biput port). The input data arrives in the request phase of the communication cycle, and the output data is transmitted in the acknowledgement phase of the cycle. The variables dini and dout must be distinct. 22

MACHINE Mux2 SEES Channel Data OPERATIONS a, dout ← M ux1 (a, din1 ) = ˆ

a, dout ← M ux2 (a, din2 ) = ˆ

SELECT a = req1 THEN dout := din1 || a′ := ack END; SELECT a = req2 THEN dout := din2 || a′ := ack END

SCHEDULING Mux2 (a, din1 , din2 , dout) = M ux1 [] M ux2 END

23

B

Decomposition steps

Increasing parallelism After extracting the register component we postpone the detection of the acknowledgement on the channel r by splitting the operation A12 of A1 into two separate parts A22 and A23 . The transformation makes the computation of the function F1 or F2 , i.e., the action A22 , potentially parallel with the transmission of the output data dout, i.e., the action P3 of the environment PA . The resulting machine A2 is given as REFINEMENT A2 REFINES A1 SEES Channel Data EXTENDS Reg VARIABLES c1 , dm DEFINITIONS F1 (. . .) == . . . ; F2 (. . .) == . . . INITIALISATION c1 := ack || dm :∈ data OPERATIONS m ← A21 (l) = ˆ SELECT l = req THEN m := req END; A22 (m, din, dout) = ˆ

SELECT m = ack1 THEN ANY dm′ WHERE F1 (dm′ , dout, din) THEN dm := dm′ END WHEN m = ack2 THEN ANY dm′ WHERE F2 (dm′ , dout, din) THEN dm := dm′ END END;

A23 (r) = ˆ SELECT r = ack THEN c1 := req END; l, r ← A24 = ˆ SELECT c1 = ack THEN r := req || l := ack END SCHEDULING A2 (l, din, m, r, dout) = ˆ (A21 ; A22 ; A23 ; A24 ) [] Reg(c1 , dm, dout) MAPPINGS A11 ≤ A21 , A12 ≤ (A22 ; A23 ), A13 ≤ A24 END

24

Multiplexer Because there are two sources for the input data dm of the register Reg, a multiplexer Mux2 is needed. For this, we must first introduce intermediate data variables dm1 and dm2 corresponding to the predicates F1 and F2 , respectively. Then we introduce a communication variable c2 : com2,1 and extract the multiplexer component from the machine A2 . As the result, we get the machine A21 defined by REFINEMENT A21 REFINES A2 SEES Channel Data EXTENDS Reg, Mux2 VARIABLES c1 , c2 , dm, dm1 , dm2 INVARIANT c2 ∈ com2,1 ∧ dm1 ∈ data ∧ dm2 ∈ data DEFINITIONS F1 (. . .) == . . . ; F2 (. . .) == . . . INITIALISATION c1 := ack || c2 := ack || dm :∈ data || dm1 :∈ data || dm2 :∈ data OPERATIONS m ← A211 (l) = ˆ SELECT l = req THEN m := req END; A212 (m, din, dout) = ˆ

SELECT m = ack1 THEN ANY dm1′ WHERE F1 (dm1′ , dout, din) THEN dm1 := dm1′ END || c2 := req1 WHEN m = ack2 THEN ANY dm2′ WHERE F2 (dm2′ , dout, din) THEN dm2 := dm2′ END || c2 := req2 END;

A213 (r) = ˆ SELECT c2 = ack ∧ r = ack THEN c1 := req END; l, r ← A214 = ˆ SELECT c1 = ack THEN r := req || l := ack END SCHEDULING A21 (l, din, m, r, dout) = ˆ (A211 ; A212 ; A213 ; A214 ) [] Reg(c1 , dm, dout) [] Mux2 (c2 , dm1 , dm2 , dm) MAPPINGS A21 ≤ A211 , (A22 ; A23 ) ≤ ((A212 ; A213 ) [] Mux2 (c2 , dm1 , dm2 , dm)), A24 ≤ A214 END

25

Channel converter A channel converter Conv1,1→1 is needed in order to drive the multiplexer Mux2 from two distinct sources. It is extracted by introducing the communication variables c3 : com and c4 : com. The procedure yields the machine A22 given as REFINEMENT A22 REFINES A21 SEES Channel Data EXTENDS Reg, Mux2 , Conv1,1→1 VARIABLES c1 , c2 , c3 , c4 , dm, dm1 , dm2 INVARIANT c3 ∈ com ∧ c4 ∈ com DEFINITIONS F1 (. . .) == . . . ; F2 (. . .) == . . . INITIALISATION c1 := ack || c2 := ack || c3 := ack || c4 := ack || dm :∈ data || dm1 :∈ data || dm2 :∈ data OPERATIONS m ← A221 (l) = ˆ SELECT l = req THEN m := req END; A222 (m, din, dout) = ˆ

SELECT m = ack1 THEN ANY dm1′ WHERE F1 (dm1′ , dout, din) THEN dm1 := dm1′ END || c3 := req WHEN m = ack2 THEN ANY dm2′ WHERE F2 (dm2′ , dout, din) THEN dm2 := dm2′ END || c4 := req END;

r ← A223 = ˆ SELECT (c3 = ack ∨ c4 = ack) ∧ r = ack THEN c1 := req END; l, r ← A224 = ˆ SELECT c1 = ack THEN r := req || l := ack END SCHEDULING A22 (l, din, m, r, dout) = ˆ (A221 ; A222 ; A223 ; A224 ) [] Reg(c1 , dm, dout) [] Mux2 (c2 , dm1 , dm2 , dm) [] Conv1,1→1 (c3 , c4 , c2 ) MAPPINGS A211 ≤ A221 , (A212 ; A213 ) ≤ ((A222 ; A223 ) [] Conv1,1→1 (c3 , c4 , c2 )), A214 ≤ A224 END

26

Function components Two function components Func[F1 /F ] and Func[F2 /F ] are needed in order to implement the predicates F1 and F2 . They are extracted by introducing the communication variables c5 : com and c6 : com. The resulting machine A3 is given below: REFINEMENT A3 REFINES A22 SEES Channel Data EXTENDS Reg, Mux2 , Conv1,1→1 , F unc VARIABLES c1 , c2 , c3 , c4 , c5 , c6 , dm, dm1 , dm2 INVARIANT c5 ∈ com ∧ c6 ∈ com DEFINITIONS F1 (. . .) == . . . ; F2 (. . .) == . . . INITIALISATION c1 := ack || c2 := ack || c3 := ack || c4 := ack || c5 := ack || c6 := ack || dm :∈ data || dm1 :∈ data || dm2 :∈ data OPERATIONS m ← A31 (l) = ˆ SELECT l = req THEN m := req END; A32 (m) = ˆ

SELECT m = ack1 THEN c5 := req WHEN m = ack2 THEN c6 := req END;

r ← A33 = ˆ SELECT c5 = ack ∧ c6 = ack ∧ r = ack THEN c1 := req END; l, r ← A34 = ˆ SELECT c1 = ack THEN r := req || l := ack END SCHEDULING A3 (l, din, m, r, dout) = ˆ (A31 ; A32 ; A33 ; A34 ) [] Reg(c1 , dm, dout) [] Mux2 (c2 , dm1 , dm2 , dm) [] Conv1,1→1 (c3 , c4 , c2 ) [] F unc(c5 , c3 , < din, dout >, dm1 , F1 (. . .)) [] F unc(c6 , c4 , < din, dout >, dm2 , F2 (. . .)) MAPPINGS A221 ≤ A31 , (A222 ; A223 ) ≤ ((A32 ; A33 ) [] F unc(c5 , c3 , < din, dout >, dm1 , F1 (. . .)) [] F unc(c6 , c4 , < din, dout >, dm2 , F2 (. . .))), A224 ≤ A34 END

27

Selection composer The choice construct, or the operation A32 , of the subsystem A3 is implemented with a selection composer If2 . The extraction is carried out by introducing the communication variable c7 : com. We get the machine A4 defined by REFINEMENT A4 REFINES A3 SEES Channel Data EXTENDS Reg, Mux2 , Conv1,1→1 , F unc, If2 VARIABLES c1 , c2 , c3 , c4 , c5 , c6 , c7 dm, dm1 , dm2 INVARIANT c7 ∈ com DEFINITIONS F1 (. . .) == . . . ; F2 (. . .) == . . . INITIALISATION c1 := ack || c2 := ack || c3 := ack || c4 := ack || c5 := ack || c6 := ack || c7 := ack || dm :∈ data || dm1 :∈ data || dm2 :∈ data OPERATIONS A41 (l) = ˆ SELECT l = req THEN c7 := req END; A42 (r) = ˆ SELECT c7 = ack ∧ r = ack THEN c1 := req END; r, l ← A43 = ˆ SELECT c1 = ack THEN r := req || l := ack END SCHEDULING A4 (l, din, m, r, dout) = ˆ (A41 ; A42 ; A43 ) [] Reg(c1 , dm, dout) [] Mux2 (c2 , dm1 , dm2 , dm) [] Conv1,1→1 (c3 , c4 , c2 ) [] F unc(c5 , c3 , < din, dout >, dm1 , F (. . .)) [] F unc(c6 , c4 , < din, dout >, dm2 , F2 (. . .)) [] If2 (c7 , m, c5 , c6 ) MAPPINGS (A31 ; A32 ; A33 ) ≤ ((A41 ; A42 ) [] If2 (c7 , m, c5 , c6 )), A34 ≤ A43 END

28

R-element and suspend component Next, an R-element R is formed from the operation A43 of the machine A4 in order to implement the partly parallel communication cycles on the channels l and r. The extraction procedure includes the introduction of the communication variable c8 : com and the auxiliary boolean variable (status signal) bsy. As a result, the term r = ack in the guard of the operation A42 of A4 can be replaced by ¬bsy, because ¬bsy ⇒ (r = ack). This enables us to extract a suspend component Susp[¬(. . .)/P (. . .)] by introducing the communication variable c9 : com. The resulting machine A5 is given as REFINEMENT A5 REFINES A4 SEES Channel Data, Bool T Y P E EXTENDS Reg, Mux2 , Conv1,1→1 , F unc, If2 , R, Susp VARIABLES c1 , c2 , c3 , c4 , c5 , c6 , c7 , c8 , c9 , dm, dm1 , dm2 , bsy INVARIANT c8 ∈ com ∧ c9 ∈ com ∧ bsy ∈ BOOL DEFINITIONS F1 (. . .) == . . . ; F2 (. . .) == . . . INITIALISATION c1 := ack || c2 := ack || c3 := ack || c4 := ack || c5 := ack || c6 := ack ||c7 := ack || c8 := ack || c9 := ack || dm :∈ data || dm1 :∈ data || dm2 :∈ data || bsy := f alse OPERATIONS A51 = ˆ SELECT l = req THEN c7 := req END; A52 = ˆ SELECT c7 = ack THEN c9 := req END; A53 = ˆ SELECT c9 = ack THEN c1 := req END; A54 = ˆ SELECT c1 = ack THEN c8 := req END; A55 = ˆ SELECT c8 = ack THEN l := ack END SCHEDULING A5 (l, din, m, r, dout) = ˆ (A51 ; A52 ; A53 ; A54 ; A55 ) [] Reg(c1 , dm, dout) [] Mux2 (c2 , dm1 , dm2 , dm) [] Conv1,1→1 (c3 , c4 , c2 ) [] F unc(c5 , c3 , < din, dout >, dm1 , F1 (. . .)) [] F unc(c6 , c4 , < din, dout >, dm2 , F2 (. . .)) [] If2 (c7 , m, c5 , c6 ) [] Susp(c9 , bsy, ¬(. . .)) [] R(c8 , r, bsy) MAPPINGS A41 ≤ A51 , (A42 ; A43 ) ≤ ((A52 ; A53 ; A54 ; A55 ) [] Susp(c9 , bsy, ¬(. . .)) [] R(c8 , r, bsy)) END

29

Sequencer As the final step of the decomposition process the operations of the machine A5 are straightforwardly implemented as a 4-channel sequencer Seq4 . Hence, the final machine A6 is given as REFINEMENT A6 REFINES A5 SEES Channel Data, Bool T Y P E EXTENDS Reg, Mux2 , Conv1,1←1 , F unc, If2 , R, Susp, Seq4 VARIABLES c1 , c2 , c3 , c4 , c5 , c6 , c7 , c8 , c9 , dm, dm1 , dm2 , bsy DEFINITIONS F1 (. . .) == . . . ; F2 (. . .) == . . . INITIALISATION c1 := ack || c2 := ack || c3 := ack || c4 := ack || c5 := ack || c6 := ack ||c7 := ack || c8 := ack || c9 := ack || dm :∈ data || dm1 :∈ data || dm2 :∈ data || bsy := f alse SCHEDULING A6 (l, din, m, r, dout) = ˆ Reg(c1 , dm, dout) [] Mux2 (c2 , dm1 , dm2 , dm) [] Conv1,1→1 (c3 , c4 , c2 ) [] F unc(c5 , c3 , < din, dout >, dm1 , F1 (. . .)) [] F unc(c6 , c4 , < din, dout >, dm2 , F2 (. . .)) [] If2 (c7 , m, c5 , c6 ) [] Susp(c9 , bsy, ¬(. . .)) [] R(c8 , r, bsy) [] Seq4 (l, c7 , c9 , c1 , c8 ) MAPPINGS (A51 ; A52 ; A53 ; A54 ; A55 ) ≤ Seq4 (l, c7 , c9 , c1 , c8 ) END

References [1] J.-R. Abrial. The B-Book. Cambridge University Press, Cambridge, Great Britain, 1996. [2] R. J. R. Back and R. Kurki-Suonio. Decentralization of process nets with centralized control. In Proc. of the 2nd ACM SIGACT–SIGOPS Symp. on Principles of Distributed Computing, pages 131–142, 1983. [3] R.J.R. Back, A.J. Martin, and K. Sere. Specifying the Caltech Asynchronous Microprocessor. Science of Computer Programming 26(1996):79-97. Elsevier. [4] R. J. R. Back and K. Sere. Stepwise refinement of action systems. Structured Programming, 12:17–30, 1991. [5] R. J. R. Back och K. Sere. From action systems to modular systems. In Proc. of FME’94: Industrial Benefit of Formal Methods. LNCS 873, pp. 1–25, Barcelona, Spain, October 1994. Springer–Verlag. [6] K. van Berkel. Handshake circuits: an asynchronous architecture for VLSI programming. International Series on Parallel Computation. Cambridge University Press, 1993. 30

[7] K. van Berkel, J. Kessels, M. Roncken, R. Saeijs, and F. Schalij. The VLSI-programming language Tangram and its translation into handshake circuits. In Proc. of the European Automation Conference, pages 384–389, IEEE, 1991. [8] M. M. Bonsangue, J. N. Kok, and K. Sere. Developing object-based distributed system. In Formal Methods for Open Object-based Distributed Systems (FMOODS’99), Florence, Italy, February 1999. Kluver Academic Publishers. [9] M. J. Butler. csp2B: A practical approach to combining CSP and B. In J. Wing, J. Woodcock and J. Davies (Eds.) Proc. of FM’99 - Formal Methods. LNCS 1708, pages 490 – 508, Toulouse, France, September 1999. Springer-Verlag. [10] M. J. Butler and M. Wald´en. Distributed System Development in B. In H. Habrias (Ed.) Proc. of the First Conference on the B Method. pages 155 – 168, IRIN, Nantes, France, November 1996. [11] E. W. Dijkstra. A Discipline of Programming. Prentice–Hall International, Englewood Cliffs, New Jersey, 1976. [12] C.A.R. Hoare. Communicating Sequential Processes. Series in Computer Science, Prentice-Hall Int, 1985. [13] A.J. Martin. Synthesis of Asynchronous VLSI Circuits. California Institute of Technology, Technical Report Caltech-CS-TR-93-28, 1993. [14] D. S. Neilson and I. H. Sorensen. The B-Technologies: A system for computer aided programming. Including the B-Toolkit User’s Manual, Release 3.2. B-Core (UK) Ltd., Oxford, U.K., 1996. [15] A. Peeters. Single-Rail Handshake Circuits. PhD Thesis, Eindhoven University of Technology, The Netherlands, 1996. [16] J. Plosila. Self-Timed Circuit Design – The Action Systems Approach. PhD thesis, University of Turku, Turku, Finland, 1999. [17] J. Plosila, R. Ruksenas, and K. Sere, Action Systems Synthesis of DI Circuits. In Proc. of the International Refinement Workshop and Formal Methods Pasific 1998, September 1998, Canberra, Australia. [18] J. Plosila and T. Seceleanu. An Asynchronous Linear Predictive Analyzer. TUCS Report 142, 1997. Submitted for publication. [19] J. Plosila and K. Sere. Action Systems in Pipelined Processor Design. In Proc. of the Third International Symposium on Advanced Research in Asynchronous Circuits, April 1997. IEEE Computer Society Press. 31

[20] R. Ruksenas. Tool Support for Data Refinement. Ph.D. Thesis. Forthcoming. [21] E. Sekerinski and K. Sere (Eds.). Program Development by Refinement. FACIT, Springer Verlag 1998. [22] St´eria M´editerran´ee. Atelier B. France, 1996. [23] M. Wald´en and K. Sere. Reasoning about action systems using the B-Method. In Formal Methods in System Design, Vol. 13, No 1, pages 5 - 35, May 1998. Kluwer Academic Publishers. [24] J. von Wright. Program refinement by theorem prover. In Proc. of Sixth BCS-FACS Refinement Workshop, January 1994.

32

Turku Centre for Computer Science Lemmink¨aisenkatu 14 FIN-20520 Turku Finland http://www.tucs.abo.fi

University of Turku • Department of Mathematical Sciences

˚ Abo Akademi University • Department of Computer Science • Institute for Advanced Management Systems Research

Turku School of Economics and Business Administration • Institute of Information Systems Science