Formalising Configuration Relocation Behaviours for Reconfigurable Computing Phan C. Vinh and Jonathan P. Bowen School of Computing, Information Systems and Mathematics South Bank University 103 Borough Road, London SE1 0AA, UK {Phanvc,bowenjp}@sbu.ac.uk

"All appropriate organizational approvals for the publication of this paper have been obtained. The author(s) will present the paper at the Forum."

Formalising Configuration Relocation Behaviours for Reconfigurable Computing Phan C. Vinh and Jonathan P. Bowen School of Computing, Information Systems and Mathematics South Bank University 103 Borough Road, London SE1 0AA, UK {Phanvc,bowenjp}@sbu.ac.uk

Abstract. Although the partially reconfigurable FPGA design is powerful if two different configurations were mapped at compile time to overlapping locations in the FPGA, only one of these configurations can be present in the array at any given moment. They cannot operate simultaneously. However, if somehow the final FPGA location can be determined at runtime, one or both of these overlapping configurations can be relocated to a new location that was previously unused to allow for simultaneous use. The configurations can be relocated by either rotation or shifting in an FPGA fabric. In this paper, our research has shown that the relocating configurations can be specified and reasoned formally by algebraic laws for checking whether a chip of given size and a given feasible schedule allow a feasible placement. Our examination is done on a generic partially reconfigurable FPGA and Ruby algebra is used to specify and reason in this case.

1 Motivation An Field-Programmable Gate Array (FPGA) typically consists of a regular rectangular grid of equal configurable cells (logic blocks) that allow the prototyping of simple logic functions together with t simple registers and with special routing resources, see Figure 1. A particular design is realized by customizing a configuration on new generations of y FPGAs becoming partitionable and dynamically reconfigurable, even partially. These chips, for example the Xilinx 6200 FPGA architecture, may support several independent or interdependent tasks and designs at a time, and parts of the chip can be reconfigured x quickly during run-time. Under these assumptions, a task, or module, may be Figure 1. An FPGA and a set of four represented by a cuboid, with two spatial modules (tasks), shown in ordinary 2dimensions, and one representing the time dimensional space and in 3of computation, see Figure 1. dimensional space-time However, even if the configuration time is short, the compilation time for constructing the configuration stream for a task is

still rather long. This diminishes the results that have been reported recently on online strategies for compiling and reconfiguring such devices. Important examples include speeding up computational problems in hardware by task compaction on hyper-cubes, or approaches to dynamic allocation of a sequence of tasks on an FPGA of given size by using heuristics to compact tasks in execution on the chip during runtime. We consider the defined problems MUL MUL MUL MUL t where a task set is given. We show how y V V V to extend this approach in order to deal W W with very restrictive constraints that are x MUL W MUL present in all practical instances. V V Typically, there are temporal t precedence constraints imposed on the ADD ADD y set of computing modules, since the V W output of one task may be needed as W x ADD V input for another task. Such a set of W precedence constraints may be described by a dependency graph, see Figure 2. Dependency graph of tasks and Figure 2. For problem instances of this shape of modules (3D boxes) with the type, there are some details in [5,6]. spatial dimensions x and y and the In this paper, we focus on formalising temporal dimension t (execution time) a feasible placement on chip with a given schedule. In this context, at a given time (value of t is a constant) the placement is processed in space of two spatial dimensions x and y. A rectilinear configuration consists of adjacent cell arrays arranged orthogonally on chip. When the configuration is relocated along with the spatial dimensions x and y the relevant cells of the configuration have to be relocated appropriately to that reconfiguration. 1

2

3

y

t

x

4

5

6

t

y

7

x

