High-level Model of Dynamically Reconfigurable Architectures S´ebastien Pillement, Daniel Chillet, Universit´e de Rennes 1- IRISA - CAIRN 6, rue de K´erampont, F-22300 Lannion

Abstract Dynamically reconfigurable platforms are becoming more and more interesting to design efficient and flexible systems. In addition, real-time applications must satisfy hard constraints to ensure correct execution. To manage such complex systems (hardware and software), the use of an operating system is now a classical solution. However, defining these systems is a tedious task that needs new design methodologies. These methodologies are heavily dependent on the availability of component models. In this paper, we propose a component based model of reconfigurable circuits. This model supports the representation of partially and dynamically reconfigurable architectures. It also proposes mechanisms to support heterogeneity of actual components.

1. Introduction Today’s reconfigurable architectures, such as FPGA, are parts of mainstream when designing a new digital system. Nevertheless, new challenges and optimization objectives have appeared and leads to the definition of dynamically reconfigurable architectures (DRA) [1]. This means that a part of a circuit can be changed on-the-fly while the remaining implemented functionalities are running. This paradigm enables new application deployment strategies, such as new standards support or adaptation to the environment, and upgrade for example. This approach reduces the development time but requires methodologies that support these changes during the product life-time. Most of actual approaches include reconfigurable architectures with processor cores on the same chip. This kind of platform can support several execution paradigms (i.e. software and hardware) but increases the design and the management complexities by adding heterogeneity of resources. The adaptability of such architectures is obtained through reconfiguration of the DRA structure (components and interconnections). This mechanism provides the flexibility of general purpose microprocessors (GPP) with the performances of hard-wired functions. However, the control of the reconfiguration process

is difficult, and Operating System (OS) is included in the design process to manage the platform [2]. The use of an OS enables the architecture abstraction that permits to propose generic development flow and enables computations reuse. The design of a complete reconfigurable platform (i.e. GPP, DRA and OS) requires new methodologies. To be effective all these methodologies require the raise of abstraction. This can be achieved if a complete reconfigurable platform model, including an operating system, is available. This paper presents a multi-level reflective model of dynamically reconfigurable platforms. Our objective is to consider the OS service exploration as part of the design process. The proposed exploration process can be done at different levels of abstraction for the different parts. This hierarchical approach enables fast evaluation of the platform early in the design process (even if not all parts of the platform are defined). The remainder of the paper is organized as follows. After some definitions introduced in section 2, section 3 presents the related works in operating systems and reconfigurable platform models. Section 4 presents the fundamentals of the proposed model. Finally, before presenting conclusions and ongoing work in section 7, section 5 presents the use of our model while section 6 gives preliminary results.

2. Context In this work a minimal platform composed by one GPP and one DRA controlled by an unified OS (see Fig. 1) is considered. The global OS API is the composition of services deployed on the two execution resources, defining a distributed OS. As each service can be deployed on specific devices it can be adapted and optimized for it’s running resource. Furthemore, management of each resource can be optimized with a local service to support execution specificities. Designing ad’hoc OS for complex architectures is quite difficult and requires a lot of attention. Even for non reconfigurable architecture, hardware dependent software [3] needs to be designed and new constraints in the OS definition are to be taken into account. The

Global RTOS API Processors API Service A

3. Related work DRA API

Service B Service A’

Service C

ALU Control

Processor

DRA

Figure 1. Structure of the minimal reconfigurable platform. The platform is composed by a GPP, a DRA and a dedicated OS.

