A Certifiable Approach to Multicore Using Ada

The Ravenscar and Jorvik profiles define deterministic and analyzable execution models, supported by run-time systems of reduced size and complexity. These models enable precise schedulability analysis using established techniques such as Rate Monotonic Analysis (RMA) [13] and Response Time Analysis (RTA) [12].

Ada 2012 introduced a multicore execution model as a conservative extension of single-core fixed-priority preemptive scheduling. Tasks are statically allocated to processors, migration is prohibited, and each processor independently schedules its ready queue. This partitioned approach enables reuse of single-core analysis techniques and simplifies run-time support while maintaining schedulability [3]. Static partitioning provides physical and temporal separation between cores, reducing interference and supporting the determinism requirements of AC 20-193.

While both profiles share the same fundamental execution model (static tasks, fixed priorities, and library-level protected objects), they differ in their synchronization constraints. Ravenscar restricts each protected object to at most one entry with a simple Boolean barrier (a single Boolean variable or attribute), enabling straightforward schedulability analysis. Jorvik relaxes these restrictions by allowing multiple protected entries and general Boolean barriers per protected object, while preserving the bounded-blocking property required for timing analysis.

This paper specifically refers to the GNAT Ada run-time library developed by AdaCore for bare-metal embedded applications. The runtime has evolved over the years to support multiple target platforms, with multicore support added in 2010 for Ada 2012 and continuously improved since then.

The Ada run-time library is composed of passive packages, meaning that its code executes only in response to explicit application calls or external events such as interrupts. It provides the fundamental services required to support Ada programs, in particular tasking and synchronization. The run-time library is statically linked into the embedded executable and must therefore be certified to the same assurance level as the application. It supports a symmetric multiprocessing (SMP) configuration, where there is a single copy of the run-time library and all memory is addressable by every processor.

The core of the run-time system implementing restricted tasking consists of approximately 100 Ada packages totaling about 11 KSLOC, with an average cyclomatic complexity of 2.57, complemented by approximately 1,000 lines of architecture-specific assembly code. These figures correspond to the GNAT Pro run-time library supporting the Ravenscar and Jorvik profiles for Ada 2022.

The multicore run-time library is derived directly from the already certified single-core library and introduces only a minimal set of changes. The run-time system is parameterized by a static configuration constant defining the maximum number of processors. When this value is equal to one, all multiprocessor-specific code paths are statically disabled and optimized out by the compiler. As a result, the generated binary for single-core systems contains no deactivated multicore functionality.

For example, a synchronization operation may include code such as:

where the Multiprocessor condition is defined as:

Here, Max_Number_Of_CPUs is a configuration parameter representing the maximum number of processors available on the target platform.

This design ensures that the single-core and multicore run-time systems share the same code base, with differences limited to 15 conditional constructs. The majority of the run-time code is identical in both configurations, enabling extensive reuse of verification and certification artifacts, including structural coverage and low-level verification evidence, significantly simplifying compliance with standards such as DO-178C, ISO 26262 [8], and EN 50128 [6], and simplifying maintenance.

System initialization is orchestrated by a designated bootstrap processor to avoid race conditions. Upon reset, this processor executes the low-level assembly start-up code responsible for initializing the common hardware.

The bootstrap processor first initializes essential hardware registers and configures the execution level to run in privileged mode, thereby enabling unrestricted access to control registers. It then enables only the minimum hardware features required by the application, such as the floating-point unit (if used) and trap and exception handling mechanisms.

Memory initialization follows, including cache and MMU configuration where applicable, zero-initialization of the .bss section, initialization of global data, and setup of the main stack pointer.

Once memory and processor state have been initialized, the run-time system constructs the internal task control structures. Tasks are statically assigned to processors according to the configuration parameters, and every task is inserted into the ready queue of its statically-assigned processor.

