As presented in section 4.1, there are different approaches to control adjustment. The benefit of using run-time reconfiguration to realise structural or parametric control adjustments can be analysed depending on the kind of adjustment. We distinguish two cases:
1. A system is controlled by a set of algorithms with different structures, where only one structure is active at any given time.
2. A system is controlled by a set of algorithms with a single structure, whose parameters are to be changed in run-time
To the first case belong active adjustment approaches such as projection methods, switched control, or fault hiding (cf. section 4.1). To the second case belong adaptive control approaches such as gain scheduling (cf. figure 4.1). When implementing these control-adjustments using reconfigurable hardware, run-time reconfiguration can be used to improve resource utilisation. The resulting resource allocation when using RTR depends on the control period, the reconfiguration time, and the placement approach, as presented in the next section.
4.3.1 Structure Adaptation
Let C ={c1,c2, ...,cn} be a set of n controllers with different structures, used to control a given plant. A controller ci∈C occupies a set of si∈SFPGA resources
(e.g., slices, BRAMs, embedded multipliers). Thus the set of resource requirements for allncontrollers∈Cis given byS={s1,s2, ...,sn}. Furthermore, each controller ci∈C requires initialization resources ui when it is activated, which is given by U ={u1,u2, ...,un}. Besides the controllers, additional hardware resources Aconst might be required, e.g., for transmitting and processing data from and to the I/Os.
Furthermore, each controllerci∈Chas a reaction timetri, which is the time required by a controller to become operative. For controllers that are reconfigured in run-time, reaction time is given by equation 4.2.
tri=tcon fi+initi (4.2) wheretcon fi is the reconfiguration time required for the ith controller, and initi is its initialization time. For a static implementation tri is neglected, because all required controllers are instantiated concurrently. The resource requirements of a static implementation is thus given by equation 4.3.
Astatic =Aconst+
n i=1
∑
(si+ui) (4.3)
If run-time reconfiguration is used, there are four possible resource-utilisation scenarios, depending on the reaction time of the controller and the placement approach (cf. section 4.2.4). Iftriis longer than the control period of theithcontroller (pi), the to-be-replaced controller has to stay configured until the new one has been loaded and initialised. However, iftri<pi, then the reconfigurable area of the old controller can be used for the new one, or for its initialization routine (ui). If the reconfigurable system architecture is build using a fixed-size slot approach, the size of all PR Regions (an thus the size of the partial bitstreams of all controllers) is defined by the amount of resources used by the largest controller. In fact, the required area depends on the amount of configuration frames that suffice to realise the largest controller. This area can be larger than the area requirements of the controller itself. Therefore, the worse case resource utilisation is given by equation 4.4.
Adynamic_FS=
(2·smax1+Aconst+Arec, iftrmax1< pmax1;
3·smax1+Aconst+Arec, iftrmax1> pmax1; (4.4) Where smax1 is the area requirements of the largest controller cmax1∈C. Corre-spondingly, trmax1 is the reaction time of that controller, and pmax1 is the control period. Furthermore,Arecrepresents the resources required to realise partial recon-figuration, e.g., for the communication infrastructure, and for the reconfiguration controller. Equation 4.4 is exemplified in figure 4.13.
If a free placement approach is used, then the required reconfigurable area depends on the size of each controller. Here again, the minimal amount of configuration frames
is what defines the size of each controller . Thus, the worse case resource utilisation is given by equation 4.5.
Adynamic_FP=
(smax1+umax1+Aconst+Arec, iftrmax1< pmax1;
smax1+smax2+umax1+Aconst+Arec, iftrmax1> pmax1; (4.5) Wheresmax2 is the area requirements of the second largest controllercmax2∈C.
Correspondingly,trmax2 is the reaction time of that controller, and pmax2is the control period.
C C
c2
C C
tconf2
u2
c1
init2
p1 p2 p2
tr2
a
PRR1 PRR2
t
t
Area
c2
c1
PRR1
PRR2
t
Area
tconf2
u2
init2
tr2
PRR3
(a)
(b)
Active Reconfiguration Initialisation
Figure 4.13: Resource utilisation as described in both cases of equation 4.4 Both cases of equation 4.4 are exemplified in figure 4.13. The first axis represents time, showing time events. The second and third axis represent the area utilisation of the PR Regions through time. In the first axis C represents the time where a control output is generated, p1and p2 are the control periods of controllersc1 and c2, respectively. Finally, a represents a reconfiguration request. In figure 4.13(a)
the reaction timetr2of the new controller is shorter than the control periodp1= p2. Because a fixed-size slot approach is used, the worst-case resource utilisation is given byAdynamic_FS=PRR1+PRR2+Aconst+Arec. In figure 4.13(b) the reaction timetr2 of the new controller is longer than the control periodp1=p2. Therefore, the worse case resource utilisation is given byAdynamic_FS =PRR1+PRR2+PRR3+Aconst+ Arec. From this example, it can be observed that the reaction time of a controller has a great influence on the worst case utilisation scenario when using RTR. A dynamic implementation leads to a better resource utilisation than a static approach (e.g., RTR enables to use a small FPGA device in contrast to a static approach), if the setCis large enough, so thatAstatic>AdynamicFS, orAstatic>AdynamicFP.
4.3.2 Parameter Adaptation
When one single control structure is required, whose parameters are adapted, two realisations are possible: a general structure, where parameters can be loaded as required, and several specific structures, which can be exchanged using dynamic reconfiguration. A specific implementation requires less resources, because hardware dedicated to load new parameters are no longer used. Furthermore, the difference regarding resource-requirements between a specific and a general implementation increases when considering the case of a structure, whose parameter sets have zero components (e.g., spare matrixes). In those cases the zero components would not be realised in a specific implementation. Moreover, in a specific realisation, the word-length can be optimised to each parameter set.
Let us take a vector multiplication as example. Figure 4.14 shows the implemen-tation of a vector multiplier as a parameterisable structure (a), and as a constant multiplier (b).
The resource utilisation of both structures when increasing the number of inputs, and using 8 bits as a base word-length is presented in figure 4.15. It can be noticed, that a specific implementation requires much less resources than a general structure.
Using dynamic reconfiguration, a specific implementations can be exchange in run time according to the requirements, avoiding the use of a general structure.
This approach is suited for control structures such as state-feedback regulators, or state-observers (cf. section 3.5.2 and 3.5.3 respectively), which have typically a large number of parameters to be changed in case of a control adaptation.
To analyse the resource utilisation, let us first definePAR={par1,par2, ...,parn} as the set of n parameter-groups for a control structure. When implementing a general structure, i.e., allowing parameter changes (cf. figure 4.14(a)), the resource requirements,Bstatic, are given by equation 4.6.
Bstatic=Bgeneral+Bconst (4.6)
(a) Parametrisable Vector Multiplier (b) Constant Vector Multiplier +
+
+
Input 1
Input 2
Input n X
X
x x x
+ +
+
Parameter_en
Data_in
Input 1
Input 2
Input n
reg
reg
reg Control Logic
X
Figure 4.14: Schematic of a vector multiplier: specific implementation vs. general implementation
5 10 15 20 25 30
200 300 400 500 600 700 800 900 1000 1100
Vector Size
Slices
Resource Utilisation of Vector Multiplication
general specific
Figure 4.15: Resource utilisation of vector multiplier: specific implementation vs.
general implementation based on a Virtex II FPGA (XCV4000)
whereBgeneral represents hardware resources required for a parameterisable struc-ture, and Bconst represents additional hardware resources, required for instance to
process I/O signals. In the case of a constant parameters implementation the resource requirements is given byA={α1,α2, ...,αn}, for all pari∈PAR. Furthermore, each specific implementation requires initialization resourcesγiwhen it is activated, which is given byΓ={γ1,γ2, ...,γn}. To allow dynamic reconfiguration of the specific con-trollers, dedicated resources are required, symbolised byBrec. The reaction time of theithspecific realisationαiis given by equation 4.7.
tr_si=tcon f_si+init_si (4.7) wheretcon f_siis the reconfiguration time of theithspecific realisation, andinit_si is its initialization time. In this case there are again four possible cases of resource utilisation scenarios. If the reconfigurable system architecture is build using a fixed-size slot approach (cf. section 4.2.4), the fixed-size of all fixed slots is defined by the amount of resources used by the largest specific implementationαmax1. Thus the worse case resource utilisation is given by equation 4.8.
Bdynamic_FS=
(2·αmax1+Bconst+Brec, iftr_smax1< p_smax1;
3·αmax1+Bconst+Brec, iftr_smax1> p_smax1; (4.8) wheretr_smax1is the reaction time of the largest specific realisation (cf. equation 4.7), and p_smax1 is its control period. If a free placement approach is used, the worst-case resource utilisation is given by equation 4.9.
Bdynamic_FP= (
αmax1+γmax1+Bconst+Brec, iftr_smax1< p_smax1; αmax1+αmax2+γmax1+Bconst+Brec, iftr_smax1> p_smax1;
(4.9) Whereγmax1is the FPGA area required for the initialization routine of the largest specific controller, and αmax2 is the area required for the second largest specific controller.
A dynamic implementation leads to a better resource utilisation than a static realisa-tion when the number of parameters, which have to be exchange is sufficiently large (cf. figure 4.15). This means that the resource required to realise a general control structure have to be such thatBstatic>BdynamicFSorBstatic>BdynamicFP.