inclusion of dynamicity in hardware behavior requires more advanced management and complex services. As the OS handles hardware implementation of tasks (i.e. bitstream for FPGA), some of it’s services need to be adapted [4]. For example, spatial constraints need to be included during the scheduling and placement steps [5]. Changing the data-processing onthe-fly have an impact on interconnection resources and requires adapted mechanisms [6]. The dynamicity of reconfiguration is mainly implemented as memory (SRAM) write. This leads to a fragmentation of the configuration memory (exactly as in data memory of processors) and have an impact on the performance that can be achieved. Defragmentation of a dynamically reconfigurable architecture [7] requires more attention than a simple garbage-collector in JAVA for example. The definition of an heterogeneous reconfigurable system (GPP and DRA) can allow task migration. This approach requires the definition of equivalences between instantiations of the same computation on different targets. However, developing applications on these systems is a NP-complex problem [8] and requires new methodology. In this context, defining a reconfigurable platform, as described in Fig. 1, requires i) the definition of the underlying architecture (GPP, FPGA, interconnection, . . . ) and ii) the definition of the controlling OS. The OveRSoC project [9] aims at furnishing an exploration framework for embedded reconfigurable platforms controlled by a dedicated OS. The method is based on abstract and modular SystemC models (for GPP, DRA and OS) that allows to explore, simulate, and validate the distribution of OS services over the platform according to architectural constraints. This paper presents the multi-levels model of DRA. This model is included in the OverSoC methodology.

Model Driven Engineering (MDE) [10] is a model based systems development philosophy. This well established approach in software engineering aims at developing portable systems. MDE permits a real separation of concerns between the required functionality and it’s real implementation. The MDE approach begins to be used in the hardware design domain since it permits to abstract low level constraints during the conception life-cycle. In these methodologies, the components approach is well suited since it can handle encapsulation and permits the definition of interfaces for the communication between components. In the software domain lot of works are done in developing meta-model implementing MDE approach. The framework supports model transformations in order to refine the description of the overall system. We can cite Kermeta [11] which aims at proposing a model for the unification of constraints definition and supports verification of heterogeneous components. The Kermeta approach is interesting in this work since it can be used for the definition of self-adaptive applications in order to build Dynamic Software Product Lines (DSPLs) [12]. FRACTAL [13] is a component based model intended to implement, deploy and manage software systems including operating systems. This model was used in the THINK [14] tool which defines an environment for the development of dynamically reconfigurable operating systems. Defining dynamic reconfiguration of OS was first discussed in the K42 system [15]. At this level of abstraction (meta-model), most of the proposed approaches are software oriented and do not handle hardware aspects of implementation. In particular, the Object Management Group has introduced the CORBA Architecture [16] which is a framework of standards and concepts for open distributed programming. This architecture is intended to support dynamicity and heterogeneity of software applications. From an hardware point-of-view most of approaches are based on UML models. This specification language is the most-used to model application structure, behavior, and architecture. More specifically, the MARTE profile [17] was defined for System-On-Chip (SoC) co-design to support real-time hardware systems. GASPARD [18] is a framework for SoC visual co-modeling. It allows modeling, simulation, testing and code generation for a complete SoC. It uses the UML MARTE specification as an entry point of the methodology. There is ongoing work on GASPARD for the inclusion of dynamic aspects of reconfiguration [19], but actually the authors do not take specific OS definition into

account. The last evolution of UML leads to the definition of SysML [20], a modeling language for the design (from specification to the verification) of complex systems including hardware and software parts. SysML provides clear, consistent system structure and interfaces. Unfortunately designing a whole systems requires several models with different semantics and difference in design constraints applied in the different subsystems. The FP6 SPEEDS project [21] intends to allow the developer of an embedded system to use heterogeneous modelling paradigms in a uniform framework thanks to the existence of a common semantic-based exchange format associating ”rich interfaces” with components. These interfaces include contracts as behavior abstractions of functional and non functional aspects. Currently, this project focuses on static complex systems and do not handle reconfigurable parts. Other approaches from hardware design appear. Several projects use SystemC as specification language, we can cite the ADRIATIC [22], MOOSE [23] or OSSS+R [24] as examples. These projects use polymorphism offered by SystemC to catch the dynamic reconfiguration behavior of the applications. If these environments permit the evaluation of dynamic implementation of applications they cannot model the hardware resources of circuits and do not consider OS. PERFECTO [25] considers a dedicated OS for dynamic reconfiguration but it is a low-level representation of the architecture and a dedicated OS. Moreover, all these models do not support heterogeneity of abstraction of the manipulated objects.