If required by the application, peripheral devices such as system clocks, timers, and UART controllers are initialized at this point. All configured interrupt handlers are installed, including those used for timer expiration and inter-processor communication. Finally, control is transferred to the environment task, which represents the initial execution context of the application.

After the bootstrap processor completes global initialization, the remaining processors are released from reset and execute a simplified initialization sequence. Each secondary processor performs only processor-local setup, such as stack initialization and required interrupt masking.

Secondary processors do not perform global hardware initialization, which avoids duplication of effort and eliminates the risk of race conditions during start-up. Instead, they immediately enter the task dispatching loop.

Each processor includes a statically defined idle task, implemented as a low-power and wait-for-interrupt loop. This idle task has the lowest priority and executes whenever no other task is ready on that processor. The idle task is not part of the application scheduling model and serves only to maintain processor control in a waiting state.

Tasks are statically allocated to processors using the CPU aspect that determines the processor on which the task will activate and execute. If the aspect is not specified, or if the CPU value is Not_A_Specific_CPU, the task is allocated to the first processor. Each processor executes an independent fixed-priority preemptive scheduler. Ready queues are disjoint and processor-local, and tasks are dispatched strictly according to priority. When a task blocks or preempts, it is returned to the ready queue of its assigned processor. No mechanism exists for a task to appear in the ready queue of another processor.

When internal data in the run-time system can be modified by tasks executing in different processors, inter-processor locking mechanisms guarantee mutual exclusion.

The execution of a task (or an interrupt handler) on a given processor may require updates to another processor’s ready queue (and may also force the preemption of the running task). Such cross-processor updates are performed indirectly: an inter-processor interrupt (IPI) is sent to the target processor, which then performs the actual updates to its own data structures locally. This preserves the invariant that each processor is the sole modifier of its own ready queue.

The restricted library-level protected objects defined by the Ravenscar and Jorvik profiles are used for inter- and intra-processor communication and synchronization. The same restrictions that exist in the Ravenscar and Jorvik profiles for single-core apply to the case of a multiprocessor. For multicore systems, protected objects rely on a Fair Lock [7, 18] mechanism that provides bounded blocking and predictable acquisition order.

The fair lock implementation ensures that all lock acquisitions are finite and analyzable, preventing starvation and supporting worst-case execution time analysis. The fair lock maintains a FIFO queue of waiting requestors: each acquisition attempt is assigned a ticket, and processors are granted access in ticket order. This guarantees that any waiting processor obtains the lock within a bounded number of other processors’ critical sections, making the worst-case blocking time statically computable as $B=(n-1)\cdot C_{cs}$, where $n$ is the number of processors and $C_{cs}$ is the maximum critical-section execution time. Lock operations introduce minimal overhead and are invoked only at well-defined synchronization points, consistent with the restricted tasking model. Inter-processor communication is limited to explicit synchronization operations and inter-processor interrupts used to trigger rescheduling on the target processor.

To simplify timing analysis and facilitate efficient implementation when possible, protected objects used only by tasks within the same CPU can utilize the optimized single-core implementation. Ada 2022 introduces CPU affinity for protected objects (ALRM [11], D.16(15/5)), enabling the static optimization of protected operations.

Protected objects not assigned to a specific CPU (i.e., accessed by tasks on different processors) rely on the fair-lock mechanism for inter-processor mutual exclusion. Assigning a protected object to the same CPU as its client tasks eliminates the need for inter-processor synchronization; global protected objects with cross-processor clients are reserved for cases where explicit inter-processor communication is required, and their use introduces the synchronization overhead discussed above.

In Ravenscar and Jorvik-compliant systems, the only mechanism to associate application-level interrupt handling code is by attaching a protected procedure to an interrupt. In a multiprocessor context, the fundamental semantic model remains unchanged; however, additional considerations arise with respect to mutual exclusion and the assignment of interrupts to processors.

