PaperlayerView exact revision on arXiv

Source-linked AI summary

Automated Deployment of Real-Time Tasks for Phased Execution on Scratchpad-Based Multicore Platforms

Konstantin Dudzik, Maximilian Kirschner, Jürgen Becker

arXiv:2609.04221v1cs.SE

TL;DR

Multicore real-time systems face timing-predictability problems from shared-memory contention, and phased execution is difficult to orchestrate. The paper automates adaptation through model-based phase scheduling and runtime support, validating the methodology on ROSACE and a RISC-V multicore platform.

  • Problem

    Shared-memory contention complicates timing predictability in consolidated multicore real-time systems, while phased execution remains elaborate to integrate.

  • Method

    A model-based deployment process extracts and schedules task memory phases and supplies a runtime environment to execute them.

  • Results

    The methodology enables modular task integration with minimal source-level changes and was validated on ROSACE using a custom RISC-V multicore platform.

  • Takeaways & Limitations

    Separating task binaries from the runtime lets the deployment tool automate phased execution while preserving modular application integration.

Abstract

from arXiv · show

The increasing throughput demands in real-time systems and the consolidation of functionality on few, high-performance platforms are driving a shift towards parallel architectures. A key challenge for multicore real-time systems is the interference from contention for access to shared memory. Phased execution approaches address this challenge by restricting shared memory access to mutually exclusive memory phases, while computation is limited to memories local to each core. However, the complexity of managing and scheduling said memory phases hinders the adoption of phased execution in real-time applications. To address this challenge, we propose a model-based deployment methodology that automates the process of adapting applications to phased execution. We present an integrated tool-based deployment process that extends the application through the necessary memory phases and provides a runtime environment to orchestrate execution on the target hardware platform. Our approach requires minimal changes to the application implementation since the deployment tool directly extracts the required information from the generated application binaries. We validate our methodology using an avionics case study on a RISC-V multicore system, showcasing its key components and principles of operation.

I. INTRODUCTION

Multicore real-time systems face timing-predictability and isolation challenges from shared-resource contention and consolidated functionality. The paper proposes a modular, model-based deployment process that automates phased execution with minimal source-level integration and validates it on ROSACE and a RISC-V platform.

  • Motivation: Shared-resource contention complicates timing analysis, while consolidation removes isolation boundaries between formerly distributed components.These challenges motivate strict isolation mechanisms and predictable multicore execution.
  • Motivation: Phased execution separates computation from shared-memory access, improving predictability but making memory-phase orchestration elaborate.The approach restricts execution to local memories apart from designated memory phases.
  • Contributions: The model-based methodology extracts and schedules task memory phases and provides a runtime environment for their execution.This automates adaptation of real-time applications to phased execution.
  • Contributions: Separate task binaries enable modular application consolidation without source-code-level integration.The deployment tool handles each task independently, avoiding application integration at the source level.
  • Contributions: The contributions include a task-and-schedule modeling scheme, a runtime providing isolation and deterministic communication, and automated binary and schedule generation.The deployment tool derives the system schedule and runtime configuration from modeled behavior.
  • Validation: The methodology is validated with ROSACE on an FPGA-based RISC-V multicore system using local scratchpad memories and DMA.The case study demonstrates the deployment process and runtime mechanisms.

III. SYSTEM MODEL

The system model combines task execution, target hardware, and scheduling descriptions to support phased execution. It uses LET-based communication and loads task instructions during acquisition phases to improve deployability across scratchpad-constrained cores.

  • Task execution model: The task model uses LET-based communication, fixing communication at LET boundaries while abstracting from varying task execution times.This decouples inter-task dataflow from actual execution-time variation.
  • Task execution model: Loading instructions during acquisition means each task must fit its instruction scratchpad individually rather than all tasks fitting simultaneously.This also permits flexible assignment of jobs to different cores.
  • System model: The system model comprises hardware, task execution, and schedule aspects that jointly describe deployment and execution behavior.These three aspects provide the basis for integrating the deployment tool.

A. Target Hardware Platform