4. High level model of the reconfigurable platform Nowaday’s architectures support dynamic reconfiguration and new approaches tend to define self-adaptive systems, where the architectures can adapt themselves their functionalities. This requires the development of an OS that will be able to monitor, interpret, analyze, and reconfigure the systems on-the-fly (i.e. at running time). During the design steps, this will require the possibility to model all the feasible execution schemes supported by the architecture. Finally, during the execution step, the model should ease the dynamic incorporation of components while supporting invariant communication interfaces. These two constraints lead us to define a component based model. The component based approach permits to model all types of architecture (homogeneous or heterogeneous structures). Components binding (i.e creating links between components) constitutes a path

to communicate and can implement arbitrary forms of communication. The interface definition can then be used to maintain interfaces consistency. In the proposed model, two different component types are defined, formerly the primitive and the composite one. The Primitive components are black boxes providing and requiring services. Composite components are a composition of other components (either primitives or composites). This leads to a hierarchical component model. As the architecture will be dynamically modified, the notion of reflection is considered. Reflective systems can therefore be modified dynamically to adapt to a particular computing environment, taking maximal advantage of resources availability. This is supported in the model by the implementation of reference redirections. According to the reflective component based approach, the model separates the functionalities of the application, implemented in the architecture, from the control of its behavior, supported by the OS.

4.1. Model of reconfigurable architectures All the above presented concepts were used and lead to the conceptual model presented in Fig. 2. The first component, called the active component, models the hardware costs and the physical constraints of the architecture. It corresponds to the internal organization of DRA and supports the execution of applicative tasks. This composite component is formed by the computation and the reconfiguration objects. These two composite components are not detailed in this particular view. In the model, the computation object handles constitutive components of the architecture, while the reconfiguration object handles the hardware parts supporting the reconfiguration process. The reactive component represents the dynamic behavior of the architecture. The particular platform presented in Fig. 2 contains an OS composed by a priority based scheduler and supports task management and allocation services. This composite component can be enhanced by others services during the design phase of the platform. In the model, the interface of the reactive component provides the DRA API supporting the developed services of the OS, while the binding of the active component represents physical interconnections of the circuit. For example, these interfaces model the access to external data memory. Definitions of the active and reactive component provides a system encapsulation, composition and configuration. Each component is constituted by metaobjects which can be defined independently and de-

Monitoring

Memory Interface

Dynamically Reconfigurable Architecture

Active Component Computation

Reconfiguration

General Interface

Monitoring

Placement attribute

Scheduler attribute

Task management

Priority Scheduler Idle Thread

Scheduler

Priority based Scheduler

Trap manager

Re-Active Component

Timer handler

Monitoring Allocator / Placement Allocator/ placement

Task Management

Physical interface Service interface Logical interface (export attribute or control)

Interface to the global OS (DRA API)

Figure 2. Conceptual model of the Dynamically Reconfigurable Architecture.

scribed at different levels of abstraction. This separation permits the quasi-independent exploration of heterogeneous components. The active component is the container of metaobjects (called computation in Fig. 2) representing the physical architecture resources. For an FPGA, these resources are CLBs (Configurable Logic Blocks), Memory blocks, LUTs (Look Up Tables), interconnections resources, I/Os, and dedicated hardwired blocks. In a classical DRA such as FPGA circuits, these elements are organized in a hierarchical manner. The composite property of the proposed model permits to handle all types of computation blocks and interconnections topologies. This component is intended to model hardware features, it then contains the reconfiguration object which represents the ability of self-adaptivity of the architecture. For example, in the Virtex Xilinx FPGA this object represents the internal reconfiguration access port (ICAP) [26]. The reconfiguration object also contains the elements required for the configuration such as memory or the definition of multi-context architectures. The reactive component is the container of the metaobject managing the platform. It models the dynamic reconfiguration mechanism, and contains the task descriptions and advanced management methods such as hardware task placement, timing and synchronization constraints, exceptions and real-time scheduling algorithms. All the dedicated OS services for the DRA management are included in the reactive component. In order to enable architecture exploration and monitor the components behavior (including both hardware and OS services), probes are inserted in the interfaces. In the model, the interfaces between the above men-