2 An Informal Description of Relocation of A Rectilinear Configuration Configurations can be relocated by either rotation or shifting in an FPGA fabric. Relocation behaviours will be formalised by using Ruby algebra for specification and reason. But before reaching the formalization the behaviours of relocation we should have a look on their following informal descriptions represented in [1]. Although the partially reconfigurable FPGA design is powerful, it faces limitations imposed by configuration locations determined at compile time. If two different configurations were mapped at compile time to overlapping locations in the FPGA, only one of these configurations can be present in the array at any given moment. They cannot operate simultaneously. However, if somehow the final FPGA location can be determined at runtime, one or both of these overlapping configurations can be shifted to a new location that was previously unused to allow for simultaneous use. Figure 3 illustrates a situation in which relocation can be applied. The darkly shaded mapping is already present on the FPGA. The lightly shaded mapping is a new mapping that is also to be placed on the FPGA. However, since the first and second configurations have several cell locations in common, they cannot both be present on a traditional partially reconfigurable FPGA simultaneously. However, an FPGA with

relocation ability can modify the second configuration to fit the unused space on the grid, thereby allowing both mappings to be present without one overwriting the other's information. Figure 3 shows the steps taken to relocate the second configuration to available cells.

Configuration Present on FPGA

Incoming Configuration

Conflicts

Reconfiguration

Figure 3: In some situations an incoming configuration maps to the same location as an existing configuration. If the incoming mapping is relocated, it may be possible to allow both configurations to be present and operational on the FPGA simultaneously.

3 Outline of this Paper In this paper, our research has indicated that the ability to relocate configurations mapped on an FPGA can be specified and reasoned formally by algebraic laws. This allows us to deduce some configuration relocation behaviours for reconfigurable computing but the original functionality of configuration is still preserved. The rest contents are organised as follows: In section 4 some requirements of relocating a configuration will be expressed. In section 5 the brief notations of Ruby algebra will be explained. In section 6 we will represent some rotation behaviours of configuration by the algebraic laws. In Section 7 the representation of configuration locations in a coordination system will be indicated. Based on the algebraic laws an illustration will also be showed for example in the section 8. And in the last section the relevant outcomes are summarised.

4 Requirements of Cells in a Rectilinear Configuration The hardware-mapped configuration relocation is seen to consist of its behaviours of rotation and shifting. In rotation, each configuration has all eight distinct permutations of its structure with altering its orientation and they are illustrated in Figure 4. These permutations can be composed from combinations of three distinct primitive movements: a rotation of 90o, a vertical flip and a horizontal flip. With combinations of these movements, any movement shown in Figure 4 can be achieved. In shifting, we simply use the offset operations to shift vertically or horizontally the entire configuration to a new location without altering its orientation. When relocating a configuration, in order to its function being still preserved some following requirements must be met: Firstly, the routing programmed into each cell must be changed to reflect the overall rotation or flip of the configuration. Each cell in a mapping can have routing to and from its four immediate neighbour cells that must be maintained relative to those neighbours when the mapping is moved. For example, if a cell routes to its neighbour to the east and a horizontal flip is performed, the original cell must now

route to that same neighbour which is now found to its west. Alternately, a cell that routes to a cell to the north and belongs to a configuration that is then rotated 90o clockwise would be changed to route to the east. Secondly, a cell must also be shifted by the same horizontal and vertical offsets as the entire configuration being relocated. Additionally, each cell must maintain its position relative to the others so that all routes between cells are preserved. In the rotation example given previously, the northern neighbour must be moved so as to become the eastern neighbour to preserve the correct routing structure. Thirdly, the relative routing between cells within a configuration must remain intact. The reconfiguration hardware can operate on a cell-by-cell basis, changing input and output directions based on the movement or movements being performed. This can be performed using either combinational logic or lookup tables. Performing translation (shift) operations also involves very little computation. The row and column offsets are simply added to the original row and column addresses of each individual cell. No other movements are required for this operation on our idealised FPGA. Finally, the relative position of a cell within a configuration must be maintained. While this is easy in a shift operation where the offset is simply applied to all cells within the configuration, it is more complex for the rotate and flip operations. These complex movements are easiest to conceptualise as operations performed on one large object. In actuality, however, this one large object is made up of many smaller objects. Each of these must be altered to a different degree in order to preserve the original larger object after the movement is complete. In our case, the large object is the full configuration, and the smaller objects are the discrete FPGA cells that form that configuration. Although all of the cells may be flipped or rotated to the same degree as the configuration itself, they each have their own particular offsets to move in order to preserve the relative arrangement between cells within the configuration.

Original Rotate 90o Configuration

