Run-time support for heterogeneous multitasking on reconfigurable SoCs

Run-time support for heterogeneous multitasking on reconfigurable SoCs

林鼎原Department of Electrical Engineering

National Cheng Kung UniversityTainan, Taiwan, R.O.C

112/04/20

1

2

一、 AbstractIn complex reconfigurable systems on chip (SoC), the dynamism of

applications requires an efficient management of the platform.To allow run-time management of heterogeneous resources, operating

systems (OS) and reconfigurable SoC platforms should be developed together.

We show that networks-on-chip (NoC) are an ideal communication layer for dynamically reconfigurable SoCs.

Explain how our OS provides run-time support for dynamic task relocation. Detail how hardware parts of the OS are integrated into the higher layers

of the NoC.

3

二、 IntroductionIn order to meet the ever-increasing design complexity, future sub-100 nm

platforms will consist of a mixture of heterogeneous computing resources, storage elements, hardware accelerators, etc. (denoted as tiles).

These programmable/reconfigurable tiles will be interconnected by networks-on-chip (NoC).

The integration of these heterogeneous resources into a single tile-based system, illustrated by Fig. 1

4

二、 Introduction( 續 )Obviously, the management infrastructure should ease application

development by shielding the programmer from the complexity of the system and by providing a clear application development interface.

In addition, this infrastructure is responsible for monitoring and managing the available resources in a consistent, efficient and fair way.

Management infrastructure motivation:Two distinct approaches of OS management can be identified:

1. Treating computing tiles as peripheral devices In this case the host OS typically provides device driver support allowing applications to

directly access these devices, which should ensure maximum performance. 2. Treating computing tiles as regular computing resources

The OS deals with the low-level aspects and the management of the heterogeneous resources, allowing the application designer to concentrate on the application’s functionality.

5

二、 Introduction( 續 )We believe it is timely to develop an integrated management infrastructure

that enables the full potential of the heterogeneous multiprocessor system, illustrated by Fig. 2.

Such an infrastructure should provide a greater ease-of-use and consistency by providing a suited abstraction for the heterogeneous computing resources.

In addition, it should enable sharing the computing resources among multiple, unrelated applications.

6

二、 Introduction( 續 )As Fig. 2 illustrates, the biggest part of our operating system for

reconfigurable systems (OS4RS) executes on top of the instruction set processor (master ISP).

However, depending on the amount of hardware support for the OS , a small amount of low-level management functions effectively ‘executes’ on top of the slave processing units.

Our OS can be classified as a master–slave configuration. This implies that one processor unit (the master ISP) is responsible for monitoring the status of the heterogeneous system and for assigning work to all the other processing units (slaves).

7

三、 OS components for the targeted system

OS4RS task descriptors:The OS keeps track of the tasks by means of a task descriptor list.

This list contains a descriptor for every OS4RS task instantiation. The most important descriptor components are:

The task logical ID. This unique ID is assigned by OS4RS at task initialization time and allows addressing

tasks, independent of their location (i.e. current computing unit) within the system. The task state.

This allows, for example, to indicate that a certain task has been assigned to a computing resource for execution, or that a task has been selected for relocation to a different computing resource.

A link to the task destination look-up table (DLT). A list containing the available execution binaries and their respective properties,

targeted at the different heterogeneous computing resources A link to the computing unit descriptor that currently executes the task.

8

三、 OS components for the targeted system( 續 )

OS4RS computing unit descriptorsThe operating system manages its computing resources by maintaining a linked list of computing unit descriptors.

Every computing unit descriptor contains a set of 11 functions that completely describes the capabilities of the computing resource.

The most important functions allow the operating system to: 1.Set up a task.

This function requires the task logical ID and the task binary as input from the OS. 2.Initialize a task.

This function allows the OS to reset a task and, if necessary, initialize it with a previously captured task state.

3.Start a task. This function allows the OS to start a task with a specified logical ID.

9

三、 OS components for the targeted system( 續 ) 4.Remove a task.

This function allows the OS to remove a task with a specified logical ID. 5.Signal a task.

This functions allows the OS to send a switch signal to a certain task, to suspend/ resume a task, etc.

This function requires a signal identifier and a task logical ID. 6.Control inter-task communication.

This function allows the OS to initialize/update the DLT of a specified task. 7.Handle computing resource exceptions.

This is a call-back function that allows the computing resource to signal exceptions to the OS.

Furthermore, the computing unit descriptor allows the OS to monitor the state of the computing unit through a number of variables

like the load of the computing unit, the number of running tasks, the task set up time, etc.

10


OS4RS task scheduling:The OS employs a dynamic two-level scheduling technique, (illustrated by Fig. 3.) The top-level scheduler assigns tasks to computing resources in response to timer ticks and external events (e.g. user interaction). This mapping is based on the information that resides in the OS4RS task descriptors and the computing unit descriptors.The top-level scheduler dispatches a task to a local scheduler by instantiating this task on a certain computing unit.The top-level scheduler is able to move tasks between heterogeneous computing resources by using task-specific contexts.The local scheduler, tied to a certain computing unit, is responsible for the temporal ordering of the tasks that have been assigned to that computing unit.

