A Formal Approach to Aspect-Oriented Modular ... - IEEE Xplore

A Formal Approach to Aspect-Oriented Modular Reconfigurable Computing Phan Cong-Vinh London South Bank University, Centre for Applied Formal Methods London, United Kingdom [email protected] Abstract For aspect-oriented modular reconfigurable computing, we specify a notion of “aspect” in the context of modular reconfigurable computing systems. In our formal approach, an aspect is determined as a coalgebraic transformation on modular reconfigurable computing systems. Then, based on this fundamental concept of aspect, inheritance and superimposition properties of aspects are studied. Specifically, the inheritance property is shown to be a bisimulation relation and the superimposition property is determined in the context of coalgebraic reconfiguration. Moreover, we also justify that our approach is sufficiently expressive to combine aspect-orientation and modular reconfigurable computing.

1 Introduction In reconfigurable computing, a key question is how to further narrow the gap between hardware and software. A potential approach is an effective powerful paradigm that combines Software-Oriented Dedicated Computing methods with Hardware-Oriented Dedicated Computing methods in a new logic of computation. In other words, the should approach combines the flexible nature of software with hardware design and the high performance nature of hardware with software programming. This topic has seen a number of developments through various research investigations [7–12, 14] and our work [20–25]. In recent years, a programming technique based on cross-cutting, also referred to as aspect orientation, has emerged as an orthogonal approach to modular programming methods [16, 19]. We believe that such a paradigm is of great potential practical use for aspect-oriented modular reconfigurable computing. Thus this paper will present our approach to combining aspect-orientation and reconfigurable computing in a modular manner. This is a novel development based on our recent research [20–25] to embed the cross-cutting technique in modular reconfigurable com-

Jonathan P. Bowen Museophile Limited Reading, United Kingdom [email protected]

puting systems. For a formal approach of such a cross-cutting technique, we model modular reconfigurable computing systems in an expressive coalgebraic framework. Our aim is to use this framework as a basis for investigating properties and capabilities of such a technique, composed of an inheritance property and a superimposition property. The inheritance property allows the study of which features of the resulting system are preserved across the application of aspect. The superimposition property enables examination of which resulting systems satisfy constraints imposed by the aspect. Moreover, from analysis results on these properties, we can more clearly understand the application of the aspectoriented technique in the context of modular reconfigurable computing.

2 Outline The paper is organized as follows: In section 3, we consider preliminary concepts of reconfigurable computing. In section 4, we introduce the notion of an aspect in the context of modular reconfigurable computing, including a coalgebraic framework of the reconfiguration process, together with definitions of aspect, inheritance and superimposition properties of the aspect and its semantics based on the coalgebraic framework. For illustration, a typical aspect provided by a particular reconfiguration process and some analyses based on the aspect are presented in section 5. A plan for future work is suggested in section 6. Finally, section 7 summarizes our formal approach to combining aspect-orientation and reconfigurable computing in a modular fashion.

3 Preliminaries 3.1

Reconfigurable computing

A definition of reconfigurable computing, also sometimes known as configurable computing, is given by DeHon and Wawrzynek as:

First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE'07) 0-7695-2856-2/07 $20.00 © 2007

“computing via a post-fabrication and spatially programmed connection of processing elements ” [5]. This definition is concerned with two major factors of reconfigurable computing: • The post-fabrication property allows adjustment of the architecture for flexibility between applications due to varying data input flows and operation conditions. • The spatial paradigm of computation, also called configware contrasts with the temporal paradigm of computation using traditional microprocessors, called by the familiar name of software. The implementation of reconfigurable computing has become realistic with the availability of Field-Programmable Gate Array (FPGA) technology. In fact, Lysaght has said that: “the importance of dynamically reconfigurable logic will increase, as FPGAs become larger ” [17]. A specific type of FPGA, which can be programmed on-thefly during system operation, is dynamically reconfigurable FPGA, also known as a Dynamically Programmable Gate Array (DPGA) technology [4]. Quite differently from some other types of FPGA, a DPGA can be programmed using a partial or full reconfiguration. Andr´e DeHon states: “Dynamically Programmable Gate Arrays (DPGAs) are programmable arrays which allow the strategic reuse of limited resources. In so doing, DPGAs promise greater capacity, and in some cases higher performance, than conventional programmable device architectures where all array resources are dedicated to a single function for an entire operational epoch ” [4].

3.2

Configware and Flowware

The statements in subsection 3.1 about reconfigurable computing refer to the notion of R. Hartenstein’s configware engineering [7–12,14], including configware and flowware, in which both configware and flowware codes are created by compiling inputs of a high-level programming language. Specifically, configware codes are produced for determining configuration before runtime, and flowware codes execute data input flows at runtime on an existing configuration.

