- Email: [email protected]
Discrete Control for Reconfigurable FPGA-based Embedded Systems*
4th IFAC Workshop on Dependable Control of Discrete Systems The International Federation of Automatic Control September 4-6, 2013. University of York, York, UK
Discrete Control for Reconfigurable FPGA-based Embedded Systems ? Xin An ∗ Eric Rutten ∗ Jean-Philippe Diguet ∗∗ Nicolas le Griguer ∗∗ Abdoulaye Gamati´ e ∗∗∗ ∗
INRIA, Grenoble, France (e-mail: [email protected]) Lab-STICC, Lorient, France (e-mail: [email protected]) ∗∗∗ LIRMM, Montpellier, France (e-mail: [email protected])
∗∗
Abstract: This work presents an application of discrete controller synthesis (DCS) techniques to a class of dynamically reconfigurable embedded computing systems, and contributes to the general approach of control for feedback computing. We propose a general model for applications defined as data-flow graphs of computing tasks, and target execution architectures that are dynamically partially reconfigurable Field Programmable Gate Arrays (FPGAs). We define our model in terms of parallel automata. Then, we encode relevant scheduling and control requirements in terms of a DCS problem w.r.t. multiple constraints and objectives. We take into account the system reconfiguration overhead, and the resulting controller is able to make decisions by foreseeing their impact on future requests. We validate our approach by using the BZR programming language and Sigali tool for modelling and simulations, with a video processing system implementation on a specific FPGA platform. Keywords: Discrete Controller Synthesis, Control of Computing, Synchronous Languages, Hardware Architectures, Dynamically Partially Reconfigurable FPGA 1. DISCRETE FEEDBACK COMPUTING ON FPGA Application domain: feedback computing. Recently in Computer Science, the notion of adaptive or autonomic computing systems has been introduced (Kephart and Chess (2003)) and defined as computing systems that can reconfigure themselves through feedback loops. Such a feedback loop takes monitoring information as input, updates a representation of the monitored system, and decides to reconfigure the monitored system if necessary. Such feedback loops are often designed using continuous control techniques (Hellerstein et al. (2004)). Another significant approach addresses synchronization and coordination problems using discrete control techniques (Wang et al. (2010); Boyer et al. (2012)). Considered problem: executions of task graphs on FPGAs. We consider the discrete control of a class of embedded systems based on FPGAs, which brings significant constraints, typically in time and energy optimizations. System applications are defined by task graphs, and target execution architectures are a special kind of hardware circuits: dynamically partially reconfigurable (DPR) FPGA (Lysaght et al. (2006)). Such FPGAs have multiple reconfigurable areas, and have the ability to combine and reconfigure some of them at run-time to execute tasks without interrupting the activities of the rest. For the systems we target, task graphs should be executed on the FPGA by reconfiguring its areas according to task requests and resource availability. A runtime reconfiguration support is required to answer task requests by choos? This work is supported by the French ANR project Famous.
978-3-902823-49-6/2013 © IFAC
ing at runtime the best suiting implementations w.r.t. given objectives and environment. Such a support should be able to predict the impacts of its decisions on the future (Santambrogio (2010)). Besides, reconfiguration overheads cannot be ignored and must be taken into account. Due to the relative novelty of DPR technologies, the reconfiguration management is usually addressed by using manual encoding and analysis in existing approaches, which is tedious and error-prone (G¨ohringer et al. (2008)). Automatic techniques are thus required to better address this problem, with the foreseeable increase in complexity. Adopted approach: DCS. We propose an approach to solve the above runtime control issue by formalizing it as a DCS problem. We do so by proposing a general model of such systems, which is decomposed into models of the possible behaviors of the application (task graph), the FPGA (a set of reconfigurable areas), and the task implementations on FPGA areas. In terms of supervisory control (Cassandras and Lafortune (2008)), this is the model of the plant. Separately, we specify properties which should be satisfied by the controlled system. They define general correctness issues (e.g., exclusive access to FPGA resources) as well as non-functional aspects such as minimizing power consumption. These models are specified in terms of Labelled Transitions Systems (LTS) equipped with a synchronous composition operator, and cost functions associated with their states and transitions. Our approach is based on a specification and programming language called BZR 1 (Delaval et al. (2010)), associated with a DCS tool Sigali (Marchand et al. 1
151
http://bzr.inria.fr
10.3182/20130904-3-UK-4041.00017
2013 IFAC DCDS September 4-6, 2013. York, UK
(2000)). The BZR compiler can generate executable code for simulations and integrations with concrete systems. 2. MODELING FORMALISM AND TOOLS We adopt a framework defined in details elsewhere (Dumitrescu et al. (2010)). We recall briefly the definitions of LTS’s and their parallel composition, and the DCS operations that will be used in the remainder of this paper. 2.1 Modeling formalism An LTS is a tuple S =< Q, q0 , I, O, T >, where Q is a finite set of states, q0 is the initial state of S, I is a finite set of input events, O is a finite set of output events, and T is the transition relation that is a subset of Q × Bool(I) × O∗ × Q, such that Bool(I) is the set of Boolean expressions of I and O∗ is the power set of O. g/a
Each transition, denoted by q −−→ q 0 , has a label of the form g/a, where guard g ∈ Bool(I) must be true for the transition to be taken, and action a ∈ O∗ is a conjunction of output events, emitted when the transition is taken. State q is the source of the transition, and state q 0 is the destination. A path is a sequence of transitions denoted by gi /ai
gi+1 /ai+1
gi+k−1 /ai+k−1
p = qi −−−→ qi+1 −−−−−−→ ... −−−−−−−−−−→ qi+k , where ∀j, i ≤ j ≤ i + k − 1, ∃(qj , gj , aj , qj+1 ) ∈ T . The composition of two LTS’s put in parallel is the synchronous composition, denoted by ||. Given two LTS’s Si =< Qi , qi,0 , Ii , Oi , Ti >, i = 1, 2, with Q1 ∩ Q2 = ∅, their composition is defined as follows: S1 ||S2 =< Q1 × Q2 , (q1,0 , q2,0 ), I1 ∪ I2 , O1 ∪ O2 , T >, where T = g1 ∧g2 /a1 ∧a2
g1 /a1
g2 /a2
{(q1 , q2 ) −−−−−−−−→ (q10 , q20 )|q1 −−−→ q10 ∈ T1 , q2 −−−→ q20 ∈ T2 , g1 ∧g2 ∧a1 ∧a2 }. Composed state (q1 , q2 ) is called a macro state, where q1 and q2 are its two component states. The states/transitions of LTS’s can be associated with weights, characterising corresponding quantitative features. We define a cost function C : Q → N to map each state of an LTS to a positive integer cost value. Costs can also be defined on execution paths across an LTS. For instance, a cost function of path p can be defined as the sum of all the costs of its traversed states. When composing LTS’s, the cost values w.r.t. the resulting global states/transitions can be defined on the basis of the local costs as their sum or the maximal/minimal value. 2.2 Discrete controller synthesis Discrete Controller Synthesis (DCS), emerged in the 80’s (Ramadge and Wonham (1989)), is an automatic technique that allows to use constructive methods to ensure desired properties on the system behavior. DCS is an operation that applies on a transition system (originally uncontrolled), where inputs I is partitioned into two subsets: Iu and Ic , representing respectively the uncontrollable and controllable variable sets. It is applied with a given control objective: a property that has to be enforced by control. The objective is expressed in terms of the system’s outputs. The controller is obtained automatically from an LTS and an objective, both specified by a user, via appropriate algorithms (Marchand et al. (2000)) that we will use without describing them in detail here. Its 152
purpose is to constrain the values of controllable variables, in function of outputs and uncontrollable inputs, such that all remaining behaviors satisfy the given objective. The controller is maximally permissive in the sense that it allows the largest possible set of correct behaviors. The paper uses techniques corresponding to different algorithms to synthesize controllers (Marchand and Samaan (2000)) for: invariance w.r.t. a subset of states, reachability of a subset of states, one-step optimization of a cost on the next state, and path optimization of a cost of the bounded path to a target state (Dumitrescu et al. (2010)). 2.3 Modeling and simulation tools The LTS modelling formalism has been implemented in tools for modeling, programming and simulation. We use the reactive data-flow language BZR (Delaval et al. (2010)), which encapsulates the DCS tool Sigali (Marchand et al. (2000)) in its compilation process. The representation of the system dynamics is done by describing the possible behaviors of each component in terms of automata. The controllable variables are identified, and the control objective to be enforced by the behaviors is given in the form of what we call a contract, defined in terms of predicates on the variables, with the possible addition of observers. Users can use this mixed imperative/declarative style and the BZR compilation that involves DCS to produce automatically a controller. It guarantees the resulting controlled automaton satisfying the invariance property, i.e., the subset of states where it holds is made invariant for the transition system, by constraining the values of the controllable variables. For control objectives other than invariance ones, such as reachability and optimal control objectives, we use directly Sigali. The users can benefit from DCS without mastering its formal technique. bzr-node-name contract equations and automata assume A enforce E in
with c
out
node body: equations and automata
Fig. 1. BZR node with a contract. Figure 1 introduces the simplified graphical syntax for a programming unit, called a node, with a contract in the BZR language. The basic node structure is inherited from the Heptagon language 2 . A BZR program, which is itself a node, is structured as a graph of data-flow nodes. Each one has input and output flows and can have local flows. The body of the node describes how input flows are transformed into output flows, in the form of a set of equations and/or automata. They are evaluated, all together at each step of a reactive system (hence the composition is called synchronous), by taking all inputs, computing the transitions, and producing the outputs. 3. DPR FPGA CONTROL PROBLEM We present informally, through examples, the class of DPR FPGAs for which we will solve the control problem. 2
http://synchronics.wiki.irisa.fr/
2013 IFAC DCDS September 4-6, 2013. York, UK
3.1 Hardware architecture We consider a multiprocessor architecture implemented on an FPGA (e.g., Xilinx Zynq device), which is composed of a general purpose processor A0 (e.g., ARM Cortex A9), and a reconfigurable area divided into four tiles: A1–A4 (see Figure 2(0)). The communications between architecture components are achieved by a Network-onChip (NoC). Reconfigurable tiles can be combined and configured to implement and execute application tasks by loading predefined bitstreams. A1
task B
task B
A2
as used reconfigurable tiles (rs), configuration costs (cc) and execution costs (ec). Configuration costs indicate the overhead caused by configuring the architecture before running tasks, while execution costs represent those generated by executing tasks on the architecture. Typical configuration and execution costs include time and energy consumptions. For example, two implementations A1 , A2 of given task A have respectively: 1) rs1 = {A1}, cc1 = 50, ec1 = 200; 2) rs2 = {A1 + A2}, cc2 = 80, ec2 = 150. Among the possible task implementations, a controller is in charge of choosing the best implementation at runtime according to system objectives.
or A3 0)
task C
task A
A4 1)
3.4 System reconfiguration
task C
2)
3)
Fig. 2. Configurations and reconfigurations. The architecture is also equipped with a battery supplying the platform with energy. Regarding power management, an unused reconfigurable tile Ai can be put into sleep mode with a clock gating mechanism such that it consumes a minimum static power. 3.2 Application software We consider system functionality described as a directed, acyclic task graph (DAG), where at least one task can appear more than once. A DAG consists of a set of nodes representing the set of tasks to be executed, and a set of directed edges representing the precedence constraints between tasks. Considering the execution of such an application on an FPGA can better exhibit the control problem connected to the reconfiguration overhead impact. If a task is loaded and would be executed again in the future according to the DAG, the controller can then choose either keeping it loaded in order to avoid reconfiguration costs, or re-using the area it occupies for other tasks. Figure 3 shows the example application consisting of four tasks, where task A runs twice. B
Figure 2 shows three system configuration examples annotated from 1 to 3. In configuration 1, task A is running on tiles A3 and A4 while tiles A1 and A2 are set to the sleep mode. Configurations 2 and 3 show two possible scenarios with tasks B and C running in parallel. Once task A finishes its execution according to the graph of Figure 3, the system can go to either configuration 2 or configuration 3 depending on the system requirements. For example, if the current state of the battery level is low, the system would choose configuration 2 as configuration 3 requires the complete FPGA working surface and therefore consumes more power. 3.5 System objectives System objectives define its functional and non-functional requirements. Typical system objectives are as follows: 1) ensuring exclusive uses of reconfigurable tiles by tasks; 2) switching tiles to sleep mode when executing no task; 3) switching tiles to active mode when executing task(s); 4) bounding the costs of system configurations according to battery levels; 5) enforcing system execution termination once started; 6) minimizing the costs of system configurations; 7) minimizing overall system execution costs.
A
A
D
4. FORMALIZING FPGA CONTROL
C
Fig. 3. DAG specification of an application. In the framework, we suppose each task performs its computation with the following four control points: • • • •
being requested or invoked; being executed w.r.t. a choice of implementation; notifying execution finish, once it reaches its end; being kept loaded or configured, after having finished.
Occurrences of control points being requested and notifying execution finish depend on runtime situations, and are thus uncontrollable. The way that tasks being executed and whether they are kept loaded after executions are available controllable points for a controller aiming to achieve system objectives.
We specify the modelling of the computing system behaviour and control in terms of LTS’s. System objectives are defined based on the models. We focus on the management of computations on the reconfigurable tiles and dedicate processor area A0 exclusively to the resulting controller. 4.1 Architecture behavior The architecture (see Section 3.1) consists of processor A0, four reconfigurable tiles {A1, A2, A3, A4} and a battery. Each tile has two operating modes, and the mode switches RMi c_ai
acti = false c_ai Slei
3.3 Task implementation a) Given a hardware architecture, a task can be implemented in various ways characterised by various parameters, such 153
not c_ai
Acti acti = true
BM down
down
acti
up
b)
H st=h
down M
up
st=m
L up
st=l
Fig. 4. Models RMi for tile Ai, and BM for battery.
st
2013 IFAC DCDS September 4-6, 2013. York, UK
TMA Sdl
eB/rA
eA,eB,eC,eD I
req/rA
A
eA/rB,rC
A,C
eC
B
eC/rD
eA and eC/rD
D
eC
eB and eC/rA
B,C
rA e A
C
eA
req
A
eD
rA,c1 X1 eA,c1
eB/rA
a)
c2
eA,c1 c1
rA,c2
c1,c2
T rA,rB,rC,rD
eA/rD
I
eA,c2
b)
rA,c1
rA,c1 L1
rA,c2 L2
X2
es
eA,c2 rA,c2
Fig. 5. Models for a) the scheduler Sdl and b) a task A: T MA are controllable. Figure 4(a) gives the model of the behaviour of tile Ai. The mode switch action between Sleep (Sle) and Active (Act) depends on the value of the Boolean controllable variable c ai . The output acti represents its current mode. The battery behaviour is given in Figure 4(b). It has three states labelled: H (high), M (medium) and L (low). Its inputs come from a battery sensor, which emits up and down level events, and its output st represents the current battery level. 4.2 Application behavior The software application is described as a DAG: we capture its behaviour by systematically defining a scheduler automaton which can be constructed algorithmically from the DAG. The algorithm transforming a DAG to an automaton can be found in (An et al. (2013)). It represents all possible execution scenarios, by keeping track of execution states and emitting the start requests of tasks in reaction to the finish notifications. Figure 5(a) shows the scheduler automaton of the application in Figure 3. It starts the execution of the application by emitting event rA , which requests the start of task A, upon the receipt of application request event req in the idle state I. Upon the receipt of event eA notifying the end of A’s execution, events rB and rC are emitted together to request the execution of tasks B and C in parallel denoted by state (B, C). At state (B, C), there are three possible transitions: task B ends denoted by eB before task C, task C ends denoted by eC before task B, and tasks B and C end at the same time, leading respectively to three states (A, C), (B) and (A). Task A is requested again (i.e., rA is emitted) once task B ends. For states (A, C), (B) and (A), the transitions are constructed similarly. Task D is not requested until the execution of both A and C is finished, i.e., the reception of events eA and eC . It reaches the final state (T ), implying the end of the application execution, upon the receipt of event eD . 4.3 Task execution model Behavior. In consideration of the four control points of task executions (see Section 3.2), the execution behaviour of task A associated with two implementations (see Section 3.3) can be modelled as in Figure 5(b). Such a model can be derived systematically from a list of task implementations. It features an initial idle state I, two executing and loaded state pairs (X1 , L1 ) and (X2 , L2 ) corresponding to the two different implementations. Each loaded state Li corresponds to an executing state Xi , meaning that their 154
corresponding task implementation has been configured in this state, and can be executed directly, i.e., go to state Xi , without the need to reconfigure. Controllable variables c1 , c2 are integrated in the model to encode controllable points: being executed and kept loaded. From idle state I, upon the receipt of start request rA , task A goes to one executing state Xi , i ∈ {1, 2} depending on the value of controllable variable ci leading to Xi . Li can only be reached from idle state I through its corresponding executing state Xi , meaning that the task has finished its execution in Xi (i.e., eA is received), and remains configured on the corresponding occupied surface. From state Li , once the task is requested again, it can either go to state Xi and be executed directly without being configured, or be configured in some new way and executed accordingly (i.e., go to state Xj , i 6= j). From state Li , it can also go to state I if the controller at some moment decides to release its occupied surface for the use of other tasks. When the task ends, denoted by ei , from an executing state Xi , it might go to state I as well instead of state Li depending on the values of controllable variables, e.g., its occupied tiles are taken by other tasks. Local execution costs. The execution costs of different task implementations are different. Three cost parameters are considered (see Section 3.3). We capture them by associating cost functions denoted by a tuple (rs, cc, ec) with the states of task models, where: rs ∈ 2RA (the occupied set of architecture resources), cc ∈ N (configuration cost value), and ec ∈ N (execution cost value). We now define the costs according to three types of states: • idle state has values rs = ∅, cc = 0, ec = 0; • loaded state Li : rs = rsi , cc = 0, ec = 0; • executing state Xi : rs = rsi , cc = 0 or cci , ec = eci . rsi represents the occupied resource set of the task implementation that corresponds to the loaded and executing state. rs has value rsi for loaded states, as a task that is kept loaded still occupies the corresponding resources. The cost values of cc and ec for idle and loaded states are 0, as configuration and execution costs can only be induced after a task is requested (i.e., reception of r). The cost values cci and eci corresponding to a task implementation should thus be evaluated to the corresponding cost functions of executing states. However, the configuration cost of an executing state Xi is not always equal to the corresponding cci , but can also be 0 when the task has been configured and is executed directly. Therefore, regarding the task execution model in Figure 5(b), function cc of Xi should be defined in consideration of its previous states.
2013 IFAC DCDS September 4-6, 2013. York, UK
It is evaluated to 0 if its previous state is Li , i.e., at the moment the task is requested, it has been configured. Otherwise, it is evaluated to cci , i.e., the task has to be configured before executed. Take state X1 in Figure 5(b) as an example, it has three incoming edges from states I, L1 and L2 . The configuration cost cc is equal to 0 if it is reached from state L1 , and cc1 if reached from I or L2 . 4.4 Global system model Global behavior. The parallel composition of control models for reconfigurable tiles RM1 -RM4 , battery BM and tasks T MA -T MD , plus scheduler Sdl defines the system model: S = RM1 ||...||RM4 ||BM ||T MA ||...||T MD ||Sdl with initial state q0 = (Sle1 , ..., Sle4 , H, IA , ..., ID , I). It represents all the possible system execution behaviours in the absence of control (i.e., a runtime controller is not yet integrated). Each execution behaviour corresponds to a complete path, which starts from initial state q0 and reaches one of the final states: Qf = (q(RM1 ), ..., q(RM4 ), q(BM ), IA , ..., ID , T ), where q(Id) denotes an arbitrary state of automaton Id. Global costs. The costs defined locally in each task execution model need to be combined into global costs. Costs on states. A system state q is a composition of local states, and we define its cost from the local task states (denoted by qA , ..., qD ) as follows: • used resources: union of the Sused resources of all tasks in this state, i.e., rs(q) = rs(qi ), i = {A, B, C, D}; • full cost on state: this indicates the overall cost the system takes in the current state, and is defined as the sum P of all task configuration and execution costs: f c(q) = (cc(qi ) + ec(qi )), i = {A, B, C, D}. Costs on paths. We also need to define the cost functions on paths so as to compute the cost of system executions. gi /ai
gi+1 /ai+1
gi+k−1 /ai+k−1
Given path p = qi −−−→ qi+1 −−−−−−→ ... −−−−−−−−−−→ qi+k , and full costs of system states, we define overall cost on path p as P sum of full costs on the states along the path, i.e., oc(p) = f c(qj ), i ≤ j ≤ i + k; 4.5 System objectives We distinguish two types of system objectives: logical and optimal ones, and describe them in terms of the states, and the costs defined on the states or paths of the model. Logical control objectives. For any system state q, we want to enforce the following: (1) exclusive usage of reconfigurable tiles by tasks: T ∀qi , qj ∈ q, i 6= j, that rs(qi ) rs(qj ) = ∅; (2) switch tile Ai to sleep mode, when executing no task: @qi ∈ q, Ai ∈ rs(qi ) ⇒ acti = f alse; (3) switch tile Ai to active mode when executing task(s): ∃qi ∈ q, Ai ∈ rs(qi ) ⇒ acti = true; (4) battery-level constrained costs (given threshold values V0 , V1 , V2 ): f c(q) < V0 (resp. V1 and V2 ) when battery level is high (resp. medium and low); (5) reachability: ∃q ∈ Qf that is reachable. 155
Optimal control objectives. Such objectives can be further classified into two types of objectives: one-step optimal and optimal control on path objectives. We use pseudo functions max and min in the following to represent the maximization and minimization objectives, respectively. One-step optimal objectives. Such objectives aim to minimise or maximise costs associated with states and/or transitions in a single step (Marchand and Samaan (2000)). We consider the following objective w.r.t. current state q: (6) minimize full costs in next states: min(f c, q). Objectives regarding optimal control on paths. Such objectives aim to drive the system from the current state to the target states Qf at the best cost (Dumitrescu et al. (2010)). We consider the following objective, w.r.t. current state q and the set of final states Qf : (7) minimize overall costs: min(oc, q, Qf ). 5. BZR ENCODING AND DCS Given the system graphical models and objectives of Section 4, this section describes the controller synthesis by using BZR and the DCS tool Sigali. BZR encoding of the system model. The automaton encoding of system components in Section 4 can be translated to textual encoding easily. The global system behaviour can then be encoded by composing all these models. Finally, the costs on system states are defined as described in Section 4.4. The BZR code is not detailed here, due to space limitation. We refer the readers to An et al. (2013) for more details. Enforcing control objectives. BZR contracts are able to directly encode the logical control objectives of Section 4 except for Objective 5. Due to space limitations, they are not given here. Taking as input the system model and the contract, the BZR compiler can synthesise a controller (in C or Java code) automatically satisfying the defined objectives. There is also a graphical tool enabling users to perform simulations of the controlled system by combining the controller with the system model. Optimal control objectives and Objective 5 can be addressed by combining BZR and Sigali. In this case, the BZR compiler serves as the front end to encode system behaviour, and produces an intermediate file. The optimal control objectives can then be encoded and integrated into this file, which feeds the Sigali tool. The DCS is finally performed by Sigali to automatically generate a controller. The generated controller can also be combined with the system model by the BZR compiler for simulations. 6. EXPERIMENTAL VALIDATION We consider a video processing system implemented on a platform containing an FPGA to visualise and validate the runtime reconfigurations of the FPGA controlled by our synthesized controller. The system consists of a camera capturing images, a dispatcher feeding image pixels to the platform, a compositor aggregating pixels produced by the FPGA, and a screen displaying the processed images. Each captured image is
2013 IFAC DCDS September 4-6, 2013. York, UK
divided into 9 areas, and the processing of each area is taken care of by one reconfigurable FPGA tile. There are three filtering algorithms (namely red, yellow and blue ones) that can be implemented on reconfigurable tiles to process images. When configured to process the same image, they are evaluated with different configuration and execution costs. Three objectives are considered: 1) different image areas are of different colours, 2) full costs are bounded by a maximum value, and 3) the full costs of next states are minimized. Following the design flow in Section 4, the C code of the runtime manager was firstly generated (which takes around 5 seconds with BZR). We then integrate it with the video processing system and implement it on an ML605 board from Xilinx. The board includes a Virtex-6 FPGA, an external DDR3 memory, etc. An Avnet extension card (DVI I/O FMC Module) with 2 HDMI connectors (In and Out) has been plugged onto the platform so that it can receive and send video streams through the connectors. Frame9processing
Microblaze
PR2
PR3
PR4
PR5
PR6
PR7
PR8
PR9
Mem.9Bus
Processor9Local9Bus
CF9controller
Interrupt controller
GPIO9switchs
DDR39Memory
ICAP
PR1
GPIO9buttons
Fig. 6. Global structure of the implementation Figure 6 illustrates the global structure of our implementation. We have divided the FPGA surface into two kinds of regions: static and reconfigurable. The latter is divided into nine reconfigurable tiles in charge of the video processing. A 32-bit soft-core microblaze processor is synthesised on the static region to execute the computed manager and the management of the configuration bitstreams. The external DDR 3 memory is used to buffer the video frame pixel data, and store the software executable to be launched by the microblaze. A compact flash card is used to store the bitstreams of the filter implementations on each reconfigurable tile. The C code of the manager is deployed on the microblaze as an infinite loop. Once invoked, it is able to read the input and computes out a new configuration. The microblaze then selects the appropriate bitstreams from the compact flash card, and sends them to the ICAP to reconfigure the nine reconfigurable tiles. A number of tests on the implementation have shown that the three system objectives are achieved. 7. CONCLUSION FPGA-based embedded systems require a runtime controller to answer task execution requests by choosing at runtime the best suited implementations w.r.t. system objectives and environment. Such a controller should take into account reconfiguration overhead, and be able to predict the impact of its decisions on future. This paper presented a discrete controller synthesis (DCS) based design flow to address this problem. System behaviors 156
are modeled by using parallel automata, and the runtime controller computation is formalized as a DCS problem. A programming language and synthesis tool are used to automatically perform the DCS. An experimental validation of our proposal has been performed by implementing a video processing system on a Xilinx FPGA platform. In future work, we will enrich our models by taking into account other aspects, such as communication costs; and exploit the modular synthesis and compilation (Delaval et al. (2010)) to anticipate possible scalability issues. REFERENCES An, X., Rutten, E., Diguet, J.P., Le Griguer, N., and Gamati´e, A. (2013). Autonomic Management of Reconfigurable Embedded Systems using Discrete Control: Application to FPGA. Rapport de recherche RR-8308, INRIA. URL http://hal.inria.fr/hal-00824225. Boyer, F., Delaval, G., de Palma, N., Gruber, O., and Rutten, E. (2012). Discrete supervisory control application to computing systems administration. In Proceedings of the 14th IFAC Symp. on Information Control Problems in Manufacturing (INCOM’12). Cassandras, C. and Lafortune, S. (2008). Introduction to Discrete Event Systems. Kluwer Academic Publishers. Delaval, G., Marchand, H., and Rutten, E. (2010). Contracts for modular discrete controller synthesis. In Conf. on Languages, Compilers, and Tools for Embedded Systems, 57–66. URL http://bzr.inria.fr. Dumitrescu, E., Girault, A., Marchand, H., and Rutten, E. (2010). Multicriteria optimal discrete controller synthesis for fault-tolerant tasks. In Workshop on Discrete Event Systems (WODES), 356–363. G¨ohringer, D., M.H¨ ubner, V.Schatz, and J.Becker (2008). Runtime adaptive multi-processor system-onchip: RAMPSoC. In Symp. on Parallel & Distributed Processing, 1–7. Hellerstein, J., Diao, Y., Parekh, S., and Tilbury, D. (2004). Feedback Control of Computing Systems. Wiley. Kephart, J.O. and Chess, D.M. (2003). The vision of autonomic computing. IEEE Computer, 36(1), 41–50. Lysaght, P., Blodget, B., Mason, J., Young, J., and Bridgford, B. (2006). Invited paper: Enhanced architectures, design methodologies and cad tools for dynamic reconfiguration of xilinx fpgas. In Field Programmable Logic and Applications, 2006 (FPL’06), 1–6. Marchand, H. and Samaan, M. (2000). Incremental design of a power transformer station controller using a controller synthesis methodology. IEEE Trans. on Soft. Eng., 26(8), 729 –741. Marchand, H., Bournai, P., Le Borgne, M., and Le Guernic, P. (2000). Synthesis of discrete-event controllers based on the Signal environment. Discrete Event Dynamic System: Theory and Applications, 10(4). Ramadge, P. and Wonham, W. (1989). On the supervisory control of discrete event systems. Proc. IEEE, 77(1). Santambrogio, M.D. (2010). From reconfigurable architectures to self-adaptive autonomic systems. International Journal of Embedded Systems, 4(3), 172–181. Wang, Y., Cho, H., Liao, H., Nazeem, A., Kelly, T., Lafortune, S., Mahlke, S., and Reveliotis, S.A. (2010). Supervisory control of software execution for failure avoidance: Experience from the gadara project. In Workshop on Discrete Event Systems (WODES).
Discrete Control for Reconfigurable FPGA-based Embedded Systems ? Xin An ∗ Eric Rutten ∗ Jean-Philippe Diguet ∗∗ Nicolas le Griguer ∗∗ Abdoulaye Gamati´ e ∗∗∗ ∗
INRIA, Grenoble, France (e-mail: [email protected]) Lab-STICC, Lorient, France (e-mail: [email protected]) ∗∗∗ LIRMM, Montpellier, France (e-mail: [email protected])
∗∗
Abstract: This work presents an application of discrete controller synthesis (DCS) techniques to a class of dynamically reconfigurable embedded computing systems, and contributes to the general approach of control for feedback computing. We propose a general model for applications defined as data-flow graphs of computing tasks, and target execution architectures that are dynamically partially reconfigurable Field Programmable Gate Arrays (FPGAs). We define our model in terms of parallel automata. Then, we encode relevant scheduling and control requirements in terms of a DCS problem w.r.t. multiple constraints and objectives. We take into account the system reconfiguration overhead, and the resulting controller is able to make decisions by foreseeing their impact on future requests. We validate our approach by using the BZR programming language and Sigali tool for modelling and simulations, with a video processing system implementation on a specific FPGA platform. Keywords: Discrete Controller Synthesis, Control of Computing, Synchronous Languages, Hardware Architectures, Dynamically Partially Reconfigurable FPGA 1. DISCRETE FEEDBACK COMPUTING ON FPGA Application domain: feedback computing. Recently in Computer Science, the notion of adaptive or autonomic computing systems has been introduced (Kephart and Chess (2003)) and defined as computing systems that can reconfigure themselves through feedback loops. Such a feedback loop takes monitoring information as input, updates a representation of the monitored system, and decides to reconfigure the monitored system if necessary. Such feedback loops are often designed using continuous control techniques (Hellerstein et al. (2004)). Another significant approach addresses synchronization and coordination problems using discrete control techniques (Wang et al. (2010); Boyer et al. (2012)). Considered problem: executions of task graphs on FPGAs. We consider the discrete control of a class of embedded systems based on FPGAs, which brings significant constraints, typically in time and energy optimizations. System applications are defined by task graphs, and target execution architectures are a special kind of hardware circuits: dynamically partially reconfigurable (DPR) FPGA (Lysaght et al. (2006)). Such FPGAs have multiple reconfigurable areas, and have the ability to combine and reconfigure some of them at run-time to execute tasks without interrupting the activities of the rest. For the systems we target, task graphs should be executed on the FPGA by reconfiguring its areas according to task requests and resource availability. A runtime reconfiguration support is required to answer task requests by choos? This work is supported by the French ANR project Famous.
978-3-902823-49-6/2013 © IFAC
ing at runtime the best suiting implementations w.r.t. given objectives and environment. Such a support should be able to predict the impacts of its decisions on the future (Santambrogio (2010)). Besides, reconfiguration overheads cannot be ignored and must be taken into account. Due to the relative novelty of DPR technologies, the reconfiguration management is usually addressed by using manual encoding and analysis in existing approaches, which is tedious and error-prone (G¨ohringer et al. (2008)). Automatic techniques are thus required to better address this problem, with the foreseeable increase in complexity. Adopted approach: DCS. We propose an approach to solve the above runtime control issue by formalizing it as a DCS problem. We do so by proposing a general model of such systems, which is decomposed into models of the possible behaviors of the application (task graph), the FPGA (a set of reconfigurable areas), and the task implementations on FPGA areas. In terms of supervisory control (Cassandras and Lafortune (2008)), this is the model of the plant. Separately, we specify properties which should be satisfied by the controlled system. They define general correctness issues (e.g., exclusive access to FPGA resources) as well as non-functional aspects such as minimizing power consumption. These models are specified in terms of Labelled Transitions Systems (LTS) equipped with a synchronous composition operator, and cost functions associated with their states and transitions. Our approach is based on a specification and programming language called BZR 1 (Delaval et al. (2010)), associated with a DCS tool Sigali (Marchand et al. 1
151
http://bzr.inria.fr
10.3182/20130904-3-UK-4041.00017
2013 IFAC DCDS September 4-6, 2013. York, UK
(2000)). The BZR compiler can generate executable code for simulations and integrations with concrete systems. 2. MODELING FORMALISM AND TOOLS We adopt a framework defined in details elsewhere (Dumitrescu et al. (2010)). We recall briefly the definitions of LTS’s and their parallel composition, and the DCS operations that will be used in the remainder of this paper. 2.1 Modeling formalism An LTS is a tuple S =< Q, q0 , I, O, T >, where Q is a finite set of states, q0 is the initial state of S, I is a finite set of input events, O is a finite set of output events, and T is the transition relation that is a subset of Q × Bool(I) × O∗ × Q, such that Bool(I) is the set of Boolean expressions of I and O∗ is the power set of O. g/a
Each transition, denoted by q −−→ q 0 , has a label of the form g/a, where guard g ∈ Bool(I) must be true for the transition to be taken, and action a ∈ O∗ is a conjunction of output events, emitted when the transition is taken. State q is the source of the transition, and state q 0 is the destination. A path is a sequence of transitions denoted by gi /ai
gi+1 /ai+1
gi+k−1 /ai+k−1
p = qi −−−→ qi+1 −−−−−−→ ... −−−−−−−−−−→ qi+k , where ∀j, i ≤ j ≤ i + k − 1, ∃(qj , gj , aj , qj+1 ) ∈ T . The composition of two LTS’s put in parallel is the synchronous composition, denoted by ||. Given two LTS’s Si =< Qi , qi,0 , Ii , Oi , Ti >, i = 1, 2, with Q1 ∩ Q2 = ∅, their composition is defined as follows: S1 ||S2 =< Q1 × Q2 , (q1,0 , q2,0 ), I1 ∪ I2 , O1 ∪ O2 , T >, where T = g1 ∧g2 /a1 ∧a2
g1 /a1
g2 /a2
{(q1 , q2 ) −−−−−−−−→ (q10 , q20 )|q1 −−−→ q10 ∈ T1 , q2 −−−→ q20 ∈ T2 , g1 ∧g2 ∧a1 ∧a2 }. Composed state (q1 , q2 ) is called a macro state, where q1 and q2 are its two component states. The states/transitions of LTS’s can be associated with weights, characterising corresponding quantitative features. We define a cost function C : Q → N to map each state of an LTS to a positive integer cost value. Costs can also be defined on execution paths across an LTS. For instance, a cost function of path p can be defined as the sum of all the costs of its traversed states. When composing LTS’s, the cost values w.r.t. the resulting global states/transitions can be defined on the basis of the local costs as their sum or the maximal/minimal value. 2.2 Discrete controller synthesis Discrete Controller Synthesis (DCS), emerged in the 80’s (Ramadge and Wonham (1989)), is an automatic technique that allows to use constructive methods to ensure desired properties on the system behavior. DCS is an operation that applies on a transition system (originally uncontrolled), where inputs I is partitioned into two subsets: Iu and Ic , representing respectively the uncontrollable and controllable variable sets. It is applied with a given control objective: a property that has to be enforced by control. The objective is expressed in terms of the system’s outputs. The controller is obtained automatically from an LTS and an objective, both specified by a user, via appropriate algorithms (Marchand et al. (2000)) that we will use without describing them in detail here. Its 152
purpose is to constrain the values of controllable variables, in function of outputs and uncontrollable inputs, such that all remaining behaviors satisfy the given objective. The controller is maximally permissive in the sense that it allows the largest possible set of correct behaviors. The paper uses techniques corresponding to different algorithms to synthesize controllers (Marchand and Samaan (2000)) for: invariance w.r.t. a subset of states, reachability of a subset of states, one-step optimization of a cost on the next state, and path optimization of a cost of the bounded path to a target state (Dumitrescu et al. (2010)). 2.3 Modeling and simulation tools The LTS modelling formalism has been implemented in tools for modeling, programming and simulation. We use the reactive data-flow language BZR (Delaval et al. (2010)), which encapsulates the DCS tool Sigali (Marchand et al. (2000)) in its compilation process. The representation of the system dynamics is done by describing the possible behaviors of each component in terms of automata. The controllable variables are identified, and the control objective to be enforced by the behaviors is given in the form of what we call a contract, defined in terms of predicates on the variables, with the possible addition of observers. Users can use this mixed imperative/declarative style and the BZR compilation that involves DCS to produce automatically a controller. It guarantees the resulting controlled automaton satisfying the invariance property, i.e., the subset of states where it holds is made invariant for the transition system, by constraining the values of the controllable variables. For control objectives other than invariance ones, such as reachability and optimal control objectives, we use directly Sigali. The users can benefit from DCS without mastering its formal technique. bzr-node-name contract equations and automata assume A enforce E in
with c
out
node body: equations and automata
Fig. 1. BZR node with a contract. Figure 1 introduces the simplified graphical syntax for a programming unit, called a node, with a contract in the BZR language. The basic node structure is inherited from the Heptagon language 2 . A BZR program, which is itself a node, is structured as a graph of data-flow nodes. Each one has input and output flows and can have local flows. The body of the node describes how input flows are transformed into output flows, in the form of a set of equations and/or automata. They are evaluated, all together at each step of a reactive system (hence the composition is called synchronous), by taking all inputs, computing the transitions, and producing the outputs. 3. DPR FPGA CONTROL PROBLEM We present informally, through examples, the class of DPR FPGAs for which we will solve the control problem. 2
http://synchronics.wiki.irisa.fr/
2013 IFAC DCDS September 4-6, 2013. York, UK
3.1 Hardware architecture We consider a multiprocessor architecture implemented on an FPGA (e.g., Xilinx Zynq device), which is composed of a general purpose processor A0 (e.g., ARM Cortex A9), and a reconfigurable area divided into four tiles: A1–A4 (see Figure 2(0)). The communications between architecture components are achieved by a Network-onChip (NoC). Reconfigurable tiles can be combined and configured to implement and execute application tasks by loading predefined bitstreams. A1
task B
task B
A2
as used reconfigurable tiles (rs), configuration costs (cc) and execution costs (ec). Configuration costs indicate the overhead caused by configuring the architecture before running tasks, while execution costs represent those generated by executing tasks on the architecture. Typical configuration and execution costs include time and energy consumptions. For example, two implementations A1 , A2 of given task A have respectively: 1) rs1 = {A1}, cc1 = 50, ec1 = 200; 2) rs2 = {A1 + A2}, cc2 = 80, ec2 = 150. Among the possible task implementations, a controller is in charge of choosing the best implementation at runtime according to system objectives.
or A3 0)
task C
task A
A4 1)
3.4 System reconfiguration
task C
2)
3)
Fig. 2. Configurations and reconfigurations. The architecture is also equipped with a battery supplying the platform with energy. Regarding power management, an unused reconfigurable tile Ai can be put into sleep mode with a clock gating mechanism such that it consumes a minimum static power. 3.2 Application software We consider system functionality described as a directed, acyclic task graph (DAG), where at least one task can appear more than once. A DAG consists of a set of nodes representing the set of tasks to be executed, and a set of directed edges representing the precedence constraints between tasks. Considering the execution of such an application on an FPGA can better exhibit the control problem connected to the reconfiguration overhead impact. If a task is loaded and would be executed again in the future according to the DAG, the controller can then choose either keeping it loaded in order to avoid reconfiguration costs, or re-using the area it occupies for other tasks. Figure 3 shows the example application consisting of four tasks, where task A runs twice. B
Figure 2 shows three system configuration examples annotated from 1 to 3. In configuration 1, task A is running on tiles A3 and A4 while tiles A1 and A2 are set to the sleep mode. Configurations 2 and 3 show two possible scenarios with tasks B and C running in parallel. Once task A finishes its execution according to the graph of Figure 3, the system can go to either configuration 2 or configuration 3 depending on the system requirements. For example, if the current state of the battery level is low, the system would choose configuration 2 as configuration 3 requires the complete FPGA working surface and therefore consumes more power. 3.5 System objectives System objectives define its functional and non-functional requirements. Typical system objectives are as follows: 1) ensuring exclusive uses of reconfigurable tiles by tasks; 2) switching tiles to sleep mode when executing no task; 3) switching tiles to active mode when executing task(s); 4) bounding the costs of system configurations according to battery levels; 5) enforcing system execution termination once started; 6) minimizing the costs of system configurations; 7) minimizing overall system execution costs.
A
A
D
4. FORMALIZING FPGA CONTROL
C
Fig. 3. DAG specification of an application. In the framework, we suppose each task performs its computation with the following four control points: • • • •
being requested or invoked; being executed w.r.t. a choice of implementation; notifying execution finish, once it reaches its end; being kept loaded or configured, after having finished.
Occurrences of control points being requested and notifying execution finish depend on runtime situations, and are thus uncontrollable. The way that tasks being executed and whether they are kept loaded after executions are available controllable points for a controller aiming to achieve system objectives.
We specify the modelling of the computing system behaviour and control in terms of LTS’s. System objectives are defined based on the models. We focus on the management of computations on the reconfigurable tiles and dedicate processor area A0 exclusively to the resulting controller. 4.1 Architecture behavior The architecture (see Section 3.1) consists of processor A0, four reconfigurable tiles {A1, A2, A3, A4} and a battery. Each tile has two operating modes, and the mode switches RMi c_ai
acti = false c_ai Slei
3.3 Task implementation a) Given a hardware architecture, a task can be implemented in various ways characterised by various parameters, such 153
not c_ai
Acti acti = true
BM down
down
acti
up
b)
H st=h
down M
up
st=m
L up
st=l
Fig. 4. Models RMi for tile Ai, and BM for battery.
st
2013 IFAC DCDS September 4-6, 2013. York, UK
TMA Sdl
eB/rA
eA,eB,eC,eD I
req/rA
A
eA/rB,rC
A,C
eC
B
eC/rD
eA and eC/rD
D
eC
eB and eC/rA
B,C
rA e A
C
eA
req
A
eD
rA,c1 X1 eA,c1
eB/rA
a)
c2
eA,c1 c1
rA,c2
c1,c2
T rA,rB,rC,rD
eA/rD
I
eA,c2
b)
rA,c1
rA,c1 L1
rA,c2 L2
X2
es
eA,c2 rA,c2
Fig. 5. Models for a) the scheduler Sdl and b) a task A: T MA are controllable. Figure 4(a) gives the model of the behaviour of tile Ai. The mode switch action between Sleep (Sle) and Active (Act) depends on the value of the Boolean controllable variable c ai . The output acti represents its current mode. The battery behaviour is given in Figure 4(b). It has three states labelled: H (high), M (medium) and L (low). Its inputs come from a battery sensor, which emits up and down level events, and its output st represents the current battery level. 4.2 Application behavior The software application is described as a DAG: we capture its behaviour by systematically defining a scheduler automaton which can be constructed algorithmically from the DAG. The algorithm transforming a DAG to an automaton can be found in (An et al. (2013)). It represents all possible execution scenarios, by keeping track of execution states and emitting the start requests of tasks in reaction to the finish notifications. Figure 5(a) shows the scheduler automaton of the application in Figure 3. It starts the execution of the application by emitting event rA , which requests the start of task A, upon the receipt of application request event req in the idle state I. Upon the receipt of event eA notifying the end of A’s execution, events rB and rC are emitted together to request the execution of tasks B and C in parallel denoted by state (B, C). At state (B, C), there are three possible transitions: task B ends denoted by eB before task C, task C ends denoted by eC before task B, and tasks B and C end at the same time, leading respectively to three states (A, C), (B) and (A). Task A is requested again (i.e., rA is emitted) once task B ends. For states (A, C), (B) and (A), the transitions are constructed similarly. Task D is not requested until the execution of both A and C is finished, i.e., the reception of events eA and eC . It reaches the final state (T ), implying the end of the application execution, upon the receipt of event eD . 4.3 Task execution model Behavior. In consideration of the four control points of task executions (see Section 3.2), the execution behaviour of task A associated with two implementations (see Section 3.3) can be modelled as in Figure 5(b). Such a model can be derived systematically from a list of task implementations. It features an initial idle state I, two executing and loaded state pairs (X1 , L1 ) and (X2 , L2 ) corresponding to the two different implementations. Each loaded state Li corresponds to an executing state Xi , meaning that their 154
corresponding task implementation has been configured in this state, and can be executed directly, i.e., go to state Xi , without the need to reconfigure. Controllable variables c1 , c2 are integrated in the model to encode controllable points: being executed and kept loaded. From idle state I, upon the receipt of start request rA , task A goes to one executing state Xi , i ∈ {1, 2} depending on the value of controllable variable ci leading to Xi . Li can only be reached from idle state I through its corresponding executing state Xi , meaning that the task has finished its execution in Xi (i.e., eA is received), and remains configured on the corresponding occupied surface. From state Li , once the task is requested again, it can either go to state Xi and be executed directly without being configured, or be configured in some new way and executed accordingly (i.e., go to state Xj , i 6= j). From state Li , it can also go to state I if the controller at some moment decides to release its occupied surface for the use of other tasks. When the task ends, denoted by ei , from an executing state Xi , it might go to state I as well instead of state Li depending on the values of controllable variables, e.g., its occupied tiles are taken by other tasks. Local execution costs. The execution costs of different task implementations are different. Three cost parameters are considered (see Section 3.3). We capture them by associating cost functions denoted by a tuple (rs, cc, ec) with the states of task models, where: rs ∈ 2RA (the occupied set of architecture resources), cc ∈ N (configuration cost value), and ec ∈ N (execution cost value). We now define the costs according to three types of states: • idle state has values rs = ∅, cc = 0, ec = 0; • loaded state Li : rs = rsi , cc = 0, ec = 0; • executing state Xi : rs = rsi , cc = 0 or cci , ec = eci . rsi represents the occupied resource set of the task implementation that corresponds to the loaded and executing state. rs has value rsi for loaded states, as a task that is kept loaded still occupies the corresponding resources. The cost values of cc and ec for idle and loaded states are 0, as configuration and execution costs can only be induced after a task is requested (i.e., reception of r). The cost values cci and eci corresponding to a task implementation should thus be evaluated to the corresponding cost functions of executing states. However, the configuration cost of an executing state Xi is not always equal to the corresponding cci , but can also be 0 when the task has been configured and is executed directly. Therefore, regarding the task execution model in Figure 5(b), function cc of Xi should be defined in consideration of its previous states.
2013 IFAC DCDS September 4-6, 2013. York, UK
It is evaluated to 0 if its previous state is Li , i.e., at the moment the task is requested, it has been configured. Otherwise, it is evaluated to cci , i.e., the task has to be configured before executed. Take state X1 in Figure 5(b) as an example, it has three incoming edges from states I, L1 and L2 . The configuration cost cc is equal to 0 if it is reached from state L1 , and cc1 if reached from I or L2 . 4.4 Global system model Global behavior. The parallel composition of control models for reconfigurable tiles RM1 -RM4 , battery BM and tasks T MA -T MD , plus scheduler Sdl defines the system model: S = RM1 ||...||RM4 ||BM ||T MA ||...||T MD ||Sdl with initial state q0 = (Sle1 , ..., Sle4 , H, IA , ..., ID , I). It represents all the possible system execution behaviours in the absence of control (i.e., a runtime controller is not yet integrated). Each execution behaviour corresponds to a complete path, which starts from initial state q0 and reaches one of the final states: Qf = (q(RM1 ), ..., q(RM4 ), q(BM ), IA , ..., ID , T ), where q(Id) denotes an arbitrary state of automaton Id. Global costs. The costs defined locally in each task execution model need to be combined into global costs. Costs on states. A system state q is a composition of local states, and we define its cost from the local task states (denoted by qA , ..., qD ) as follows: • used resources: union of the Sused resources of all tasks in this state, i.e., rs(q) = rs(qi ), i = {A, B, C, D}; • full cost on state: this indicates the overall cost the system takes in the current state, and is defined as the sum P of all task configuration and execution costs: f c(q) = (cc(qi ) + ec(qi )), i = {A, B, C, D}. Costs on paths. We also need to define the cost functions on paths so as to compute the cost of system executions. gi /ai
gi+1 /ai+1
gi+k−1 /ai+k−1
Given path p = qi −−−→ qi+1 −−−−−−→ ... −−−−−−−−−−→ qi+k , and full costs of system states, we define overall cost on path p as P sum of full costs on the states along the path, i.e., oc(p) = f c(qj ), i ≤ j ≤ i + k; 4.5 System objectives We distinguish two types of system objectives: logical and optimal ones, and describe them in terms of the states, and the costs defined on the states or paths of the model. Logical control objectives. For any system state q, we want to enforce the following: (1) exclusive usage of reconfigurable tiles by tasks: T ∀qi , qj ∈ q, i 6= j, that rs(qi ) rs(qj ) = ∅; (2) switch tile Ai to sleep mode, when executing no task: @qi ∈ q, Ai ∈ rs(qi ) ⇒ acti = f alse; (3) switch tile Ai to active mode when executing task(s): ∃qi ∈ q, Ai ∈ rs(qi ) ⇒ acti = true; (4) battery-level constrained costs (given threshold values V0 , V1 , V2 ): f c(q) < V0 (resp. V1 and V2 ) when battery level is high (resp. medium and low); (5) reachability: ∃q ∈ Qf that is reachable. 155
Optimal control objectives. Such objectives can be further classified into two types of objectives: one-step optimal and optimal control on path objectives. We use pseudo functions max and min in the following to represent the maximization and minimization objectives, respectively. One-step optimal objectives. Such objectives aim to minimise or maximise costs associated with states and/or transitions in a single step (Marchand and Samaan (2000)). We consider the following objective w.r.t. current state q: (6) minimize full costs in next states: min(f c, q). Objectives regarding optimal control on paths. Such objectives aim to drive the system from the current state to the target states Qf at the best cost (Dumitrescu et al. (2010)). We consider the following objective, w.r.t. current state q and the set of final states Qf : (7) minimize overall costs: min(oc, q, Qf ). 5. BZR ENCODING AND DCS Given the system graphical models and objectives of Section 4, this section describes the controller synthesis by using BZR and the DCS tool Sigali. BZR encoding of the system model. The automaton encoding of system components in Section 4 can be translated to textual encoding easily. The global system behaviour can then be encoded by composing all these models. Finally, the costs on system states are defined as described in Section 4.4. The BZR code is not detailed here, due to space limitation. We refer the readers to An et al. (2013) for more details. Enforcing control objectives. BZR contracts are able to directly encode the logical control objectives of Section 4 except for Objective 5. Due to space limitations, they are not given here. Taking as input the system model and the contract, the BZR compiler can synthesise a controller (in C or Java code) automatically satisfying the defined objectives. There is also a graphical tool enabling users to perform simulations of the controlled system by combining the controller with the system model. Optimal control objectives and Objective 5 can be addressed by combining BZR and Sigali. In this case, the BZR compiler serves as the front end to encode system behaviour, and produces an intermediate file. The optimal control objectives can then be encoded and integrated into this file, which feeds the Sigali tool. The DCS is finally performed by Sigali to automatically generate a controller. The generated controller can also be combined with the system model by the BZR compiler for simulations. 6. EXPERIMENTAL VALIDATION We consider a video processing system implemented on a platform containing an FPGA to visualise and validate the runtime reconfigurations of the FPGA controlled by our synthesized controller. The system consists of a camera capturing images, a dispatcher feeding image pixels to the platform, a compositor aggregating pixels produced by the FPGA, and a screen displaying the processed images. Each captured image is
2013 IFAC DCDS September 4-6, 2013. York, UK
divided into 9 areas, and the processing of each area is taken care of by one reconfigurable FPGA tile. There are three filtering algorithms (namely red, yellow and blue ones) that can be implemented on reconfigurable tiles to process images. When configured to process the same image, they are evaluated with different configuration and execution costs. Three objectives are considered: 1) different image areas are of different colours, 2) full costs are bounded by a maximum value, and 3) the full costs of next states are minimized. Following the design flow in Section 4, the C code of the runtime manager was firstly generated (which takes around 5 seconds with BZR). We then integrate it with the video processing system and implement it on an ML605 board from Xilinx. The board includes a Virtex-6 FPGA, an external DDR3 memory, etc. An Avnet extension card (DVI I/O FMC Module) with 2 HDMI connectors (In and Out) has been plugged onto the platform so that it can receive and send video streams through the connectors. Frame9processing
Microblaze
PR2
PR3
PR4
PR5
PR6
PR7
PR8
PR9
Mem.9Bus
Processor9Local9Bus
CF9controller
Interrupt controller
GPIO9switchs
DDR39Memory
ICAP
PR1
GPIO9buttons
Fig. 6. Global structure of the implementation Figure 6 illustrates the global structure of our implementation. We have divided the FPGA surface into two kinds of regions: static and reconfigurable. The latter is divided into nine reconfigurable tiles in charge of the video processing. A 32-bit soft-core microblaze processor is synthesised on the static region to execute the computed manager and the management of the configuration bitstreams. The external DDR 3 memory is used to buffer the video frame pixel data, and store the software executable to be launched by the microblaze. A compact flash card is used to store the bitstreams of the filter implementations on each reconfigurable tile. The C code of the manager is deployed on the microblaze as an infinite loop. Once invoked, it is able to read the input and computes out a new configuration. The microblaze then selects the appropriate bitstreams from the compact flash card, and sends them to the ICAP to reconfigure the nine reconfigurable tiles. A number of tests on the implementation have shown that the three system objectives are achieved. 7. CONCLUSION FPGA-based embedded systems require a runtime controller to answer task execution requests by choosing at runtime the best suited implementations w.r.t. system objectives and environment. Such a controller should take into account reconfiguration overhead, and be able to predict the impact of its decisions on future. This paper presented a discrete controller synthesis (DCS) based design flow to address this problem. System behaviors 156
are modeled by using parallel automata, and the runtime controller computation is formalized as a DCS problem. A programming language and synthesis tool are used to automatically perform the DCS. An experimental validation of our proposal has been performed by implementing a video processing system on a Xilinx FPGA platform. In future work, we will enrich our models by taking into account other aspects, such as communication costs; and exploit the modular synthesis and compilation (Delaval et al. (2010)) to anticipate possible scalability issues. REFERENCES An, X., Rutten, E., Diguet, J.P., Le Griguer, N., and Gamati´e, A. (2013). Autonomic Management of Reconfigurable Embedded Systems using Discrete Control: Application to FPGA. Rapport de recherche RR-8308, INRIA. URL http://hal.inria.fr/hal-00824225. Boyer, F., Delaval, G., de Palma, N., Gruber, O., and Rutten, E. (2012). Discrete supervisory control application to computing systems administration. In Proceedings of the 14th IFAC Symp. on Information Control Problems in Manufacturing (INCOM’12). Cassandras, C. and Lafortune, S. (2008). Introduction to Discrete Event Systems. Kluwer Academic Publishers. Delaval, G., Marchand, H., and Rutten, E. (2010). Contracts for modular discrete controller synthesis. In Conf. on Languages, Compilers, and Tools for Embedded Systems, 57–66. URL http://bzr.inria.fr. Dumitrescu, E., Girault, A., Marchand, H., and Rutten, E. (2010). Multicriteria optimal discrete controller synthesis for fault-tolerant tasks. In Workshop on Discrete Event Systems (WODES), 356–363. G¨ohringer, D., M.H¨ ubner, V.Schatz, and J.Becker (2008). Runtime adaptive multi-processor system-onchip: RAMPSoC. In Symp. on Parallel & Distributed Processing, 1–7. Hellerstein, J., Diao, Y., Parekh, S., and Tilbury, D. (2004). Feedback Control of Computing Systems. Wiley. Kephart, J.O. and Chess, D.M. (2003). The vision of autonomic computing. IEEE Computer, 36(1), 41–50. Lysaght, P., Blodget, B., Mason, J., Young, J., and Bridgford, B. (2006). Invited paper: Enhanced architectures, design methodologies and cad tools for dynamic reconfiguration of xilinx fpgas. In Field Programmable Logic and Applications, 2006 (FPL’06), 1–6. Marchand, H. and Samaan, M. (2000). Incremental design of a power transformer station controller using a controller synthesis methodology. IEEE Trans. on Soft. Eng., 26(8), 729 –741. Marchand, H., Bournai, P., Le Borgne, M., and Le Guernic, P. (2000). Synthesis of discrete-event controllers based on the Signal environment. Discrete Event Dynamic System: Theory and Applications, 10(4). Ramadge, P. and Wonham, W. (1989). On the supervisory control of discrete event systems. Proc. IEEE, 77(1). Santambrogio, M.D. (2010). From reconfigurable architectures to self-adaptive autonomic systems. International Journal of Embedded Systems, 4(3), 172–181. Wang, Y., Cho, H., Liao, H., Nazeem, A., Kelly, T., Lafortune, S., Mahlke, S., and Reveliotis, S.A. (2010). Supervisory control of software execution for failure avoidance: Experience from the gadara project. In Workshop on Discrete Event Systems (WODES).