tionned components represent the interactions between the management and the circuit. On one hand the attributes required to manage the DRA are exported to the reactive component. While on the other hand, internal OS services interfaces allow the reconfiguration control (and by extension the control of the circuit). The proposed composite model offers hierarchical view of the platform to ensure an incremental exploration. Definitions of components (requiring/providing services) are independent since they are defined through their interfaces. The separation of concerns allows us to explore different high level description services of an OS (part of the reactive component), along with different levels of description of the active components. Using this model for the definition of a reconfigurable platform requires two step: • first, a platform is defined, in terms of components composition, interfaces definition, and interconnection; • second, functionality of each component must be implemented The former is achieved by the use of an architecture description language (ADL) based on UML, while the implementation is made in SystemC. SystemC was identified (and is widely used) as a good candidate for a modeling language as well as for its underlying high level simulation kernel. The next section discuss the choice of these ADLs.

4.2. Architecture Description Languages Usually, high level models are described with language such as UML which can handle functional and non functional properties of an architecture. To capture the different levels of abstraction and to keep model consistency, an UML class diagram is used. Three levels of abstraction of each component are defined (Fig. 3). The hierarchical structure of the active and reactive components are modelled through the UML inheritance construction. The computation component (Fig. 2) is composed (UML composition) by execution blocks (RunningBlock) and can include memories. These two elements can be specialized in the last level of representation by specific memories or by two main types of execution resources (processor or logic element). The reconfiguration component presented in Fig. 2 is modelled by the memory class. For the Virtex FPGA familly, the memory interface of the reconfiguration component is implemented by an ICAP block supporting bitstream transfers. The DRA management is modelled by OS services which are defined at a behavioral level. These services

are linked to the computation and reconfiguration components to export logical interfaces and requires attributes. These services offer a global API for the DRA management. Finally, the computation and reconfiguration components are linked to interfaces to ensure memory accesses and task communications. Even if this UML model offers different views of the reconfigurable unit, this type of description is difficult to simulate. The second drawbacks of UML is the difficulty in evaluating run-time reconfiguration. This can be addressed by the use of the UML MARTE profile. Unfortunately this profile do not handle dynamic aspects of reconfiguration at this time. Furthermore, in the hardware design domain, the systems are described using VHDL, Verilog or SystemC language. Even if VHDL can support behavioral description, the most flexible is SystemC [27]. SystemC is build over the C++ language and hence is object-oriented. Currently, SystemC offers the abilities to support description of several heterogeneous components. Furthermore it can execute classical C codes for the execution of OS services and application tasks. In the SystemC approach a progressive refinement is realized from the specification level to the behavioral level, and then, after an exploration phase, to the RTL level. SystemC supports an interesting Transaction Layer Model (TLM) [28] which helps in refining communication in SoC models by inserting, in a progressive way, timing delays and communication information. Finally, some useful dynamic process creation primitives have been added to SystemC (starting from v2.1) that can considerably help in software modeling. For all this reasons, we choose to generate SystemC code in order to explore the platform. Design of a complete reconfigurable platform (e.g. hardware and associated OS services) corresponds to the refinement of the active and reactive components. Even if the component based model permits a separation of concerns, the two components are tightly coupled and the refinement of one of them have impacts on the other ones. The exploration process of the overall platform is then constrained by the level of description of each component (composed by meta-objects representing hardware or software part of the system). The refinement process requires synchronization points (we call levels) where the level of description of each component is sufficient in order to have consistent evaluations of the design quality. In the next section, we present the simple model of a classic FPGA structure. The different levels are defined and we focus on the creation and placement of tasks of the OS.