Flip Vertical & Horizontal

Flip Vertical & Horizontal & Rotate 90o

Flip Horizontal Flip Horizontal Flip Vertical & Rotate 90o

Flip Vertical & Rotate 90o

Figure 4. The seven primary permutations of a configuration

5 Concepts of Ruby Algebra To capture information about architecture and behaviour we advocate a hardware description notation that can express topological information. There already exists a hardware description language called Ruby [2] that allows behaviour and layout to be elegantly expressed, resulting in powerful architectural descriptions such as in [3,4] particularly. Topologically, a basic Ruby component is a tile that consists of four edges, namely East (e), West (w), South (s) and North (n). The tile is a physical abstraction of the concrete layout of some circuit. By working at a suitably abstract level, many

analyses and descriptions are simplified. The layout abstractions that Ruby provides map easily onto FPGA hardware. The behaviour of the component contained within the tile is described by specifying binary relations between the signals on the edges. The connections on the West and North edges are interpreted as belonging to the domain domain of the relation, and the n connections on the East and South edges are interpreted as belonging to the range of the relation. w e R The circuit contained within the cell may be as simple as a routing element or s a two input combinational gate, or as range complicated as a microprocessor. In this abstract level, tuples are used to represent Figure 5. A Ruby tile composite edges instead of signals in syntax that its semantics is still preserved. To demonstrate how Ruby can be used to describe a simple combinational circuit, we represent the behavioural description of a Ruby tile in Figure 5 by the following Ruby syntax: R() =

or

R

The domain values are represented by a pair (using angle brackets) where the first element is the signal value on the West edge, and the second element is the signal value on the North edge. The range is also represented by a pair, where the first element describes the South edge signals, and the second element describes the East edge signals. Circuit layout and behaviour can be composed as in Figure 6. The combinatory beside («) places one circuit R horizontally beside another S. The two circuits R and S communicate through their East and West edges respectively. A circuit can also be placed below another circuit with below written as b (communication through the North and South edges of R and S respectively). The semantics of these combinators describe the composite circuit behaviours by forming the relational conjunction of the constituent relations S R

S R

Syntax: >R «S<,eS> Semantics: $ i=eR=wS. R & S

Syntax: <,nS>>RbP> Semantics: $ i=nR=sS. R & S

Figure 6. Syntax and semantics describe the composite circuit layouts and behaviours

6 Representation of Rotations 6.1 Definition Suppose that components of hardware-mapped configurations, posed one after one in row or in column, are written respectively as follows: (1) rowi =1¸n Ri = def R1 « R2 « ... « Rn

(2) col j =1¸ m R j = def R1 b R2 b ... b Rm then that configuration can be defined by S( rowi =1¸n Ri , col j =1¸ m R j ), i.e. a system of rowi =1¸n Ri and col j =1¸ m R j composes up the configuration and we also define the

followings: (3) (rowi =1¸ n Ri )rev = def Rn « Rn -1 « ... « R1

(

)rev = def

(4) col j =1¸ m R j

Rm b Rm -1 b ... b R1

in order to describe the reversion of rows and columns, respectively. 6.2 Properties

From the previous definition some following properties can reach intuitively. (1) (rowi =1¸n Ri ) « Rn +1 = rowi =1¸ n +1 Ri (2) Rn +1 « (rowi =1¸ n Ri )rev = (rowi =1¸ n +1 Ri )rev

(

)

(3) col j =1¸ m R j b Rm +1 = col j =1¸m +1 R j (4) Rm +1 b col j =1¸ m R j

)rev = (col j =1¸m+1R j )rev

(5) (rowi =1¸ n Ri )rev

= rowi =1¸n Ri

