share article

Share on facebook
Share on twitter
Share on linkedin

Green Hills Software Extends multicore interference mitigation to Arm Cortex-A72 for DO-178C Level A Applications

News

Green Hills Software has extended its solution for DO-178C Level A multicore interference mitigation to Arm Cortex-A72 processor cores. As part of the INTEGRITY-178 Time-Variant Unified Multi-Processing (tuMP) RTOS, the Bandwidth Allocation and Monitoring (BAM) functionality enables software architects to allocate and enforce bandwidth limits to shared resources for each processor core. By guaranteeing access to shared resources based on application requirements or assurance level, BAM effectively mitigates multicore interference and minimizes multicore worst-case execution time (WCET).

Multicore interference occurs when multiple processor cores attempt to access the same shared resource, such as memory, shared cache, I/O, or the on-chip interconnect. Interference is a significant enough problem to warrant an entire position paper from the Certification Authorities Software Team (CAST-32A) dedicated to identifying problem areas relating to safety, performance, and integrity of software executing in an airborne multicore system. Green Hills Software has demonstrated application WCET growing 8 times longer from just a single interfering core, and up to 13 times longer with 3 interfering cores.

The BAM interference mitigation functionality monitors and strictly enforces the use of the shared resources as defined by the system integrator. When coupled with Green Hills Software’s multicore SoC-specific WCET utility libraries, BAM ensures that critical partitions meet their required deadlines while enabling other lower criticality partitions to execute on other cores simultaneously with no impact on the critical applications. This remains true even as the other partitions are modified or as new partitions are introduced into the system. This is a vital capability for sustainment and growth of critical systems based on multicore architectures.

Even though CAST-32 was first published in 2014 and updated in 2016, some RTOS suppliers are only just now acknowledging that multicore interference is a serious problem and are starting to look for a solution. For example, Lynx Software is “involved with multiple researchers,” including the EU-funded MASTECS project. That project is due to complete in November 2021, with the expected output being timing analysis software tools, not mitigation solutions. Other operating system suppliers just leave this multicore interference for the system integrator to solve. The BAM functionality provides the solution today and has been shipping to customers for years, beginning with Power Architecture e500mc cores.

“Our competitors, such as Lynx Software, noted recently that ‘the FAA has promised to allow the use of multiple cores in a multicore processor chip but only if adequate mitigations can be demonstrated to certifiers, based [on] the CAST-32A specifications.’ Yet no RTOS supplier other than Green Hills Software provides a DO-178C Level A-compliant solution for multicore interference mitigation that meets the CAST-32A requirements,” said Dan O’Dowd, founder and chief executive officer of Green Hills Software.

Although some level of mitigation at the application level is possible, generally it requires retesting and reverification of all the applications executing on the multicore system when any single application changes, thereby incurring significant costs and delays that contribute to vendor lock. In the same way that MMU support and partition schedules need to be implemented in the OS, the enforcement of the multicore interference mitigation needs to be in the OS in order to achieve robust multicore partitioning. INTEGRITY-178 tuMP provides a general solution to multicore interference mitigation, thereby minimizing retesting and verification after any application changes or additions.

Green Hills Software recognized the problem of multicore interference early on and started investing in a solution in 2010. Based upon more than 60 staff-years of research and development into multicore interference analysis and mitigation strategies, the DAL A compliant BAM functionality monitors and enforces the bandwidth allocation of the chip-level interconnect to each of the cores. Because the chip-level interconnect is at the center of interactions between the cores and other shared resources, it is the ideal place to observe and enforce limits on the use of shared resources. BAM emulates a high-rate hardware-based approach to ensure continuous allocation enforcement of the cores’ use of shared multicore resources. This contrasts with a “safety net” approach using coarse-grain thresholding and fault detection to kill or suspend rogue processes. BAM regulates the bandwidth smoothly throughout the application’s execution time window, thereby allowing other applications in the same execution time window to acquire their allocated portion of the shared resources. These capabilities greatly lower integration and certification risks while also enabling integrators to gain the maximum performance advantages of multicore processors.

The INTEGRITY-178 tuMP safety- and security-critical RTOS is designed to simultaneously meet DO-178C design assurance level (DAL) A and the separation kernel protection profile (SKPP v1.03) as defined by the NSA. INTEGRITY-178 tuMP is a multicore RTOS with support for any combination of asymmetric multi-processing (AMP), symmetric multi-processing (SMP), and bound multi-processing (BMP). Specifically, it includes support for running a multi-threaded DO-178C DAL A partition across multiple processor cores in a BMP configuration as required in ARINC 653 Part 1, Supplements 4 and 5, and also SMP configurations as required in ARINC 653 Part 2 Multicore Service Extensions, Supplements 3 and 4. INTEGRITY-178 tuMP was the first RTOS to be certified conformant to the FACE™ Technical Standard, edition 3.0, and remains the only one conformant for all three avionics processor architectures: Arm, Intel and Power Architecture.

Share this article

Share on facebook
Share on twitter
Share on linkedin

Member Login