• No results found

We have already shown that the amount of necessary reconfiguration depends on the differences between device configurations, i.e. on the element-wise differences between d(ni) and d(nj), ni, nj ∈ NT. In order to model the device reconfigura-tion depending on these differences, we introduce the Reconfigurareconfigura-tion State Graph (RSG) model. The RSG is a digraph G(NT,ET). In this model, the active configura-tion is associated with a task n from a setNTof possible tasks. A possible change at runtime from the active configuration, associated with task ni∈NTto a new con-figuration, associated with task nj∈NTis described by a directed edge (ni, nj)∈ET. An example RSG is shown in Figure 3.2.

The transition between the RSG states, or the equivalent reconfiguration, is per-formed by loading new configuration data into the device. There are as many dif-ferent reconfigurations as edges in an RSG. If the RSG is complete, i.e. there exists an edge between each possible pair of nodes, the number of possible transitions is

|ET| = |NT|(|NT| − 1).

3.2. Reconfiguration State Graph 51

C B

A

Reconfiguration

Configuration

Figure 3.2: A reconfiguration state graph example. The edge from A to C represents the reconfiguration of the device from configuration A to C. The node C symbolizes the new configuration of the device after the reconfiguration is complete.

Each state n∈NTin the RSG is associated with a device configurationd(n) = (d(n)1,d(n)2, . . . ,d(n)m), that is active in the device’s configuration memory when the state n is the active state. Here, we assume that the configurationdconsists of m individually reconfigurable elements, e.g. configuration frames. The vector element d(n)k, k = 1 . . . m describes the configuration data for the reconfigurable element k.

Each transition e = (ni, nj)∈ETin the RSG requires a change in the active de-vice configuration, i.e. the active configuration changes fromd(ni) tod(nj). This exchange of configuration data causes runtime reconfiguration cost that can be de-scribed with the reconfiguration costte(e). The RSG and the device configuration is illustrated in Example 3.1.

Example 3.1 Consider the transition from state nito njwith the device configurations d(ni) = (6, 5, 3, 7, 3) andd(nj) = (6, 5, 2, 7, 5). In order to perform partial reconfig-uration, the configuration of the elements k =3 and k = 5 must be changed, causing reconfiguration cost ofte((ni, nj)) = 2 elements.

ni (ni, nj) nj

d(ni) = (6, 5, 3, 7, 3) d(nj) = (6, 5, 2, 7, 5) r(ni, nj) = (0, 0, 1, 0, 1)

Figure 3.3: Illustration of Example 3.1.

In order to quantify the reconfiguration cost te, we define a reconfiguration bitmapr : ET 7→ {0, 1}m, wherer(e = (ni, nj)) = (r(e)1,r(e)2, . . . ,r(e)m) describes which of the reconfigurable elements have to be reconfigured in order to realize the transition e∈ ET. An elementr(e)k = 1 denotes that new configuration data d(nj)kmust be loaded into the device’s configuration memory at position k. In the RSG model, it is assumed that for a state n the configuration of all m reconfigur-able elements is specified. We further assume that each reconfigurreconfigur-able element can be reconfigured independently. Hence,r(ni, nj) can be derived from the difference between the configuration data of both configurationsd(ni) andd(nj):

r((ni, nj))k=

1 ifd(ni)k6=d(nj)k

0 otherwise . (3.1)

Now, we define the reconfiguration costte(e) for a transition e as follows:

te(e) = Xm k=1

wt(k)r(e)k, (3.2)

where the termwt(k) denotes the reconfiguration cost of element k.

3.2.1 Reconfiguration Time Overhead

Based on the RSG G(NT,ET) and the reconfiguration costte(e) for a single transition e∈ET, we define the total reconfiguration time t.

Definition 3.1 The total reconfiguration time t is the sum of reconfiguration costs over all transitions e∈ETin G:

t =X

e∈ET

te(e). (3.3)

The total reconfiguration time t describes the reconfiguration cost that occur if all transitions in G are performed once. The measure represents the time overhead at runtime associated with partial reconfiguration. The total reconfiguration time can be normalized in order to describe the average time per reconfiguration:

t = t

|ET|. (3.4)

It provides a reasonable measure to compare different implementations of reconfig-urable applications in terms of reconfiguration runtime overhead.

3.2.2 Dynamic Configuration Data Overhead

The time required to reconfigure a device is only one aspect of the reconfiguration overhead. Another one is the amount of configuration data that must be available at system runtime. In FPGAs the amount of configuration data can be huge and hence, is usually stored in external memory. Here we introduce a measure that en-ables us to determine how much data must be available at runtime. We determine the amount of data for the configurations independent of each other. Moreover, we assume that the device is initialized with a configuration n∈NTat system start-up.

Together with the initial configuration, all fully static configuration data is loaded.

The amount of fully static configuration data is neglected here, because it is neces-sary in any case.

At first, consider all reconfigurations represented by the edges e ∈ET,nwhich lead to configuration n were ET,n :={e ∈ ET : e = (n, n), n ∈NT}. At runtime, any configuration data that changes on any transition e ∈ET,n must be available.

3.2. Reconfiguration State Graph 53

Applied to the configuration n it means that for any reconfigurable element k which is configured with new data on any transition e∈ET,n, the configuration datad(n)k are required. Overall, the element k in the reconfiguration bitmapr(n) indicates what configuration datad(n)kmust be present at runtime for a configuration n. The reconfiguration bitmapr(n) is now defined as:

r(n)k= _

e∈ET,n

r(e)k. (3.5)

Subsequently, the configuration sizesn(n) for a configuration n is defined as:

sn(n) = Xm k=1

ws(k)r(n)k, (3.6)

wherews(k) denotes the configuration size of the element k. The computation of the configuration sizesn(n) is illustrated next:

Example 3.2 Consider an RSG with the reconfiguration bitmapsr((n1, n3)) = (0, 0, 1, 1, 0) andr((n2, n3)) = (0, 1, 1, 0, 0). According to Equation 3.5, the reconfiguration bitmap evaluates tor(n3) = (0, 1, 1, 1, 0) and hence withws= 1, the configuration size yieldssn(n3) = 3.

Now, we are able to define the total configuration size s:

Definition 3.2 The total configuration size s is the sum of the configuration sizes for all configurations n∈NTthat are required at runtime for dynamic reconfiguration:

s = X

n∈NT

sn(n). (3.7)

Similar to the reconfiguration time, the total configuration size can also be nor-malized in order to describe the average amount of data required to store the dy-namic partof a configuration:

s = s

|NT|. (3.8)

The reconfiguration bitmapr(n) determines which elements k of a configuration are dynamic at runtime. Moreover, if the RSG is a complete graph, then the recon-figuration bitmapsr(n) are equal for all n∈NT: The reconfiguration bitmapr(n)k can only be 0 if all reconfiguration bitmapsr((n, n))kare 0, too. This is only true if the configuration datad(n)k=d(n)kfor all n, n∈NT. Otherwise, ifd(n)k6=d(n′′)k then at leastr((n, n))k= 1 orr((n′′, n))k= 1 and hence, in any caser(n)k= 1.

Although external memory in reconfigurable systems is inexpensive today, the amount of storage needed for configuration data impacts the external memory size, the system’s memory bandwidth, the system’s energy consumption and the size of

on-chip caches for configuration data. Therefore, the total configuration size must be reduced to allow for more efficient reconfigurable systems.

In the following we will use the RSG model to compute reconfiguration cost for both, binary configuration data and structural design representations.