Figure 1(a) illustrates the configware approach, in which a sequence of operations is mapped from time to space and executed per C-step (also called a control step) in parallel on a DPGA; its intermediate results are stored in buffers for another sequence of operations in the next C-step. 3.2.2 Flowware Flowware means data-flow programming that schedules the data flow for output from or input to the DPGA-based architecture using one or several data counters. Flowware determines which data item has to be connected with which DPGA port of which configuration at which time (see Figure 1(b)). The DPGA-based architecture is vital for the flowware-based paradigm. This architecture allows the multiple data flows clocked into and out of such a pipelined network, in a similar manner to the heart and the blood streams. The specification of data flows can be expressed by flowware language. Data flows are created by executing flowware code on distributed memory arrays (denoted by the symbol D in Figure 1(c)), surrounding the DPGA to drive data flows from/to the DPGA. Flowware may also be described by higher level flowware languages, which are similar to high level software languages like C [1]; an example language is SystemC [3, 6]. These languages include control structures such as jumping and (nested) looping. The principal differences between software and flowware are that (sequential) software makes reference to only a single program counter, whereas flowware refers to several data counters. As a result, flowware also includes parallel looping as an important control structure, which is not supported by sequential software. 3.2.3 Configware/Flowware synthesis Both flowware and configware are two different complementary approaches that can be combined in programming for reconfigurable computing systems. Figure 1(c) describes a process of configware/flowware synthesis, generating both configware and flowware from a high level programming language source, in which configware is produced for establishing the configuration before runtime and flowware is used to execute data flows at runtime.

4 Aspect in the Context of Modular Reconfigurable Computing Systems 4.1

3.2.1 Configware Configware means structural programming, or programming in space as presented in Figure 1(a). That is, configware executes computation in space. Configware is also sometimes called Soft IP (Intellectual Property) Cores [13].

Reconfiguration and its coalgebraic semantics

4.1.1 Reconfiguration Let T be a (finite or infinite) set of transformations. A reconfiguration with set of transformations T is a pair

First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE'07) 0-7695-2856-2/07 $20.00 © 2007

time

register

Clock tick 1

register

Clock tick 2

register

Clock tick 3

Input data streams

•• •• · · ·

•• · · · •

High-level program source

· · · •• •

D

D

D

D

Wrapper

port x

time

register

Clock tick 4

time · · ·

· · · Mapping time to space

time

Input data streams

bu ff er bu ff er

D

Configuration n

DPGA · · · •

• · · ·

· · · • •

DPGA

D

Configuration 2

D

y bu ff er

C-step 1

Intermediate

Output data streams

Configuration 1

D

Compiler Mapper (placement & routing)

D

D

D

D

• • · · ·

port

port

C-step 2

· · ·

C-step 3

C-step 4

time

•• · · ·

Output data streams

D

D

D

Data Flow Scheduler

D

•• •• · · ·

Configware Code

Flowware Code

time

(a) Configware

(b) Flowware

(c) Configware/Flowware synthesis

Figure 1. Configware and Flowware (adapted from [13]) This bisimulation relation is read as: two reconfigurations issue the same observations in O and the same transformation is carried out on both configurations in C that will lead to two new configurations in C that are observationally indistinguishable again. A bisimulation between hC, hoC , eC ii and itself is called a bisimulation on hC, hoC , eC ii. We write c ∼ c0 whenever there exists a bisimulation R with c R c0 .

hC, hoC , eC ii consisting of • a set C of configurations, • an output function oC : C −→ OT , and • an evolution function eC : C −→ C T . where • OT and C T are read as {f : T −→ O} and {g : T −→ C} respectively, • O is a set of observable output values, • oC assigns, to a configuration c, a function oC (c) : T −→ O, which specifies the value oC (c)(t) that is reached after a transformation t has been executed. • Similarly, eC assigns, to a configuration c, a function eC (c) : T −→ C, which specifies the configuration eC (c)(t) that is reached after a transformation t has t been executed. Sometimes c −→ c0 is used to denote eC (c)(t) = c0 . Generally, both the configuration space C and the set T of transformations may be infinite. If both C and T are finite, then we have a finite reconfiguration, otherwise we have an infinite reconfiguration. A bisimulation between two reconfigurations hC, hoC , eC ii and hC 0 , hoC 0 , eC 0 ii is a relation R ⊆ C × C 0 with, for all c in C, c0 in C 0 and t in T ½ oC (c)(t) = oC 0 (c0 )(t) and if c R c0 then eC (c)(t) R eC 0 (c0 )(t). In other words, ½ if hc, c0 i ∈ R then