5. Building a model of DRA In this example, a simple FPGA (only constituted by CLB) is modeled, and we focus on the CreateTask service of the OS. As we refine the description, the CreateTask service will require a PlaceTask service in order to check availability of resources in the FPGA. In Fig. 3, the level 1 is the highest level of abstraction. In this level, the different components require a small number of parameters. The reconfigurable unit (i.e. the active component) contains only one metaobject representing an homogeneous unconstrained hardware area (i.e. no size constraint). The reconfiguration object is implicit and is not presented nor controlled in this example. At this level, designer should define, at a high level, the future service required in the reactive component. For this purpose, the resources are considered as unlimited, i.e. no bandwidth limitation, no latency, no area constraint. The designer should also defines the binding of the active component which defines the physical interfaces of the DRA. These interfaces remain invariant during all the exploration process, in this example we used the OCP standard as transfer protocol. At this level, the constraints are defined according to the part of the reactive component the designer is actually describing. In the example, the only one property considered is the area (i.e number of resources) that task needs to be executed in the DRA. In this case, the CreateTask service only tests if the available area within the reconfigurable unit is sufficient to implement the new task. The constraint can be expressed, in the reactive component, by the relation: N X Ai × Pi,t ≤ Adra (1) Ra = i=1

with Ai the necessary area to instantiate task i in DRA, Pi,t an integer variable equals to 1 if the task i is instantiated in DRA at time t and equals 0 elsewhere, N the total number of tasks, and Adra the total area of the DRA. This constraint is the evaluation of the required reconfigurable area (Ra ) in the future PN circuit. For example, the computation of max( i=1 Pi,t )∀t defines the maximal number of simultaneous running tasks on the DRA and this information allows to fix the size of the task table for the management. When the API begins to be defined and all services (meta-object of reactive component) are defined, designer can start the refinement of the description. The second level refines the active components by defining the functional blocks of the reconfigurable resource. The considered FPGA is defined as a matrix of memory, running blocks and interconnection

Dynamic Reconfigurable Architecture

Active component

Reactive component 1..* APIInterface

OSServiceL1

1

GeneralInterface

Computation

1

attribute

attribute

Reconfiguration 1

0..*

1

1..*

MemoryInterface

1

Level 1

1 OSServiceL2

1

1

Memory

RunningBlock

Level 2

OSServiceL3

Ram

Rom

Processor

LogicElement

Level 3

Figure 3. UML model of the Dynamically Reconfigurable Architecture.

resources. The refinement of the hardware resources makes appear heterogeneity like different task sizes or different resources usages. This will require to refine some of the reactive component meta-objects such as the creation of a basic placement service. At this level, the reactive component can use the structural information of the active component to verify the consistency of constraints between the two levels. The definition of tasks must be completed by additional information, such as rectangular size and the form factor of the area required. In this case, the CreateTask service can verify more advanced constraints. The previous property (eq. 1) can be derived as: ∃RBi

∈

{(f reeWRBk , f reeHRBk )}∀k

(2)

| wTj ≤ f reeWRBi ∧ hTj ≤ f reeHRBi with (wTj , hTj ) the rectangular size of task Tj , and {(f reeWRBk ; f reeHRBk )} the set of rectangular sizes of free resources blocks RBk . These information can be used by more complex management services such as the scheduling. More advanced objects like placement and defragmentation algorithms can be added and explored at this level. These services are embedded in reactive component at a high level of description (like C code). Adding these services enhances the API of the DRA OS. The refinement of these services will impact the required hardware resources in the active component and can imply the dynamic creation of tasks. This property (if supported) catch the self-adaptativity of the circuit to an execution context. The level 3 is the more accurate level of description. At this level all the elementary objects of the active components are described. For our simple architecture, an array of LUT with the glue logic for arithmetic computation and the corresponding sequential elements are