( (6) ((col (7) ((row (8) ((col

(

j =1¸ m

) R ) )

rev rev

j

i =1¸ n Ri

i =1¸ n Ri

rev

= col j =1¸m R j

)rev « (row j =1¸m S j )rev )

rev

)rev b (col j =1¸m S j )

)

rev rev

(

)

= row j =1¸ m S j « (rowi =1¸n Ri )

(

)

= col j =1¸ m S j b (coli =1¸ n Ri )

(9) rowi =1¸n col j =1¸ m Rij = col j =1¸ m rowi =1¸ n R ji 6.3 Primitive Laws

From arguments of section 4, we can show three below basic laws of rotation intuitively. Let S( rowi =1¸n Ri , col j =1¸ m R j ) be an original configuration and without losing its generality we can consider the number of rows and columns that they are equal, that is n=m. (i) Law R90: Rotate 90o Describing the rotate 90o movement of original configuration in clockwise and from original locations we have the following transformation:

R90(rowi =1¸n Ri ) = (col i =1¸ n R90( Ri ) )rev

(1 )

R90(col i =1¸n Ri ) = rowi =1¸ n R90( Ri )

(2 )

(ii) Law H: Flip horizontal Describing the horizontal flip movement of original configuration and from original locations we come to the new locations by the transformation: H (rowi =1¸n Ri ) = (rowi =1¸ n H ( Ri ) )rev

(3 )

H (col i =1¸ n Ri ) = col i =1¸ n H ( Ri )

(4 )

(iii) Law V: Flip vertical Describing the vertical flip movement of original configuration that reaches the new locations by the transformation: V (rowi =1¸n Ri ) = rowi =1¸nV ( Ri )

(5 )

V (col i =1¸n Ri ) = (col i =1¸nV ( Ri ) )rev

(6 )

Laws of R90, H and V describe three basic movements of the clockwise rotation of 90o, horizontal flip and vertical flip. We can derive five further laws from them in order to describe the movements of rotation based on the original locations. In the below subsection the contents of relevant laws will be deducted. 6.4 Derived Laws

(iv) Law VH: Flip vertical and horizontal VH (rowi =1¸ n Ri ) = (rowi =1¸ nVH ( Ri ) )rev

(7 )

VH (col i =1¸ n Ri ) = (col i =1¸ nVH ( Ri ) )rev

(8 )

(v) Law VHR90: Flip vertical, horizontal and rotate 90o VHR90(rowi =1¸ n Ri ) = col i =1¸ nVHR90( Ri ) VHR90(col i =1¸ n Ri ) = (rowi =1¸ nVHR90( Ri ) )rev

(9 ) (10)

(vi) Law HR90: Flip horizontal and rotate 90o HR90(rowi =1¸n Ri ) = col i =1¸ n HR90( Ri )

(11)

HR90(col i =1¸n Ri ) = rowi =1¸ n HR90( Ri )

(12)

(vii) Law VR90: Flip vertical and rotate 90o VR90(rowi =1¸ n Ri ) = (col i =1¸ nVR90( Ri ) )rev

(13)

VR90(col i =1¸ n Ri ) = (rowi =1¸ nVR90( Ri ) )rev

(14)

The laws from (iv) to (vii) can be easily proven by applying the primitive laws (i)(iii). In addition, we can see that any composite movement that can be built from composition of some smaller movements, for example law VHR90 can reach from laws VH and R90. In general, the below Table 1 shows the mutual relations among the movements described by laws. For example, if applying twice law R90 on original configuration to reach a new configuration that it is equivalent of application of laws V and H; in other words, R90{R90{S(row, col)}} = V{H{S(row, col))}} and it is showed at the intersection of row R90 and column R90 in Table 1. Orig R90 VH VHR90 H HR90 V VR90

R90 VH VHR90 Orig HR90 V VR90 H

VH VHR90 Orig R90 V VR90 H HR90

VHR90 Orig R90 VH VR90 H HR90 V

H HR90 V HR90 Orig VHR90 VH R90

HR90 V VR90 V R90 Orig VHR90 VH

V VR90 H VR90 VH R90 Orig VHR90

VR90 H HR90 H VHR90 VH R90 Orig

Table 1. Table describes the mutual relations of rotation