The target platform requires per-core scratchpads for interference-free concurrent execution and reserves one management core to orchestrate system execution. Its model includes hardware regions and transfer-timing information for estimating memory-phase overhead.

  • Platform assumptions: Per-core scratchpad memories support interference-free concurrent execution in the phased-execution platform.The target is a multicore system with a dedicated management core.
  • Platform organization: One management core orchestrates execution, while the remaining application cores execute application tasks.The platform connects N cores through a crossbar and assigns distinct management and application roles.
  • Platform model: The hardware model specifies core count, scratchpad and main-memory regions, runtime-component times, and transfer-duration functions.The deployment tool uses these parameters to estimate memory-phase overhead.

B. Task execution model

Tasks are modeled with frequency, WCET, and ports, while LET boundaries define deterministic communication. The schedule adds memory-transfer operations and execution phases, groups operations into events, and prevents overlapping jobs on the same core.

  • Task representation: Each task is characterized by frequency, WCET, and ports, with task instances scheduled across the application hyperperiod.A task instance is called a job.
  • Task representation: WCET estimation for a task’s execution phase can use an equivalent single-core system because scratchpad execution avoids interference.The task executes independently from a scratchpad memory.
  • Schedule model: The schedule begins with periodic LETs and derives a static hyperperiod schedule whose events perform memory transfers and related operations.The periodic LET equals the task period, calculated from hyperperiod and task frequency.
  • Communication: LET boundaries populate input ports at the start and publish outputs at the end, producing deterministic communication semantics.Operations at the same logical time are grouped into one event.
  • Phased execution: Phased execution adds task-load and task-unload operations for acquisition and restitution within each job’s LET.Jobs are non-preemptive, so jobs assigned to the same core must not overlap.
  • Schedule construction: The parameters εTL and εTUL define execution windows by delaying acquisition and advancing restitution within the LET.The deployment tool uses these offsets and core assignments to construct an event sequence for one hyperperiod.

Task input load:

The task load operation transfers a task’s executable and data-related sections, along with its ports, to the mapped core’s scratchpads.

  • Task load transfers instruction and data sections, input ports, and private ports to the scratchpads of the core hosting the job.
  • The task load operation has a specified start time used to schedule this transfer within the phased execution process.

Task unload:

The task output publish operation copies buffered task outputs into output ports at the end of the corresponding job’s logical execution time.

  • Task output publish copies buffered task outputs into the task’s output ports at the end of the job’s LET.

D. Scheduling constraints

The deployment tool validates schedules against non-overlap, delay, slack, and job-order constraints before constructing the runtime configuration. Events may overlap only when resulting delays preserve feasibility and the LET-based execution model.

  • The developer specifies the schedule, while the deployment tool verifies memory and computation phase timing against feasibility constraints.
  • Operations assigned to one time point share an event and execute in the order ωTUL,ωTOP,ωTIL,ωTL to preserve LET dataflow.
  • Positive load and unload offsets keep job execution within its LET, while execution phases on the same core must not overlap.
  • A later job on the same core cannot begin loading before the preceding job unloads.
  • Scheduling delays from overlapping event durations are propagated through consecutive events but cannot affect the subsequent hyperperiod.
  • The deployment tool computes event delays from preceding events whose durations extend beyond later event start times; otherwise, the delay is zero.
  • A valid schedule requires each event delay to be less than the distance to the next event and every job’s slack to remain positive.
  • When all constraints are satisfied, the schedule is feasible and the deployment tool constructs the runtime configuration.

IV. DEPLOYMENT PROCESS

The deployment process converts application sources and a system model into task, runtime, and kernel binaries through task-level and application-level steps. It separates task and runtime binaries while extracting binary-level information needed to generate memory transfers and orchestration code.

  • The deployment process has two main steps: one operating at task level and one at application level.
  • The methodology separates runtime and task binaries, avoiding source-level task integration and minimizing restrictions on task implementations.
  • The task-level step generates a build configuration for each task, including a makefile, linker script, and core scratchpad properties.
  • The application-level build extracts section addresses and sizes from task binaries to generate runtime memory-transfer parameters.
  • The deployment tool builds a system schedule from developer annotations, checks its timing constraints, and generates C code to orchestrate execution.
  • The process also builds a minimal kernel for each application core, then loads task, runtime, and kernel binaries into main memory.

