Design

Design of SC-REX

Introduction

During their execution, applications show different behaviors (called "phases").
Each phase is characterized by a certain behavior (e.g., loop, strided memory, potentially parallel) and by a certain set of constraints (e.g., Quality of Service, deadlines).
Detecting these phases at run-time allows to reconfigure the underlying architecture in order to meet different goals:

• Performance improvement
• Power consumption optimization

SC-REX provides an infrastructure to allow applications:

• Execute part of the code on available reconfigurable processors
• Reconfigure each processor based on the characteristics of the code that is going to be executed

Description of components

The main idea behind the design of SC-REX is that a hardware-specific kernel driver exports the reconfigurable processors as files on the filesystem. On Linux, this can be achieved, for example, by using character devices on dev/ or entries on sys/. Then, a hardware-independent supervisor, running in user level, is in charge of handling the set of processors: it collects the requests coming from the applications, it schedules the tasks on the available processors, and it reconfigures the processors based on the desired goal (e.g., energy efficiency or performance).

Therefore, the SC-REX scheduler consists of 3 components:

• A kernel driver, which exports all reconfigurable processors as "files" on the filesystem. The driver must export, at least, the instruction and data memories and the control register (i.e., to let the supervisor stop and start the processing unit). If the processor is also capable of reconfiguration, then the driver must also export through some files the specific interface registers for triggering the reconfiguration.
  The kernel driver is obviously dependent from the specific platform. Therefore, you have to implement the driver for your specific hardware.
  We provide an example of a driver for the Vex reconfigurable VLIW on the drivers/ directory.

• The supervisor, which is a daemon running in user-space. It receives requests from the applications through the RTL library, and schedules the tasks on the available processors. Moreover, it reconfigures the processors in order to achieve the desired goal (e.g., energy efficiency or performance).
  This component is implemented using the C++ programming language to have good performance and robustness. Currently, only one the external library (i.e., rapidxml) has been used, to enhance portability. The source code of the supervisor is available under the supervisor/ directory.

• The Run-Time Library (RTL), that is needed by applications to communicate with the supervisor. This library is implemented using standard C and it is available as shared library. The source code of the library is available under the runtimelib/ directory. The library exports to the application an API that allows to

  • Communicate to the Supervisor a task that must be run on available processors and retrieve the result of such computation
  • Communicate to the Supervisor additional information about the task that is going to be run. This information consists of the Quality of Service (QoS), the type of program (called "phase" like, for example, a loop) and the expected duration of the computation. The "mapping" between this information and the specific configuration of the reconfigurable processor is done through a sort of table (''reconfiguration table") contained inside a XML file parsed by the supervisor. In practice, when the supervisor receives the phase information from the application, it looks up in the table to understand the new configuration of each reconfigurable device. Then, it writes such values into the files on the filesystem. The kernel drivers will read those values and reconfigure the devices accordingly.

See Section [Usage] for the API available to the applications.

The communication between the applications and the supervisor is done through Unix local sockets, but the communication type is hidden to application code.

XML files

All architecture-dependent information are on XML files, so that the supervisor code remains architecture-independent. In particular, there are two kind of XML files:

• One file (i.e., /etc/screx/architecture.xml) contains the description of the architecture (e.g., number and type of processors, files used to access internal memories and to reconfigure them, etc.). This file is loaded when the supervisor starts, to understand the devices available on the platform.

• Additional XML files contain the tables of mappings between (phase, QoS) and configuration of each processor.

See Section [Usage] for the structure of these XML files.

Doxygen documentation

To create automatic documentation through Doxygen, download the code and type

make doc

This requires doxygen and graphviz installed.