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

The work proposes a model-based deployment methodology that automates application adaptation for phased execution.

Source: E001, E004

Its integrated tooling derives task and runtime artifacts and provides runtime orchestration for the target platform.

Source: E001, E004

Tasks follow an acquisition, computation, and restitution execution pattern: relevant program and communication state is brought into local memory, computation executes there, and outputs are transferred afterward.

Source: E002

The runtime dispatches scheduled events through timer-triggered handling and performs the associated memory transfers, while LET communication uses buffers.

Source: E006, E011

Memory protection restricts each task to its assigned instruction and data scratchpad regions.

Source: E011

The methodology was demonstrated through deployment of the case-study application, including a generated schedule and an execution trace covering a hyperperiod; the displayed trace uses an adjusted hyperperiod for visibility.

Source: E005, E019

Evaluation is confined to the stated case study and its custom FPGA-based RISC-V target platform.

Source: E005, E022

Support for environment ports that interact with external sensors and actors is identified as future work.

Source: E005

The work proposes a model-based deployment methodology that automates application adaptation for phased execution.

Source: E001, E004

Its integrated tooling derives task and runtime artifacts and provides runtime orchestration for the target platform.

Source: E001, E004

The research question concerns automating adaptation and deployment of real-time applications for phased execution on scratchpad-based multicore systems while reducing integration effort.

Source: E001

The work proposes a model-based deployment methodology that automates application adaptation for phased execution.

Source: E001, E004

Its integrated tooling derives task and runtime artifacts and provides runtime orchestration for the target platform.

Source: E001, E004

The methodology is organized around hardware, task-execution, and schedule aspects in a common system model.

Source: E002, E009

The schedule model derives a static hyperperiod schedule from periodic task schedules and developer-provided annotations.

Source: E007

The runtime dispatches scheduled events through timer-triggered handling and performs the associated memory transfers, while LET communication uses buffers.

Source: E006, E011

Memory protection restricts each task to its assigned instruction and data scratchpad regions.

Source: E011

Tasks follow an acquisition, computation, and restitution execution pattern: relevant program and communication state is brought into local memory, computation executes there, and outputs are transferred afterward.

Source: E002

Deployment builds task binaries separately for the cores on which tasks execute and extracts transferable section information from those binaries.

Source: E016

The process generates a runtime configuration and schedule, builds the runtime artifact, and creates minimal kernels for application cores.

Source: E020

The tool evaluates schedule feasibility through offset, computation nonoverlap, event-delay, and positive-slack constraints.

Source: E012, E017, E018

The developer remains responsible for providing a schedule that satisfies the feasibility constraints.

Source: E015

The assumed platform combines per-core scratchpads, shared main memory, and a management core for execution orchestration.

Source: E003, E010

The approach requires scratchpads and memory protection; it uses direct memory access where available, while management-core transfers are a lower-performance fallback.

Source: E010

The implementation study deploys an avionics-control application on a custom FPGA-hosted RISC-V multicore platform with scratchpads, shared memory, an interconnect, and a memory-transfer peripheral.

Source: E022

Task execution times were measured on the hardware platform rather than established through a worst-case execution-time analysis.

Source: E008, E013

Memory-transfer behavior was characterized by repeated measurements across a range of transfer sizes and represented with a conservative linear timing model.

Source: E013, E021

The study reports maximum observed static overheads for schedule events and the task communication and transfer operations, excluding memory-transfer time, based on repeated measurements.

Source: E013, E014

The methodology was demonstrated through deployment of the case-study application, including a generated schedule and an execution trace covering a hyperperiod; the displayed trace uses an adjusted hyperperiod for visibility.

Source: E005, E019

Separating runtime and task binaries avoids source-level framework integration and is intended to minimize impact on task implementations.

Source: E016

The current deployment process requires task implementations to be supplied as C source code.

Source: E016

Evaluation is confined to the stated case study and its custom FPGA-based RISC-V target platform.

Source: E005, E022

Support for environment ports that interact with external sensors and actors is identified as future work.

Source: E005