V. RUNTIME ENVIRONMENT

The runtime executes scheduled phased tasks while implementing deterministic LET communication and memory-based isolation. It uses extracted binary information, timer-triggered events, DMA transfers, scratchpads, and protection mechanisms to orchestrate execution.

  • Runtime responsibilities: The runtime executes system-schedule operations, implements LET communication semantics, and isolates tasks through memory protection.These mechanisms support deterministic dataflow and prevent task faults from interfering with the rest of the system.
  • Configuration: Runtime configuration stores instruction and data-section addresses, sizes, task ports, and memory-transfer parameters extracted from task binaries.Ports must be implemented as global variables, while their variable type is irrelevant to the runtime.
  • Communication: Input and output buffers located in the management core’s data scratchpad implement instantaneous LET-boundary reads and publishes.The buffers decouple communication boundaries from the task’s actual execution interval.
  • Event execution: Timer interrupts on the management core trigger DMA programming for each memory transfer associated with the current scheduling event.The runtime periodically executes schedule events from its configuration.
  • Initialization: A loader places the runtime in the management core’s instruction scratchpad, while initialization loads task kernels into application-core instruction scratchpads.After initialization, the runtime configures the first schedule event and becomes idle.
  • Isolation: Privilege separation and memory protection restrict each task to its instruction partition and data scratchpad.The stated purpose is to prevent one task’s faults from interfering with the rest of the system.

VI. CASE STUDY

The ROSACE case study deploys a modeled application onto a RISC-V multicore FPGA platform with scratchpads, DMA, and task isolation. The deployment process models task timing and communication, derives scheduling parameters, and produces an execution trace from scheduler timestamps.

  • Platform: The target platform uses four 100 MHz Rocket cores with tightly integrated scratchpad memories and a DMA engine on a Xilinx VCU118 FPGA.The platform was implemented with the Chipyard framework, and RISC-V PMP provides task isolation.
  • Timing characterization: The case study measures static scheduling overheads separately from memory-transfer times and evaluates DMA transfers over sizes from 1 B to 32 KiB.The measurements support the timing characterization used by the deployment process.
  • Application model: The deployment model represents task frequencies, ports, execution times, and communication channels in a JSON application model.Tasks sharing a frequency are mapped to one application core and execute sequentially within the same LET window.
  • Schedule specification: Schedule parameters distribute task-load and task-unload operations across LET windows, with additional time assigned to the longer dynamics task.A 100 µs final-unload offset reduces operations at hyperperiod boundaries.
  • Execution trace: The execution trace shows task windows between load and unload operations, with TIL and TOP operations at LET boundaries.The displayed hyperperiod was shortened from 20 ms to 5 ms to improve visibility.
  • Observed execution: The execution graph is generated from scheduler-timer timestamps for each scheduling operation, while inter-task communication transfers data between connected ports.This trace captures the deployed application’s scheduled operation sequence.

VII. CONCLUSION AND OUTLOOK

The work automates deployment of real-time applications into a three-phase execution model and supports modular task integration through binary-level information extraction. The methodology is validated on ROSACE using a custom RISC-V multicore platform, with environment ports identified as future work.

  • Contribution: The deployment methodology automates adaptation of real-time application tasks to a three-phase execution model.This is the central deployment contribution described by the authors.
  • Modularity: Independent task handling and binary-level information extraction enable modular integration without integrating tasks and runtime at source-code level.The deployment tool extracts required information directly from task binaries.
  • Validation: The methodology was validated on a custom RISC-V multicore platform using the ROSACE case study.The validation showcases the deployment process.
  • Outlook: Future work will extend the runtime environment and system model to support environment ports connected to external sensors and actors.The stated extension concerns interactions with external system components.
Loading 2609.04221v1…