defined. The corresponding reactive components must know all the task properties. Task descriptions are complete (i.e. all parameters are set), and OS services can ensure an accurate management of the execution. The reactive components are a set of complete OS services managing the hardware according to the application constraints. In this case, the previous simple example can be expressed as: ∃RBi

∈

{(nLRBk , nCRBk , M SRBk , nIRBk )}∀k

|

nLTj ≤ nLRBi ∧ nCTj ≤ nCRBi ∧ nITj ≤ nIRBi ∧ M STj ≤ M SRBi

With {(nLRBk , nCRBk , M SRBk , nIRBk )} the set of numbers of LUT, CLB, Interconnect and memory size of the free resources blocks RBk , and with nLTj , nCTj , nITj , M STj the task characteristics in terms of LUT, CLB, Interconnect and memory size. In this last step the model checks all the described constraints against the real elements implemented in the DRA. The presented process can be executed iteratively in order to define more complex architectures or to obtain more precise evaluations depending on the refinement of each objects in the model.

6. Experimentations and results To illustrate our methodology, we present in this section a simple example of development. For this example, three tasks (T1 a software task and T2 and T3 two hardware tasks) need to be executed on an architecture composed by one GPP and one DRA . We want to explore the OS requirements to support the execution of this set of tasks. The first step consists in defining the application and to ensure that the description is correct. At this level the DRA has no constraints and can accept all hardware tasks simultaneously. In

this case, the execution trace (listing 1) obtained shows that the DRA accepts all requests of task creation. SystemC 2.2.0 --- Sep 12 2008 13:42:31 Copyright (c) 1996-2006 by all Contributors ==> Degug at 0 s from : Create task T1 is done =========>at time 0 s Entering scheduler...1 tasks, , Tasks list type=SOFT pid=0; pri=1; name=T1; state=ready =========>at time 0 s Exiting scheduler... Finishing task with PID: 0 at time: 110 ns ==> Degug at 110 ns from : Create Task T2 ==> Degug at 110 ns from : Create Task T3 ==> Degug at 200 ns from : Load Task T2 : OK ==> Degug at 300 ns from : Load Task T3 : OK =========>at time 1 us Entering scheduler...2 tasks, Tasks list type=HARD pid=1; pri=1; name=T2; state=running type=HARD pid=2; pri=1; name=T3; state= running =========>at time 0 s Exiting scheduler...

Listing 1. OS Execution trace of three tasks, all the hardware tasks are accepted by the DRA (level 1 of description) After this verification step, the level 2 of the DRA is specified and a new OS service must be developed. This service now checks that, for each task creation request, the total DRA area is sufficient. At this level the designer must complete the description of the DRA with an area value and each hardware task area must be precised. This execution scenario leads to listing 2, and shows that the DRA accepts the task T2 but rejects the task T3 , due to space limitation. SystemC 2.2.0 --- Sep 12 2008 13:42:31 Copyright (c) 1996-2006 by all Contributors ==> Degug at 0 s from : Create task T1 is done =========>at time 0 s Entering scheduler...1 tasks, , Tasks list type=SOFT pid=0; pri=1; name=T1; state=ready =========>at time 0 s Exiting scheduler... Finishing task with PID: 0 at time: 110 ns ==> Degug at 110 ns from : Create Task T2 ==> Degug at 110 ns from : Create Task T3 ==> Degug at 200 ns from : Load Task T2 : OK ==> Degug at 300 ns from : Load Task T3 : : Not enough space =========>at time 1 us Entering scheduler...1 tasks, Tasks list type=HARD pid=1; pri=1; name=T2; state=running =========>at time 0 s Exiting scheduler...