Mutual exclusion for interrupt handlers is provided by the protected object semantics defined by Ada. As a result, the same design principles and constraints that apply to intra- and inter-processor synchronization of protected operations apply equally to interrupt handling. In particular, the avoidance of unnecessary inter-processor synchronization is essential to improve determinism and analyzability.

Multicore hardware typically allows interrupts to be delivered to one or more processors through the configuration of interrupt affinity masks. While dynamic or multicore delivery of interrupts may improve average responsiveness in general-purpose systems, it significantly complicates timing analysis and introduces additional sources of interference due to shared interrupt handling paths and cross-processor synchronization.

For high-integrity systems, and in alignment with the objectives of AC 20-193, interrupts are therefore statically assigned to a single processor. Each interrupt is handled by exactly one processor for the lifetime of the application, although different interrupts may be assigned to different processors. This approach eliminates interrupt migration, avoids contention between processors for interrupt handling, and ensures that interrupt-related interference remains strictly local to the processor to which the interrupt is assigned.

Furthermore, allocating interrupts to the same processor as the tasks that use the associated devices (using the Ada 2022 CPU affinity mechanism for protected objects) avoids the need for inter-processor synchronization when accessing shared data. This design reduces interference channels, simplifies worst-case execution-time and response-time analysis, and supports robust partitioning between processors.

Overall, this interrupt handling model directly supports the AC 20-193 objectives of determinism, interference containment, and analyzability by enforcing static interrupt allocation, eliminating dynamic affinity changes, and minimizing cross-processor interactions.

Timing services must be predictable, analyzable, and resilient to interference. The Ada run-time uses hardware timers and static software structures, limiting shared resources and avoiding dynamic behaviors. The approach follows [21] principles and adapts to hardware capabilities.

AC 20-193 requires that the execution model, processor configuration, and dynamic hardware behaviors be clearly defined and reflected in planning data. The static execution model described in Section 3 (fixed tasks, static priorities and affinities, no dynamic task operations, and restricted synchronization) directly satisfies these requirements. It prevents race conditions and deadlocks by construction, eliminates dynamic scheduling decisions, and bounds all component interactions, making the system amenable to static analysis and straightforward to document in planning artifacts.

Where shared hardware resources are unavoidable, such as clocks and timers, their access mechanisms and associated interference are fully specified and bounded, as described in Section 4.6, allowing them to be addressed systematically in verification and timing analysis.

AC 20-193 requires that all multicore processor resources be explicitly identified, configured, and controlled to ensure predictable and repeatable system behavior. This applies both to processing resources (e.g., processor cores and interrupt handling) and to shared hardware resources that may constitute interference channels (e.g., clocks, timers, caches, and interconnects).

In the proposed approach, multicore resources that directly affect the execution model are configured statically during system initialization. These include the set of active processors, interrupt affinity and routing, timing resources (clocks and timers), and basic I/O devices such as the UART. Once initialized, these configurations remain fixed for the duration of system operation and are not modified at run time, in accordance with the determinism and robustness objectives of AC 20-193.

Other multicore-related resources, in particular those associated with shared hardware structures, such as caches and DMA arbitration on the interconnect, are outside the scope of the run-time system and are therefore the responsibility of the application designer. AC 20-193 explicitly requires that the configuration and usage of such resources be defined, justified, and verified.

A central objective of AC 20-193 is the identification and mitigation of interference channels arising from shared hardware resources. Note that even if there is no explicit data or control flow between tasks, coupling exists on the platform level, which can cause interference between them. This analysis is mostly the responsibility of the system designer, but Ada provides mechanisms that minimize contention:

• $\mathrm{■}$

  Tasks and protected objects are statically assigned to processors, minimizing inter-processor contention.

• $\mathrm{■}$

  Interrupts are statically routed to designated processors using hardware affinity mechanisms, reducing asynchronous interference.

The run-time library reduces interference through architectural and configuration mechanisms. For example, the timing services implementation satisfies the following properties:

