operating systems for reconfigurable embedded platforms: online scheduling of real-time tasks

Operating Systems for Reconfigurable Embedded Platforms:Online Scheduling of Real-Time Tasks

Jinxu Ding

Ramón Mercado

Cpr E 583 : Reconfigurable Computing Systems - Fall 2005

Outline

1. Introduction

2. Models and Limitations

3. Design Issues of Operating System

4. Task and Resource Management

5. Results and Conclusion


Introduction

The past of FPGAS Rapid prototyping and emulation.

FPGAs replacing ASIC reconfigurable hardware enables shorter time-to-

market and updating after product deployment. Today’s FPGA characteristics that allow for

more dynamic applications: Higher densities. Integrate processors, memories and special

function blocks. Partial reconfiguration.


Introduction (cont)

Reconfigurable Embedded Systems High performance demands. Frequent changes of their workloads. Some applications:

Wearable computing, mobile system, network processors, etc. The functions and their execution time are not known in

advance. Classical design process (i.e. complete design-time synthesis

and optimization) is not enough for this systems. This systems demand partial reconfiguration to meet their

require degree of flexibility.

Multitasking Reconfigurable Hardware


IntroductionMultitasking Reconfigurable Hardware

Programming Model Define the executable objects, their interaction and

provides the developer with a set of well-defined system services.

Runtime System Efficiently operates the system and resolves

conflicts between the executable objects. Reconfigurable Hardware Operating System

Programming model + runtime system. Similar to an RTOS, but for partially reconfigurable

hardware.


IntroductionRTOS and RHOS

Programming model: Real-time task (RTOS), smallest executable unit.

This are task that have a deadline. This task not only need to produce a result, but the must do it in a specific amount of time.

Periodic or Aperiodic. Hardware Task (RHOS), smallest executable unit.

This task, HW tasks, also have deadlines and can be periodic or aperiodic. BUT they also have an area constrain.

Run-time system: Scheduling (RTOS)

Guarantee-based: Every task that is admitted is guaranteed by the scheduler to meet its deadline.

Acceptance Test Scheduling (RHOS)

Also guarantee-based, but in this case the task is guaranteed that there will be space (area) for it to completely execute before its deadline.


IntroductionThe Problem

Guarantee-based online scheduling of real-time tasks to partially reconfigurable hardware.


Models and Limitations Device Model

For our purposes, the device (FPGA) is modeled as a rectangle of width (W) and height (H).

This rectangle is further divided into uniform sections of usable area. Any task scheduled will use an integer amount of these sections.


Models and LimitationsHardware Task Model

Executable objects of our model, formal definition. Aperiodic Configurations are known a-priori

Preplaced and prerouted Stored in a position-independent manner

Tasks are defined by {Ri, Ei, Di, Wi x Hi} Ri – Ready time Ei – Worst case execution time Di – Deadline Wi – Size along x-coordinate Hi – Size along y-coordinate


Models and LimitationsArea Model

1D – hardware tasks can be allocated anywhere along the horizontal dimension (x)

2D – hardware tasks can be allocated anywhere on the device (x, y)


Models and LimitationsArea Model (cont)

1D area model suffers from 2 types of external fragmentations Type A Type B

2D suffers less from external fragmentation which leads to higher schedulability, but is more complex.

Most FPGAs allow only for 1D model, only latest Vertex 4 supports a 2D model


Models and LimitationsCurrent Technology

Relocatability FPGAs are non-homogeneous devices.

They contain special resources like dedicated memories (BRAM) and embedded multipliers (Xtreme DSP) which are not available at every location on the device.

This non-homogeneousness limits the relocatability of HW tasks, however an operating system takes many of these resources away from the user and puts them under OS control.

Online Routing Arbitrary relocation of task require online routing and online delay

estimation of their signals (since they need to meet a deadline) neither of which is sufficiently supported by current tools. However, the models presented here are abstract enough that, with a

significant loss in performance, they could be modified to fit what is allow by the tools.