11


12


OS4RS inter-task communication:By using a uniform communication scheme for all tasks (independent of their mapping), relocating at run-time a certain task between heterogeneous computing resources does not affect the way other tasks communicate with it.This uniform communication scheme is based on message passing, since this communication type is supported by the underlying hardware.To support point-to-multipoint and multipoint-to-point communication, we have introduced the notion of input and output ports for the tasks.Messages sent by one task to two other tasks are distinguished by the output port number they are being sent on.

13

三、 OS components for the targeted system( 續 )During application initialization, for every task in the application, the OS

assigns a system-wide unique logical ID.The top-level scheduler (Fig. 3) maps the task on a computing resource,

which determines its physical address on the platform.In addition, the application provides the OS with a task graph detailing the

application’s inter-task communication (Fig. 4).

14

三、 OS components for the targeted system( 續 )Thus, for every output port of a task the OS defines a triplet

(destination input port, destination logic address, destination physical address). For instance, task C has two output ports, hence is assigned two triplets,

which compose its DLT (Fig. 5).Whenever a task gets instantiated, the OS updates its associated DLT and

sends it to the computing resource responsible for the task execution.

15

四、 OS hardware supportThe hardware support allows the OS to perform some low-level

management functions in a more efficient way. This section explains how an ensemble of NoCs and interfaces to the

computations resources implement an efficient communication layer and support the OS in three distinct domains:

(1)Task management. In order to instantiate/remove tasks from a certain computing resource, the OS requires

efficient access to its configuration/programming mechanism. (2)Inter-task communication.

A better solution would be to allow the different (slave) computing resources to communicate with each other in a way controlled by the OS, but without having to pass through the main ISP.

(3)Operation and Management (OAM). The OS needs to keep track of the behavior of the different tasks executing on all the

computing resources in terms of communication and security.

16

五、 Description of the application life cycleTask life cycle Whenever a user starts an application, the OS needs to perform a series of actions before the application actually starts running on the heterogeneous reconfigurable SoC. Three steps can be identified (Fig. 7):

(1) Loading the application This step creates a task structure containing a unique logical ID for every task within the

application. This is done by registering a communication task graph . Based on this task graph, the OS creates a DLT for every task.

(2) Allocate tasks to platform computing resources In this step the operating system decides on the mapping of the application tasks

depending on their available representation, the availability of computing resources, the requested QoS, etc.

17

五、 Description of the application life cycle( 續 )

(3) Instantiate initialize and start the application tasks. This entails (for every task) sending the configuration/program data to the computing

resource, reset/initialization of the tasks, updating the DLT and sending it to the computing resource and finally start the task.

18


The OS needs the ability to relocate (migrate) a task from one heterogeneous computing resource (origin tile) to another (destination tile).

The principle of the relocation process is depicted by Fig. 8. (1)In order to relocate a task, the OS can send a switch signal to that task, at any time (2)Whenever that signaled task reaches a switch point, it goes into an interrupted

state. (3)In this state, all the relevant state information of that switch point is transferred to

the OS. (4)Consequently, the OS will instantiate that task onto a different computing resource.

The task will be initialized using the state information previously stored by the OS. (5)The tasks resumes by continuing execution in the corresponding switch point.

19


20

2

21


Because parts of the OS are distributed in different components over the platform, the actual switch process involves concurrent steps and requires synchronization of communication.

The different steps performed in the actual switch process are described in more detail in Fig.9 .

(1)When the OS sends a switch signal to the origin tile , the task running on that tile may be in a state that requires more input data before reaching a switch point.

Therefore, when the task reaches its switch point and signals it to the OS (1→2).

22


(2)After reception of the acknowledgment that the task has reached its switch point, the OS requests the sender tile to send one last tagged message to the origin tile and then stop sending further messages.

(3)The OS then configures the destination tile with the switched task, initializes it to the state it stopped in and enables its communications on the data NoC.

(4)The next step is to forward all pending messages to the newly relocated task.

(4)To this end, the OS sends a new DLT to the origin tile and puts its data NIC in a special state that forwards all its input messages to the destination tile.

23


The tagged message is the last one to be forwarded by the data NIC of the origin tile to the destination tile. The OS is informed by the data NIC of the destination tile upon reception of the tagged message (4→5)

(5)The task switching mechanism is finished and the OS can simply update the DLT of the sender tile to point to the destination tile in place of the origin tile and re-enable its communication on the data NoC.

24

六、 conclusionThis paper presents our work on the run-time support of heterogeneous

multitasking on reconfigurable SoCs.

We show that an OS for reconfigurable systems should to be designed together with the communication layer of the platform.

Our architecture for reconfigurable SoCs is composed of a master ISP connected to heterogeneous reconfigurable tiles using an ensemble of NoCs as communication layer.

Documents

Run-time support for heterogeneous multitasking on reconfigurable SoCs