7 Representation of Locations As mentioned in section 4, one of the requirements posed that the relative position of a cell within a configuration must be maintained. While this is easy in a shift operation where the offset is simply applied to all cells within the configuration, it is more complex for the rotate and flip operations. These complex movements are easiest to conceptualise as operations performed on one large object. In actuality, however, this one large object is made up of many smaller objects. Each of these must be altered to a different degree in order to preserve the original larger object after the movement is complete. In our case, the large object is the full configuration, and the smaller objects are the discrete FPGA cells that form that configuration. Although all of the cells may be flipped or rotated to the same degree as the configuration itself, they each have their own particular offsets to move in order to preserve the relative arrangement between cells within the configuration. Here we consider the relation of new locations with original after the configuration rotation was done.

7.1 Definition

Let Ã(r,c) be a geometric location used to represent the upper-left location of configuration on chip, and it is illustrated as in Figure 7. For given Ã(r,c), let ÃR90(r,c), ÃVH(r,c), ÃVHR90(r,c), ÃH(r,c), ÃHR90(r,c), ÃV(r,c) and ÃR90(r,c) describe the configurations after rotating of R90, VH, VHR90, H, HR90, V and VR90 respectively. 0

0

0

c

Original Configuration

r

r

0

c

0

Flip Horizontal

Flip Horizontal & Rotate 90 o

Flip Vertical & Horizontal & Rotate 90 o

r

0

0

c

r

c

Flip Vertical & Horizontal

r

Rotate 90 o

c

r

0

c

c

r

Flip Vertical

c

r

Flip Vertical & Rotate 90 o

Figure 7. The geometric location determines the locations of the configuration rotations

7.2 Transformations of Location

We can easily show the algebraic transformations of location after rotating a configuration in the below Table 2. Let Ã(r,c) be a geometric location for describing an original configuration and the location of its cell is denoted by x(r, c)=(rx,cx). In general, therefore, for given the location of any cell x(r, c) then after rotation its new location is x’(r, c)= (rx’,cx’). Actually, the locations of configuration are changed in bound of an array whose size is maxrow ´ maxcol. Ã ÃR90 ÃVH ÃVHR90 ÃH ÃHR90 ÃV ÃVR90 Ã ÃR90 ÃVH ÃVHR90 ÃH ÃHR90

rx’=rx cx’=cx

rx’ = cx cx’+rx= maxcol

rx’ = cx cx’+rx= maxcol

rx’= rx cx’=cx

rx’+ rx= cx’+cx= maxcol cx’=rx rx’+cx= maxrow rx’=rx cx’+cx= maxcol rx’+cx= cx’+rx= maxcol

rx’=cx cx’+rx= maxcol rx’+rx= cx’+cx= maxcol rx’+cx= cx’+rx= maxcol cx’=cx rx’+rx= maxrow

rx’+rx= maxrow cx’+cx = maxcol rx’= cx cx’+rx= maxcol rx’= rx cx’=cx rx’= cx cx’+rx= maxcol cx’=cx rx’+rx= maxrow rx’=cx cx’=rx

cx’= rx rx’+cx= maxrow

rx’ = rx cx’+cx= maxcol

rx’+rx= maxrow cx’+cx= maxcol rx’= cx cx’+rx= maxcol rx’= rx cx’=cx

rx’+cx= maxrow cx’+rx= maxcol cx’=cx rx’+rx= maxrow rx’= cx cx’=rx

rx’= cx cx’=rx

rx’= rx cx’=cx

rx’=rx cx’+cx= maxcol

rx’= cx cx’+rx= maxcol

rx’+cx= maxrow cx’+rx= maxcol cx’=cx rx’+rx= maxrow

cx’ = cx rx’+rx= maxrow

rx’= cx cx’=rx

rx’=cx cx’=rx

rx’= rx cx’+cx= maxcol

rx’=cx cx’=rx

rx’=rx cx’+cx= maxcol rx’+cx= cx’+rx= maxcol rx’+rx= cx’+cx= maxcol rx’=cx cx’+rx= maxcol

rx’+cx= cx’+rx= maxcol cx’=cx rx’+rx= maxrow cx’= rx rx’+cx= maxrow rx’+rx= cx’+cx= maxcol

rx’= rx cx’+cx= maxcol rx’=cx cx’+rx= maxcol rx’=rx cx’=cx

ÃV ÃVR90

cx’=cx rx’+rx= maxrow rx’=cx cx’=rx