Listing 2. OS Execution trace of three tasks, the DRA checks the availability of resources before loading a new task At this point, the designer have several choices. The first one consists in increasing the DRA area and to restart the exploration step. The second choice consists in the development of a new OS service that recovers the task rejection and decides to create a software instance for task T3 (if this representation exist). This simple service was developed and a software description of task T3 was provided. In this context, the exploration process, presented in listing 3, shows that the task T3 is rejected, and the error code returned by the DRA leads the OS to create a software instantiation onto the processor. In this example, we have shown that exploration of both OS services or DRA is possible. This is supported by our multi-levels model and by the OverSoC

SystemC 2.2.0 --- Sep 12 2008 13:42:31 Copyright (c) 1996-2006 by all Contributors ==> Degug at 0 s from : Create task T1 is done =========>at time 0 s Entering scheduler...1 tasks, , Tasks list type=SOFT pid=0; pri=1; name=T1; state=ready =========>at time 0 s Exiting scheduler... Finishing task with PID: 0 at time: 110 ns ==> Degug at 110 ns from : Create Task T2 ==> Degug at 110 ns from : Create Task T3 ==> Degug at 200 ns from : Load Task T2 : OK ==> Degug at 300 ns from : Load Task T3 : : Not enough space ==> Degug at 310 ns from : Create Task T3 =========>at time 1 us Entering scheduler...2 tasks, Tasks list type=HARD pid=1; pri=1; name=T2; state=running type=SOFT pid=2; pri=1; name=T3; state=running =========>at time 0 s Exiting scheduler...

Listing 3. OS Execution trace of three tasks, the rejected hardware task is executed in it’s software version methodology. The designer can progress iteratively in the design process through the exploration of some specific parts of the system.

7. Conclusion and future works In this paper, we propose a reflective component based model of dynamically reconfigurable architectures. The composite aspect of the model permits to define heterogeneous architectures through several levels of abstraction. The reflective property permits to handle the dynamicity of actual architectures. We used the component based paradigm in order to separate the definition of the architecture from the definition of its control. The use of UML permits to maintain consistency in the definition of objects and enables checking of binding properties. This binding defines physical interface (based on the OCP standard) of the platform and provides specific DRA API. The use of SystemC language permits the deployment and the simulation of the model. We are currently working on the model methodology to ensure automatic binding checking, and to include more properties. Another way of development concerns the automatic generation of meta-objects from the UML model by the way of composition methods. Finally the methods developed in the Dynamic Software Product Lines (DSPLs) methodologies will be explored to ease the exploration of architectures variability.

References [1] H. Amano, “A survey on dynamically reconfigurable processors,” IEICE TRANSACTIONS on Communications, vol. E89-B, no. 12, pp. 3179 – 3187, Dec. 2006. [2] J. Noguera and R. Badia, “Multitasking on reconfigurable architectures: microarchitecture support and dynamic scheduling,” Trans. on Embedded Computing System, vol. 3, no. 2, pp. 385–406, 2004.