oC (c)(t) = oC 0 (c0 )(t) heC (c)(t), eC 0 (c0 )(t)i ∈ R.

and

4.1.2 Coalgebraic semantics of reconfiguration For a reconfiguration hC, hoC , eC ii, the functions oC : C −→ OT and eC : C −→ C T can be now combined into one function hoC , eC i : C −→ (O × C)T , which maps c in C into the pair hoC (c), eC (c)i. Thus the reconfiguration hC, hoC , eC ii is considered as the structure observed through the following interface. ¯ = (O × )T because applying this interface to the observable configuration space C, we have ¯ C = (O × C)T This interface of ¯ can be regarded as a mapping to decompose the observable configuration space C into an observation context (O × )T of the configuration space. Let ¯ : C −→ C be a functor on the category of configurations and functions. A ¯-coalgebra is a pair hC, f i consisting of a set C and a function f : C −→ ¯ C. Thus reconfigurations are coalgebras of the functor ¯, which is defined on sets C by ¯ C = (O × C)T . In this way, the reconfiguration hC, hoC , eC ii has been represented as a ¯coalgebra hoC , eC i : C −→ ¯ C. Through this coalgebraic representation of reconfigurations, there exist a number of notions and results on coalgebras in general, which can be applied to reconfigurations.

First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE'07) 0-7695-2856-2/07 $20.00 © 2007

4.2

Aspect and its coalgebraic semantics

For ti ∈ T, ∀i ∈ N, an aspect A : ht1 , t2 , . . . , tn i is considered as a transformation on modular reconfigurable computing system M : hc1 , c2 , . . . , cn i including n modular configurations where ci ∈ C, ∀i ∈ N. Let A : ht1 , t2 , . . . , tn i be an aspect and M : hc1 , c2 , . . . , cn i be a modular reconfigurable computing system. An application of A to M (denoted by A(M)) determines the modular resulting reconfigurable computing system M0 : hc01 , c02 , . . . , c0n i = ht1 (c1 ), t2 (c2 ), . . . , tn (cn )i. That is, 0

A(M) = M : ht1 (c1 ), t2 (c2 ), . . . , tn (cn )i 4.2.1 Inheritance property as a bisimulation A bisimulation between two modular reconfigurable computing systems M : hc1 , c2 , . . . , cn i and M0 : hc01 , c02 , . . . , c0n i is a relation L ⊆ M × M0 with, for all hc1 , c2 , . . . , cn i in M, hc01 , c02 , . . . , c0n i in M0 and ht1 , t2 , . . . , tn i in A t

if hc1 , c2 , . . . , cn i L hc01 , c02 , . . . , c0n i then ci ∼i c0i , ∀ i ∈ N t

we write ci ∼i c0i when ci ∼ c0i under transformations ti in T . In other words, if hhc1 , c2 , . . . , cn i, hc01 , c02 , . . . , c0n ii ∈ L then hci , c0i iti ∈ R where hci , c0i iti in R denotes hci , c0i i in R under transformations ti in T . We also write M ∼ M0 whenever there exists a bisimulation L with hc1 , c2 , . . . , cn i L hc01 , c02 , . . . , c0n i. Two modular reconfigurable computing systems M and M0 that are related by a bisimulation relation are observationally indistinguishable in that:

Proof. In fact, the relational composition of two bisimulations L1 ⊆ M × M0 and L2 ⊆ M0 × M00 is the bisimulation obtained by L1 ◦ L2 = {hx, yi | x L1 z and z L2 y for some z ∈ M0 } where x = hc1 , c2 , . . . , cn i ∈ M, z = hc01 , c02 , . . . , c0n i ∈ M0 and y = hc001 , c002 , . . . , c00n i ∈ M00 Proposition 4.2. (M ∼

M0 )

where x = hc1 , c2 , . . . , cn i and y = hc01 , c02 , . . . , c0n i The union of all bisimulations S between M and applications of aspect A(M) (i.e., (M ∼ A(M)) ) is the greatest bisimulation. The greatest bisimulation is called the bisimulation equivalence or bisimilarity [18] (again denoted by the notation ∼). S Proposition 4.3. The bisimilarity ∼ on (M ∼ A(M)) is an equivalence relation. S Proof. In fact, a bisimilarity ∼ on (M ∼ A(M)) is a S binary relation ∼ on (M ∼ A(M)) that is reflexive, symmetric and transitive; i.e., it holds such that • Reflexivity: S ∀(a ∼ b) ∈ (M ∼ A(M)) (a ∼ b) ∼ (a ∼ b) • Symmetry: ∀(a ∼ b), (c ∼ d) ∈