rx’=cx cx’=rx rx’=rx cx’+cx= maxcol

rx’=rx cx’+cx= maxcol rx’+cx= cx’+rx= maxcol

rx’+cx= cx’+rx= maxcol cx’=cx rx’+rx= maxrow

rx’+rx= cx’+cx= maxcol cx’= rx rx’+cx= maxrow

rx’=cx cx’+rx= maxcol rx’+rx= cx’+cx= maxcol

rx’= rx cx’=cx rx’=cx cx’+rx= maxcol

rx’=cx cx’+rx= maxcol rx’=rx cx’=cx

Table 2. Table describes the absolute location of cells after rotation

8 An Illustration With the ability to do the three basic movements of V, H, and R90 and the operations of vertical offset and horizontal offset, any reconfiguration of a cell mapping is possible in our idealised FPGA. Table 3 details the transformation equations for relocating that configuration following their relative and absolute locations. Old Location New Location

(

)rev )

Vertical flip

S( rowi =1¸n Ri , col j =1¸ m R j )

S( rowi =1¸ nV ( Ri ), col j =1¸ mV ( R j )





Horizontal flip

S( rowi =1¸n Ri , col j =1¸ m R j )

S( (rowi =1¸n H ( Ri ) )rev , col j =1¸ m H ( R j ) )





o

S( rowi =1¸n Ri , col j =1¸ m R j )

S( (coli =1¸ n R90( Ri ) )rev , row j =1¸ m R90( R j ) )

S( rowi =1¸n Ri , col j =1¸ m R j )

S( rowi =1¸n Ri , col j =1¸ m R j )





S( rowi =1¸n Ri , col j =1¸ m R j )

S( rowi =1¸n Ri , col j =1¸ m R j )





Rotate 90

Vertical offset (by n) Horizontal offset (by m)

Table 3. The transformation equations determine the relative and absolute location of cells

However, We have known that the three basic movements of V, H and R90 can compose up to VHR90 as an single composite movement so we can use VHR90 instead of V, H and R90 serially in some applications of relocation pipeline, thus the new relative and absolute location will become S( coli =1¸ nVHR90( Ri ) ,

(row j =1¸mVHR90( R j ))rev ) and
x

, rx > respectively. These transformations

can be illustrated in Figure 8.

9 Conclusions We formalised the specification and reason of configuration relocations in the generic partially reconfigurable FPGA. We considered that configurations can be relocated by either rotation or shifting in an FPGA. This allows us to deduce some configuration relocation behaviours for reconfigurable computing and the original functionality of configuration is still preserved. Our examination is done on a generic partially reconfigurable FPGA and to capture information about the configuration

architecture and behaviour we advocate a hardware description notation that can express topological information. Ruby algebra is used to specify and reason in this case, it allows behaviour and layout to be elegantly expressed, resulting in powerful architectural descriptions. Finally, based on some algebraic laws a relevant illustration is showed for example. Incoming configuration

Outgoing configuration

Relocation pipeline V

H

R90

Vertical offset

Horizont al offset

Stepwise changes

Figure 8. The relocation pipeline for relocation of configuration

References [1]K. Compton, J. Cooley, S. Knol and S. Hauck. Configuration Relocation and Defragmentation for FPGAs, IEEE Symposium on Field-Programmable Custom Computing Machines, 2000 [2]Mary Sheeran and Geraint Jones. Circuit Design in Ruby. Formal Methods for VLSI Design. J. Staunstrup (editor). North-Holland, 1990. [3]Satnam Singh. Architectural Descriptions for FPGA Circuits. FCCM’95, 1995 [4]Shaori Guo and Wayne Luk. An Integrated system for developing regular array designs, Journal of Systems Architecture 47 (2001), pp. 315-337. [5]Jurgen Teich, Sandor P. Fekete and Jorg Schepers, Optimising Dynamic Hardware Reconfigurations, ZPR Technical Report 98-336, Mathematics Institute, University of Koln,1998. [6]Sandor P. Fekete and Jorg Schepers, On more-dimensional packing I: Modelling, ZPR Technical Report 97-288, Mathematics Institute, University of Koln,1997.