[3] F. Pospiech and S. Olsen, “Embedded software in the SoC world. How HdS helps to face the HW and SW design challenge,” in Custom Integrated Circuits Conference, Sept. 2003, pp. 653–658. [4] K. Danne, R. Muhlenbernd, and M. Platzner, “Executing hardware tasks on dynamically reconfigurable devices under real-time conditions,” in Field Programmable Logic and Applications (FPL), 2006. [5] J. Tabero, J. Septin, H. Mecha, and D. Mozos, “Task placement heuristic based on 3d-adjacency and lookahead in reconfigurable systems,” in conference on Asia South Pacific design automation, 2006, pp. 396–401. [6] V. Nollet, T. Marescaux, D. Verkest, J.-Y. Mignolet, and S. Vernalde, “Operating-system controlled network on chip,” in Design Automation Conference, 2004, pp. 256–259. [7] J. V. der Veen, S. Fekete, M. Majer, A. Ahmadinia, C. Bobda, and J. Teich, “Defragmenting the module layout of a partially reconfigurable device,” in Engineering of Reconfigurable Systems and Algorithms, 2005, pp. 92–104. [8] R. Chamberlain, J. Lancaster, and R. Cytron, “Visions for application development on hybrid computing systems,” Parallel Computing, vol. 34, pp. 201–216, 2008. [9] J.-C. Prevotet, A. Benkhelifa, B. Granado, E. Huck, B. Miramond, F. Verdier, D. Chillet, and S. Pillement, “A Framework for the Exploration of RTOS Dedicated to the Management of Hardware Reconfigurable Resources,” in International Conference on ReConFigurable Computing and FPGAs, 2008. [10] M. driven Engineering, “Planet mde,” http://planetmde.org/, 2008. [11] T. I. Team, “Kermeta - breathe life into your metamodels,” http://www.kermeta.org/, 2008. [12] G. Perrouin, F. Chauvel, J. DeAntoni, and J. Jzquel, “Modeling the variability space of self-adaptive applications,” in Dynamic Software Product Lines Workshop, 2008, pp. 15–22. [13] E. Bruneton, T. Coupaye, and J. Stefani, “The fractal component model,” http://fractal.objectweb.org, 2008. [14] J. Polakovic and J. Stefani, “Architecting reconfigurable component-based operating systems,” Journal of Systems Architecture, vol. 54, pp. 562–575, 2008. [15] A. Baumann, G. Heiser, J. Appavoo, O. Krieger, R. Wisniewski, and J. Kerr, “Providing dynamic update in an operating system,” in USENIX Annual Technical Conference, 2005, pp. 32–32. [16] OMG, “Corba,” http://www.corba.org/, 2008.

[17] L. Rioux, T. Saunier, S. Gerard, A. Radermacher, R. de Simone, T. Gautier, Y. Sorel, J. Forget, J. Dekeyser, A. Cuccuru et al., “MARTE: A new profile RFP for the modeling and analysis of real-time embedded systems,” in UML for SoC Design Workshop, 2005. [18] H. Yu, A. Gamati´e, E. Rutten, and J. Dekeyser, “Model Transformations from a Data Parallel Formalism Towards Synchronous Languages,” Embedded Systems Specification and Design Languages: Selected Contributions from Fdl’07, 2008. [19] I. Quadri, S. Meftali, and J. Dekeyser, “A MDE methodology for implementing Partially Dynamically Reconfigurable FPGAs,” http://www.design-reuse.com/articles/18309/mdedynamic-reconfiguration-fpga.html, 2008. [20] OMG, “Systems modeling http://www.omgsysml.org/, 2008.

language,”

[21] S. Consortium, “Speeds http://www.speeds.eu.com/, 2006.

project,”

[22] A. Pelkonen, K. Masselos, and M. Cupak, “Systemlevel Modeling of Dynamically Reconfigurable Hardware with SystemC,” in International Parallel and Distributed Processing Symposium, 2003, p. 174.2. [23] D. Morris, C. Theaker, P. Green, and G. Evans, Object Oriented Computer Systems Engineering. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 1996. [24] A. Schallenberg, W. Nebel, and F. Oppenheimer, “OSSS+R: Modelling and simulating selfreconfigurable systems,” in Engineering of Reconfigurable Systems and Algorithms, 2006. [25] P.-A. Hsiung, C.-H. Huang, and C.-F. Liao, “Perfecto: A systemc-based performance evaluation framework for dynamically partially reconfigurable systems,” in Field-Programmable Logic and its Applications, 2006. [26] Xilinx Inc., Virtex-5 FPGA Configuration User Guide, 2nd ed., San Jose, feb 2007. [27] Open SystemC Initiative, “Standard SystemC Language Reference Manual,” http://www.systemc.org/, 2005. [28] F. Ghenassia, Transaction-Level Modeling with SystemC: TLM Concepts and Applications for Embedded Systems. Springer Verlag, 2005.