For further well-founded investigation, we justify some following statements. Let M0 and M00 be applications of aspect A(M). Proposition 4.1. If M ∼ M0 and M0 ∼ M00 then (M ∼ M0 ) ◦ (M0 ∼ M00 ) = M ∼ M00 , where the symbol ◦ denotes a relational composition. For more descriptive notation, we can write this in the form

M ∼ M0 , M ∼ M00 S (M ∼ M00 ) = M ∼ (M0 M00 )

0 and L2 ⊆ M × M00 are Proof. In fact, if L1 ⊆ M × MS L2 is also bisimulation any two bisimulations then L S1 L2 is either hx, yi ∈ L1 or because every hx, yi ∈ L1 hx, yi ∈ L2 . In other words, it is formally denoted by ^ [ _ L2 = {hx, yi | x ∈ M (y ∈ M0 y ∈ M00 )} L1

• Each member module in M and its partner module in M0 cause the same observations, and • Applying the same aspect to both systems will lead to two resulting systems that are indistinguishable again.

S

[

(M ∼ A(M)),

(a ∼ b) ∼ (c ∼ d) (c ∼ d) ∼ (a ∼ b) • Transitivity:

M ∼ M0 , M0 ∼ M00 (M ∼ M0 ) ◦ (M0 ∼ M00 ) = M ∼ M00

First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE'07) 0-7695-2856-2/07 $20.00 © 2007

[ ∀(a ∼ b), (c ∼ d), (e ∼ f ) ∈ (M ∼ A(M)), V ((a ∼ b) ∼ (c ∼ d)) ((c ∼ d) ∼ (e ∼ f )) (a ∼ b) ∼ (e ∼ f )

The bisimulation relation between M and A(M) is now shown as a semantic basis of inheritance property of aspect. In other words, for some condition α, we can formally represent the inheritance property as the following: M |= α A(M) |= α That is, if modular reconfigurable computing system M satisfies condition α then this constraint is still preserved on an application of aspect A(M). Thus it is read as M ∼ A(M) in the constraint of α (and denoted by M ∼α A(M)). 4.2.2 Superimposition property in its coalgebraic semantics Superimposition is an aspect A that can augment an underlying modular reconfigurable computing system M to a resulting system A(M) with added functionality α, while cutting across modularity processes of usual reconfigurable computing. In other words, we can formally represent the superimposition property as the following specification: A |= α A(M) |= α Modular reconfigurable computing system in which reconfiguration may be imposed by aspect A is coalgebra of functor F (M) = (U × M)A (recall that (U × M)A = f : A −→ U × M): huM , eM i : M −→ (U × M)A where U is an output set, uM is an output function uM : M −→ U A and eM is an evolution function eM : M −→ MA . Alternately, we can write as ½ uM (m)(a) = u, a 0 m −→ hu, m i ⇐⇒ eM (m)(a) = m0 where every u in the set U of outputs is defined by u = a hoC (c1 )(t1 ), . . . , oC (cn )(tn )i and the arrow of −→ can be read as: in configuration m = hc1 , . . . , cn i ∈ M and given transformation a = ht1 , . . . , tn i ∈ A, the system can be make a change to configuration m0 = hc01 , . . . , c0n i ∈ M by the evolution function eM and we can observe the output u ∈ U. In other words, we also consider the output u as the observable effect of the change of configuration. Such system hM, huM , eM i : M −→ (U × M)A i is precisely the deterministic system hM, huM×A , eM×A i : M × A −→ U × Mi with aspect A mentioned above because of the following bijection: {M −→ (U × M)A } ∼ = {M × A −→ U × M}

The deterministic reconfigurable computing system hM, huM×A , eM×A i : M × A −→ U × Mi consists of a set M of configurations, output function uM×A and evolution function eM×A that for every configuration m in M and transformation a in aspect A determine the observable output uM×A (hm, ai) and next configuration eM×A (hm, ai). A bisimulation between reconfigurable computing systems hM, huM×A , eM×A ii and hN , huN ×A , eN ×A ii is now a relation L ⊆ M × N such that, for all a in A, V V a a hm, ni ∈ L m −→ hu, m0 i n −→ hu, n0 i hm0 , n0 i ∈ L A homomorphism between reconfigurable computing systems hM, huM×A , eM×A ii and hN , huN ×A , eN ×A ii is now any function h : M × A −→ N × A satisfying, for all m in M and a in A, a

m −→ hu, m0 i a

h(m) −→ h(hu, m0 i) Thus homomorphism is also understood as a functional bisimulation.

5 An Illustration of Aspect in the Context of Modular Reconfigurable Computing Systems In this section we present an example of how the notion of aspect introduced in section 4 can be manipulated in our approach. In fact, the aspect can expressively represent the kind of reconfiguration which has been detailed in [20] and here some relevant contents are briefly presented in the following subsection 5.1.

5.1

Transformations

For reconfigurable computing, in [20] we have considered the type of configuration changes consisting of transformations of rotation, horizontal reflection, vertical reflection, horizontal shifting and vertical shifting (see Figure 2). When rotating or reflecting a configuration, its components are relocated from combinations of two basic transformations: rotation 900 (R) and vertical reflection (V). When a configuration is horizontally (or vertically) shifted, its components have to be translated in the respective directions First of all, we represent two basic operations of transformation: rotation 900 and vertical reflection. Let c ∈ C be a starting configuration. 5.1.1 Rotation 900 (R) This transformation rotates a configuration c ∈ C by 900 clockwise, see Figure 2(b).

First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE'07) 0-7695-2856-2/07 $20.00 © 2007

(a) Current configuration c ` ID(c)

(b) c ` R(c)

(c) c ` RR(c)

(g) c ` VRR(c)

(h) c ` VRRR(c)

(i) c ` → (c)

k>0

(d) c ` RRR(c)

k0

(k) c ` ↓ (c)

(f) c ` VR(c)

k 0) or left (k < 0) direction, see Figures 2(i) and 2(j).

First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE'07) 0-7695-2856-2/07 $20.00 © 2007

◦ R RR RRR VRR VRRR V VR ID

R RR RRR ID VRRR V VR VRR R

RR RRR ID R V VR VRR VRRR RR

RRR ID R RR VR VRR VRRR V RRR

VRR VRRR V VRRR ID RRR RR R VRR

VRRR V VR V R ID RRR RR VRRR

V VR VRR VR RR R ID RRR V

VR VRR VRRR VRR RRR RR R ID VR

ID R RR RRR VRR VRRR V VR ID

Table 1. Relation of the transformations k

that defines an algebra of TT (or a TT -algebra) Regarding algebra f : TT (C) −→ C of the functor TT , the set C is called the carrier of the algebra and the function f is called the structure of algebra or the operation of the algebra. Hence this algebra of TT corresponds to model of T.

5.1.10 Vertical shifting (↓) For an integer k, this transformation vertically moves a configuration down (k > 0) or up (k < 0), see Figure 2(k) and 2(l).

5.2

Algebra of transformations 5.3

Let C be a notation of configuration space, known as a set of configurations, including configurations being reachable by transformations. Let T be a signature denoting a set of transk

Let M be a modular reconfigurable computing system consisting of two modules of configuration c1 ∈ C and c2 ∈ C as in Figure 3(a). From the transformations T =

k

k

formations {ID, R, RR, RRR, V, VR, VRR, VRRR, →, ↓ }. Each transformation in T is a unary operation. In other words, each t ∈ T is recognized as an operation t:

C |{z}

−→

one argument

taking a configuration input of type C and producing a configuration output of type C. With this signature T of the set of transformations k

k

we

as-

5.4

|T | ] TT (C) = C

k

k

, ↓} is precisely input flow join with the context information of M : hc1 , c2 i to built up the reconfiguration process that will eventually modify the context information, thus influencing the change in more later configurations. 5.4.1 Inheritance

• a set of configurations C and k

• a function f = [ID, R, RR, RRR, V, VR, VRR, VRRR, → k

Analysis on aspect

The set of T = {ID, R, RR, RRR, V, VR, VRR, VRRR, →

in which we see how the shape of the considered functor TT is determined by the arity of transformations in T (that is, | T |= 10 elements of T ). Note that symbol + indicates a disjoint union (or coproduct [15]). The major role of the disjoint unions is to combine multiple operations into a single operation. Algebra of transformations is a pair hC, f : TT (C) −→ Ci consisting of:

, ↓] : TT (C) −→ C of transformations t : C −→ C for each t ∈ T

k

{ID, R, RR, RRR, V, VR, VRR, VRRR, →, ↓} considered in subsection 5.1, the aspect A : ht1 , t2 i, where ∀t1 , t2 ∈ T , is determined on M : hc1 , c2 i. In this case, the application of A : ht1 , t2 i to M is written ht1 , t2 i(hc1 , c2 i) = ht1 (c1 ), t2 (c2 )i. As an exemplification in the limited space of the paper, here we illustrate only three instances of the modular resulting system as in Figure 3. Specifically, hR(c1 ), V(c2 )i, hVR(c1 ), R(c2 )i and hVRR(c1 ), VRRR(c2 )i produce three resulting systems in Figures 3(b), 3(c) and 3(d) respectively.

C

{ID, R, RR, RRR, V, VR, VRR, VRRR, →, ↓} sociate a functor in disjunctive normal form

An aspect and its application

In this particular investigation, an inheritance between the modular systems hM, hoM , eM ii and hA(M), hoA(M) , eA(M) ii satisfies a bisimulation relation M ∼ A(M) with hc1 , c2 i ∼ hR(c1 ), V(c2 )i hc1 , c2 i ∼ hVR(c1 ), R(c2 )i hc1 , c2 i ∼ hVRR(c1 ), VRRR(c2 )i

First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE'07) 0-7695-2856-2/07 $20.00 © 2007














 



 



(a) A modular system (M : hc1 , c2 i)

























(b) M ` hR, Vi(M) = hR(c1 ), V(c2 )i

 




 

 











(c) M ` hVR, Ri(M) = hVR(c1 ), R(c2 )i




 





(d) M ` hVRR, VRRRi(M) = hVRR(c1 ), VRRR(c2 )i

Figure 3. Applying aspect A on the modular system M : hc1 , c2 i and so on. In other words, V c1 ∼ R(c1 ) V c2 ∼ V(c2 ) c1 ∼ VR(c1 ) V c2 ∼ R(c2 ) c1 ∼ VRR(c1 ) c2 ∼ VRRR(c2 ) and so on. As the statement justified in proposition 4.2, we are easy to see that hc1 , c2 i ∼ hR(c1 ), V(c2 )i, hc1 , c2 i ∼ hVR(c1 ), R(c2 )i, hc1 , c2 i ∼ hVRR(c1 ), VRRR(c2 )i S S hc1 , c2 i ∼ (hR(c1 ), V(c2 )i hVR(c1 ), R(c2 )i hVRR(c1 ), VRRR(c2 )i) From the symmetry of bisimulation shown in proposition 4.3, we obtain

• If configuration in C is relocated by a transformation operation, then all its components are also relocated by the same operation. Thus, any pair of modular systems hM, A(M)i in a reconfiguration process is invariant under the reconfiguration operations. In this setting, the reconfiguration operation Op : M −→ A(M) is defined as a map between two modular systems in the same reconfiguration process and an invariant under this reconfiguration operation is written as Op(fM (m)) = fA(M) (Op(m)) for all m ∈ M and for each unary operation fM (m) determining a set of direct connections to each m ∈ M. In other words, the invariant is the homomorphism of all m ∈ M under the reconfiguration operations.

hc1 , c2 i ∼ hR(c1 ), V(c2 )i, hc1 , c2 i ∼ hVR(c1 ), R(c2 )i,

5.4.2 Superimposition

hc1 , c2 i ∼ hVRR(c1 ), VRRR(c2 )i hR(c1 ), V(c2 )i ∼ hc1 , c2 i, hVR(c1 ), R(c2 )i ∼ hc1 , c2 i, hVRR(c1 ), VRRR(c2 )i ∼ hc1 , c2 i

In a specific way [20], we have considered the output set O as 2 = {0, 1}, where output is 1 when a change of module c ∈ C is successfully executed and 0 otherwise. Therefore, the signature of huM , eM i becomes

Hence, as a consequence of proposition 4.1, we also obtain the following result: hR(c1 ), V(c2 )i ∼ hVRR(c1 ), VRRR(c2 )i ∼ hVRR(c1 ), VRRR(c2 )i. In fact, such each pair of modular systems hM, A(M)i in a reconfiguration process are observationally indistinguishable in the following meaning [20]: • Adjacency of components in a configuration in C is preserved in any relocation. • Routing the components in a configuration in C and its input/output directions is kept undamaged in any way. • The location of components in a configuration in C is relocated when that configuration is changed.

huM , eM i : M −→ (2n × M)A where the output set U is defined by 2n with n ∈ N (recall n Q that 2n is read as 2). Here output u ∈ 2n is h1, 1, . . . , 1i when an application of aspect A(M) is perfectly done and u ∈ 2n \ {h1, 1, . . . , 1i} otherwise. The function huM , eM i is a mathematical tool for building the reconfiguration process. Using this technology, reconfiguration processes and their evolution can be observed. The universal view will equip itself with the right “glass” − that is a mathematical tool with which to observe and which necessarily gives rise to a particular “shape” for observation. The relation be specified is between the input

First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE'07) 0-7695-2856-2/07 $20.00 © 2007

flow as a set of transformations and the output configurations depending on the particular kind of observation we want to perform. In other words, our focus becomes the universe or, more pragmatically, the modular system M. The observed configuration being produced from the reconfiguration is just one among other possible observations. The basic concepts required to support an observation of reconfiguration processes consist of: n

A

• A glass: ¯ = (2 × )

• An observation structure:

Data Flow Data Flow

(Flowware Codes)

(Flowware Codes)

Data Flow (Flowware Codes)

Configurations Data Flow

(Configware Codes)

Data Flow

(Flowware Codes)

(Flowware Codes)

Data Flow

Data Flow

huM ,eM i

modular system M −−−−−−→ ¯ modular system M Informally, the glass can be thought of as providing a shape that huM , eM i is able to handle in each of the situations mentioned above. From a technical point of view, as this paper has aimed to make clear, the pair hM, huM , eM ii, as above, constitutes a coalgebra with interface ¯. Coalgebras provide uniform models for reconfiguration processes.

6 Future Work Unlike the algebraic approach to the operations, which are completely defined by a set of operators, the reconfigurations we study here are specified by determining their behavior. This is done not only by an external input specification, but also by the internal context in the modular system, to which there is no direct access in general. Such reconfigurations are inherently dynamic and have an observable behavior, but their internal configurations remain hidden and therefore have to be identified if not distinguishable by observation. Our approach throughout this paper has aimed to develop a foundation of aspect-oriented modular reconfigurable computing that is characterized by: • Configuration space: In this space, configurations evolve and persist by adapting to improve suitableness over time; • Interaction: This specifies the exchangeability with the environment during the reconfiguration process; • Aspect/Component-Oriented model: In this model, configware is oriented towards “aspect” development and flowware is oriented towards a “component” approach. Aspect-Oriented Configware relies on “separation of concerns” in all phases of the configware development lifecycle, while ComponentOriented Flowware greatly depends on pre-fabricated “components” for building the data processing needs of flowware. Incorporating both the emerging programming approaches based on aspect [16] and component [2] oriented paradigms could unify the two specialized concepts of “modularity” and “separation of concerns” in the model (see Figure 4).

(Flowware Codes)

Data Flow

(Flowware Codes)

(Flowware Codes)

Figure 4. A diagrammatic illustration of Aspect/Component-Oriented reconfigurable computing

7 Summary For combining aspect-orientation and modular reconfigurable computing, our unified approach presented in this paper relies on coarse-grained abstraction in which the “aspect” is considered as a coalgebraic transformation A composed of the elementary transformations in T on a modular reconfigurable computing system M. The inheritance property of the aspect is shown as a bisimulation relation and superimposition property of aspect is specified and examined in the context of coalgebraic reconfiguration. As a result, the approach is a basic modeling development on which we can carry out some desirable extensions such as parameterizations and capability of context capture. Moreover, this abstract level makes our modeling approach easier for justifying preservation of the system features in further developments because the set of behaviors is captured and covered well.

References [1] A. Ast, J. Becker, R. Hartenstein, R. Kress, H. Reinig, and K. Schmidt. Data-Procedural Languages for FPL-based Machines. In R. Hartenstein and M. Serv´ıt, editors, 4th International Workshop on Field-Programmable Logic and Applications: Field-Programmable Logic, Architectures, Synthesis and Applications, volume 849 of Lecture Notes in Computer Science, pages 183–195, Prague, Czech, 7–9 September 1994. Springer–Verlag.

First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE'07) 0-7695-2856-2/07 $20.00 © 2007

[2] L. Barbosa and Z. Liu, editors. Proceedings of the 2nd International Workshop on Formal Aspects of Component Software (FACS), Macao, 24–25 October 2005. UNU/IIST. ENTCS. [3] D. Black and J. Donovan. SystemC: From the Ground Up. Springer, 1st edition, 31 May 2004. 244 pages. [4] A. DeHon. DPGA Utilization and Application. In 4th International Symposium on Field Programmable Gate Arrays (FPGA’96), pages 115–121, Monterey, CA, US, 11–13 February 1996. ACM. [5] A. DeHon and J. Wawrzynek. Reconfigurable Computing: What, Why, and Implications for Design Automation. In 36th Design Automation Conference (DAC), pages 610–615, New Orleans, LA, USA, 21–25 June 1999. ACM. [6] T. Gr¨otker, S. Liao, G. Martin, and S. Swan. System Design with SystemC. Springer, 1st edition, 31 May 2002. 240 pages. [7] R. Hartenstein. The Microprocessor is No Longer General Purpose: Why Future Reconfigurable Platforms Will Win. In 2nd Annual International Conference on Innovative Systems in Silicon, pages 2–12, Austin, TX, USA, 8–10 October 1997. IEEE. [8] R. Hartenstein. A Decade of Reconfigurable Computing: A Visionary Retrospective. In Design, Automation, and Test in Europe Conference (DATE), pages 642–649, Munich, Germany, 13–16 March 2001. IEEE. [9] R. Hartenstein. Coarse Grain Reconfigurable Architectures. In Asia and South Pacific Design Automation Conference (ASP-DAC), pages 564–569, Yokohama, Japan, 30 January – 2 February 2001. IEEE. [10] R. Hartenstein. Reconfigurable Computing: A New Business Model and its Impact on SoC Design. In Euromicro Symposium on Digital Systems, Design (DSD), pages 103– 110, Warzaw, Poland, 4–6 September 2001. IEEE. [11] R. Hartenstein. Trends in Reconfigurable Logic and Reconfigurable Computing. In 9th International Conference on Electronics, Circuits and Systems (ICECS), volume 2, pages 801–808, Dubrovnik, Croatia, 15–18 September 2002. IEEE. [12] R. Hartenstein. Are We Really Ready for the Breakthrough? [morphware]. In International Parallel and Distributed Processing Symposium (IPDPS), Nice, France, 22–26 April 2003. IEEE. CD-ROM. [13] R. Hartenstein. Handbook of Nature-Inspired and Innovative Computing. Integrating Classical Models with Emerging Technologies, chapter Morphware and Configware, page 780. Springer, 2005. [14] M. Herz, R. Hartenstein, M. Miranda, E. Brockmeyer, and F. Catthoor. Memory Addressing Organization for Streambased Reconfigurable Computing. In 9th International Conference on Electronics, Circuits and Systems (ICECS), volume 2, pages 813–817, Dubrovnik, Croatia, 15–18 September 2002. IEEE. [15] B. Jacobs and J. Rutten. A Tutorial on (Co)Algebras and (Co)Induction. Bulletin of EATCS, 62:222–259, 1997. [16] G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda, C. Lopes, J. Loingtier, and J. Irwin. Aspect-Oriented Programming. In M. Aks¸it and S. Matsuoka, editors, 11th European Conference on Object-Oriented Programming (ECOOP), volume 1241 of Lecture Notes in Computer Science, pages 220–242, Jyv¨askyl¨a, Finland, 10 June 1997. Springer–Verlag. The paper originating AOP.

[17] P. Lysaght. Aspects of Dynamically Reconfigurable Logic. In Colloquium on Reconfigurable Systems, volume 61, pages 1/1–1/5, Glasgow, Scotland, UK, 10 March 1999. IEE. [18] J. Rutten. Automata and Coinduction (an Exercise in Coalgebra). In 9th International Conference on Concurrency Theory (CONCUR), volume 1466 of Lecture Notes in Computer Science, pages 194–218, Nice, France, 8–11 September 1998. Springer–Verlag. [19] M. Sihman and S. Katz. Superimpositions and aspectoriented programming. Computer Journal, 46(5):529–541, 2003. [20] P. Vinh. Formal Aspects of Dynamic Reconfigurability in Reconfigurable Computing Systems. PhD thesis, London South Bank University, 103 Borough Road, London SE1 0AA, UK, 4 May 2006. [21] P. Vinh and J. Bowen. Formalising Configuration Relocation Behaviours for Reconfigurable Computing. In SFP Workshop, FDL’02: Forum on Specification & Design Languages, Marseille, France, 24–27 September 2002. CDROM. [22] P. Vinh and J. Bowen. An Algorithmic Approach by Heuristics to Dynamical Reconfiguration of Logic Resources on Reconfigurable FPGAs. In 12th International Symposium on Field Programmable Gate Arrays, page 254, Monterey, CA, USA, 22–24 February 2004. ACM/SIGDA. [23] P. Vinh and J. Bowen. A Provable Algorithm for Reconfiguration in Embedded Reconfigurable Computing. In M. Hinchey, editor, 29th Annual IEEE/NASA Software Engineering Workshop (SEW), pages 245–252, Greenbelt, MD, USA, 6–7 April 2005. IEEE. [24] P. Vinh and J. Bowen. Continuity Aspects of Embedded Reconfigurable Computing. Innovations in Systems and Software Engineering: A NASA journal, 1(1):41–53, April 2005. Springer. [25] P. Vinh and J. Bowen. POM Based Semantics of RTL and a Validation Method for the Synthesis Results in Dynamically Reconfigurable Computing Systems. In J. Rozenblit, T. O’Neill, and J. Peng, editors, 12th Annual International Conference and Workshop on the Engineering of Computer Based Systems (ECBS), pages 247–254, Greenbelt, MD, USA, 4–5 April 2005. IEEE.

First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE'07) 0-7695-2856-2/07 $20.00 © 2007