Design IssuesTarget Architecture

Ci are external components. RC is the reconfigurable

device. The configuration and

readback port (C/R) gives the CPU complete control over the configuration of RC, (full and partial configurations can be downloaded to the device and full and partial device states can be read back.)

The communication port (COMM) provides a number of general-purpose signals between the host CPU and RC.


Design IssuesResource Partition

Hardware Task Area


Design IssuesOS Frames & Hardware Task Area

Static OS Frames accommodate functions that constitute the runtime part of the operating system. Functions such as: Task communication and I/O through the Task

Communication Bus (TCB). Hardware Task Area is divided into a number of

dummy task areas that are placeholders for hardware tasks. Dummy tasks are palceholders for hardware tasks. The width

of a harware task is an integer multiple of the width of a dummy task.

During the configuration of a hardware task, the other loaded hardware tasks remain executing.


Design IssuesOS Modules


Design Issues Three level architecture of the OS

First level : task and resource management. Task scheduler decides on a starting time for each

task, based on some scheduling policy; offline or online.

An offline schedule is suitable for statically defined applications and is reflected by a simple task sequence table.

Online schedulers are priority-driven and split into nonpreemptive and preemptive schedulers.

The resource manager keeps track of all dynamically assigned resources, such as the hardware task area and memory.



The second level : handle task bitstreams and tasks states. Raw Task Repository stores task circuits in their

raw form. Before a raw task can be downloaded to the reconfigurable device, it must be relocated to a specific location in the hardware task area.

Task Context Store holds the task contexts that have previously been extracted from preempted tasks.

Task Preparation Unit (TPU) generates and analyzes partial bitstreams that represent the tasks.



The third level : communication and configuration. COMM Driver establishes this channel and allows the

operating system modules to exchange commands and data. C/R Driver provides device-independent configuration and

readback services to the TPU. The services comprise full and partial configuration as well as full and partial readback.

Task Controller is the standard task interface and forms the connection between operating system frames and hardware task area. One task controller assigned to each task.

Memory Management Unit (MMU) offers memory services to the tasks,


Task and Resource Management

Scheduling real-time tasks Guarantee-based online

scheduling of real-time tasks to partially reconfigurable, non-preemptive platforms.

A task is schedule, or accepted to the current schedule, if its deadline can be meet and there is enough free area to accommodate the task.

An acceptance function can be define as shown, where xi is the task position and si is the start time allocated to the Ti by the scheduler.

rejected

sxwithacceptedT iii

,



A sophisticated online scheduling methods increase the acceptance ratio by planning (looking into the future)

We may delay starting a task for its laxity (until Si-latest = di - ei) and still meet its deadline.

The time interval [Ri, Si-latest] is the planning period for a task Ti.

During the period, a planning scheduler manages two sets of tasks: the set of tasks currently executing on the device the set of reserved tasks, i.e., tasks that have been previously

guaranteed but not yet started. Planning techniques split into two groups.



The first group are schedulers that may rearrange already guaranteed tasks to find guarantees for all these tasks plus the newly arrived one. Such scheduling problems are known to be NP-hard. One such scheduling scheme is the Myopic scheme.

The second group are schedulers that try to fit the newly arrived task into the set of already guaranteed tasks rather than attempting to rearrange them. Dis. : weaker in performance but can be more efficient

algorithms. The two scheduling algorithms that we present here, Horizon

and Stuffing, fit into this group.


Task and Resource ManagementScheduling Task in 1D

Definition 1: A schedule task Ti is a task with a placement xi and a starting time si such that:


Task and Resource ManagementScheduling Task in 1D (Horizon)

Execution List E: contains all currently executing tasks with their finishing time and placement (Ti, xi, fi). xi is placement fi is finish time of task fi = si + ei

si and ei, are start and execution time respectively. Reservation List R: stores all scheduled but not yet

executing tasks with their start time and placement (Ti, xi, si).

The Scheduling Horizon: is given by hi = ([x1, x2] @ tr), where [x1, x2] denotes an interval in the device’s x-dimension and tr gives the maximum of the last release time for this interval and the current time.