• $\mathrm{■}$

  Interference identification and mitigation: Shared timing resources are either eliminated (per-processor timers) or explicitly protected (shared timers), making interference channels identifiable and analyzable.

• $\mathrm{■}$

  Partitioned execution: Timing operations respect task-to-processor allocation, and remote effects are mediated exclusively through inter-processor interrupts.

• $\mathrm{■}$

  Bounded execution time: All timing-related operations, including clock reads and alarm handling, execute with statically bounded complexity.

Platforms that provide per-processor timers and 64-bit counters further reduce certification effort by eliminating shared timing state and minimizing synchronization.

Applicants need to demonstrate that the hosted applications function correctly and have sufficient time to execute in the presence of the interference that occurs when all the software is executing on the multicore processor.

The static Ravenscar/Jorvik execution model, as described in Sections 3 and 4, directly supports these objectives. Precise response-time and worst-case execution-time analysis is possible because scheduling is fixed-priority and partitioned. Contention is bounded because synchronization is restricted and uses analyzable fair locks. The explicit specification of task priorities, processor affinities, and protected objects in the source code provides strong traceability from design decisions to verification evidence. The application developer uses these restrictions to simplify their own verification activities. The run-time library itself needs to provide the following verifications based on worst-case scenario for interference:

• $\mathrm{■}$

  Detailed manual review. Ensure proper protection against parallel updates of internal run-time data.

• $\mathrm{■}$

  Test functional behavior

  • –

    Tasks from different processors using shared protected objects. Ensure data access protection and conditional blocking and unblocking of tasks.

  • –

    Tasks from different cores reading clock and setting timers. Ensure Consistent reads and expected ordering of timing activations.

• $\mathrm{■}$

  Verify timing behavior

  • –

    Protected interrupt handler overhead ALRM [11], C.3.1(15). Measure the execution time incurred from the time that an interrupt is asserted until the first user statement of the attached protected interrupt handler.

  • –

    Mutual exclusive access ALRM [11], D.12(6). Measure the time overhead incurred to seize mutually exclusive access to an entry-less protected object.

  • –

    Null delay until lateness ALRM [11], D.9(11). Measure the time to treat a delay request that does not cause the requesting task to block.

  • –

    Delay until lateness ALRM [11], D.9(13/5). Measure the difference between the requested time of delay expiration and the resumption time actually attained by a task following an absolute time suspension

Predictable error detection and containment are essential for high-integrity multicore systems. The Ada language, together with its restricted tasking profiles, provides a structured and analyzable framework for implementing robust safety nets. Application-level logic is responsible for handling timing and functional anomalies with the following mechanisms:

• $\mathrm{■}$

  Task-level exceptions: Ada supports structured exception handling within each task. Exceptions arising from hardware events, run-time checks, or internal computation errors are confined to the task in which they occur, preventing propagation to unrelated tasks and maintaining system stability.

• $\mathrm{■}$

  Static error prevention: The Ravenscar and Jorvik profiles eliminate dynamic task creation, uncontrolled access to shared data, and unbounded priorities. These restrictions reduce the likelihood of runtime errors and make error detection predictable and analyzable.

• $\mathrm{■}$

  Protected object integrity: Synchronization primitives, including protected objects and fair locks, guarantee atomicity and mutual exclusion. Violations, such as attempts to enter a protected object in violation of the ceiling protocol, raise well-defined exceptions, ensuring that erroneous states are detected and contained.

Monitoring processor usage is possible using execution-time clocks in Ada [20]. In the multicore run-time, execution-time clocks are implemented by reading the global hardware counter at task dispatch and preemption points and accumulating the elapsed time per task. Because tasks are statically bound to processors, no migration adjustments are needed, simplifying the implementation. The static nature of the Ravenscar and Jorvik model does limit the range of possible responses to a budget overrun, but the monitoring capability itself is sufficient for detection and logging.