For completeness, here we show the Horizon algorithm.



Horizon Summary Scheduler maintains a set

of ‘horizons’ H Each horizon, hi, is of the

form {[x1, x2] @ tr} Tasks are scheduled if

they fit in any horizon (smallest horizon with adequate width is selected)

Adjacent horizons are merged when possible

The BestFit() function returns the horizon where the new task can be place or null and the task is rejected.


Task and Resource ManagementScheduling Task in 1D (Stuffing)

Stuffing schedules task to arbitrary free areas that will exist in the future, including areas that will be used later by tasks currently in the reservation list.

More complex than Horizon, as it has to identify such potential placements and to check these potential placements for conflicts with existing reservations.



Besides the Execution and Reservation lists, the stuffing scheduler employs a Free Space List F.

The free space list is a set of intervals [x1, x2] that identify currently unused resource intervals, sorted according to increasing x-coordinates.



For completeness, here we show the Stuffing algorithm.



Stuffing Summary Maintains a ‘free space list’ Each free space is given by

[x1, x2] Free space list changes over

time To schedule a task, scheduler

simulates execution of reserved tasks, modifying the free space list as it goes, until suitable space is found for the arriving task

The BestFit() function returns the free space where the new task can be place or null and the task is rejected.



Definition 2: A schedule task Ti is a task with a placement (xi, yi)and a starting time si such that: (Notice that this is a simple extension from the 1D model)



The acceptance test can also be extended to fit the 2D model.

rejected

syxwithacceptedT iiii

,,


Task and Resource ManagementScheduling Task in 2D (Horizon & Stuffing)

Switching from the 1D to the 2D area model mainly affects the management of free space which is done by the placer, not the scheduler.

The scheduling techniques remain basically unchanged. Bestfit() works with rectangles instead of intervals. MergeRectangles() can improve area unitilization.

Execution List E = {…, [Ti, (xi,yi), fi], …} which contains all currently executing tasks with their current 2D position and finish times.

Reservation List R stores all scheduled but not yet executing tasks {…, [Ti, (xi , yi ), si], …}

The Scheduling Horizon: hi = ([(x1 , y1 ), (x2 , y2 )] @ tr)


Results and Conclusion

The following table show the resulting schedule of 7 task on both area models with the horizon and stuffing algorithms.

Notice the difference in starting time for task T4 to T7 from 1D to 2D. This shows how the 2D area model provides better schedulabitlity.



Simulation settings: 96x64 RCUs, Xilinx XCV1000 Task are uniformly distributed in [50, 500] RCUs

UART (50 RCU), DCT (600 RCU)

Computation time also uniformly distributed in [5, 100] times units (simulation unit of 10ms)

Tasks A,B and C with laxities uniformly distributed in [1, 50], [50, 100], [100, 200] times units, respectively.


Results and ConclusionReference Vs Horizon & Stuffing

rmercado

The reference scheduler do not takes laxaty into concideration.

rmercado

Standing tasks, far right, are better sutted for 1D model

rmercado

Laying tasks

rmercado

Standing Tasks


Results and Conclusion1D & 2D Stuffing

rmercado

76%

rmercado

98%

rmercado

1.8ms at most for task of [50ms, 1s] -> [3.6%, 0.18%]



We have presented some design issues for reconfigurable hardware operating system.

We have presented the problem of real-time hardware task.

Shown two heuristics for online scheduling of this real-time hardware tasks for the 1D and 2D area models, Horizon and Stuffing.

Shown how Stuffing outperforms Horizon for both the 1D and 2D model, and how on the 1D area model the scheduling performance, for horizon as well as stuffing, depends on the aspect ratio of the hardware task.


Questions

operating systems for reconfigurable embedded platforms: online scheduling of real-time tasks

Documents

hardware task rhos

realtime task rtos

asicreconfigurable hardware

rhosprogramming model

device x

mobile system

runtime system

operating systems