Multicore Timing Analysis - Discover more

Discover Multicore Timing


Multicore Timing analysis for Critical Systems

The critical embedded industry is moving towards the use of multi-core rather than single-core processors due to improved performance. The increased performance of multicore and manycore systems per unit area is especially sought after in the embedded aerospace and automotive industries due to the limited physical space often available and the ever-increasing complexity of software in these industries.

However the increase in computational power of complex multicore systems comes at a price; these systems are less predictable than their single-core counterparts. Multicore processors can suffer from interference channels which can significantly affect timing behavior of software running on them. These interference channels can be the result of competition for shared resources or a range of other hardware idiosyncracies. When developing software for safety-critical systems, it is essential to identify and quantify these interference channels.

Multicore processor

What is Multicore Timing Analysis?

When developing safety-critical applications to DO 178C (CAST-32A) guidelines or ISO 26262 standards, there are special requirements for using multicore processors. Evidence must be produced to demonstrate that software operates within timing deadlines.

The goal of multicore timing analysis is to produce execution time evidence for these complex systems. In multicore processors, multiple cores compete for the same shared resources, resulting in potential interference channels that can affect execution time. Accounting for this interference and producing robust execution time evidence is a challenge addressed by Rapita’s Multicore Timing Solution.

Downloads


Challenges of multicore timing analysis

‘‘Using multicore processors poses specific challenges in the critical embedded domain. As traditional worst-case execution time analysis methods don’t take interference effects into account, we need to use new methods.‘‘

In the critical automotive domain, the rapid developmnent of technologies such as autonomous driving and Advanced Driver Assistance Systems (ADAS) has placed increasing importance on the safety of multicore systems. Per ISO 26262, multicore software should be free from cascading failures caused by software failing to meet timing deadlines.

In the critical aerospace domain, worst-case timing evidence must be provided to certification authorities for multicore systems certified against DO-178B or DO 178C. In this context, the use of multicore architectures is addressed specifically in the CAST-32A guidance paper.

Validating the timing requirements of multicore systems offers new challenges. In multicore systems, the timing behavior of a task is affected not only by the software running on it, and its inputs, but also by contention over resources shared with other tasks.

This contention causes interference to the timing behavior of the task. As traditional worst-case execution time analysis methods don’t take interference effects into account, we need to use new methods, such as Rapita Systems' Multicore Timing Analysis Solution.

What is an interference channel?

In the CAST 32A position paper published by the FAA, an interference channel is defined as "a platform property that may cause interference between independent applications". This definition can be applied to a range of ‘platform properties’, including thermal factors etc.

Of these interference channels, interference caused by the sharing of certain resources in multicore systems is one of the most significant in terms of execution times. Interference based on shared resources may occur in multicore systems when multiple cores simultaneously compete for use of shared resources such as buses, caches and main memory.

Rapita’s Multicore Timing Solution analyzes the effects of this type of interference channel.

Example

This is a very simple example of a shared resource interference channel.

In this simplified example, tasks running independently on the two cores may need to access main memory simultaneously via the memory controller. These accesses can interfere with each other, potentially degrading system performance.

Solving the challenges of multicore timining analysis

Our multicore timing analysis solution comprises three components: a process, tool automation, and services. Our multicore timing analysis process is a V-model process that we developed in line with DO 178C and CAST 32A. It follows a requirements-based testing approach that focuses on identifying and quantifying interference channels on multicore platforms.

The tools we have developed let us apply tests to multicore hardware (RapiTest) and collect timing data (RapiTime) and other metrics such as scheduling metrics (RapiTask) from them. We use RapiDaemons (developed by the Barcelona Supercomputing Center) to create a configurable degree of traffic on shared hardware resources during tests, so we can analyze the impact of this on the application’s timing behavior.

Our multicore timing analysis services include tool integration, porting RapiDaemons, performing timing analysis, identifying interference channels, and others depending on customer needs.


Multicore Timing Services
  • Combination of RapiDaemons
  • Mature toolchain, including RapiTest and RapiTime
  • Engineering expertise to understand multicore systems in enough depth to perform the analysis
Learn more »

What is a RapiDaemon?

A RapiDaemon is an application designed to create contention in a predictable and controlled manner on a specific shared resource in a multicore system. The effect of this contention can then be measured to identify interference channels and impacts on execution times.

Rapita have developed and optimized a set of standard RapiDaemons that target shared resources common to most multicore architectures, such as main memory. Some projects will require the creation of custom RapiDaemons for a specific architecture.

RapiDaemon

Demo

This demo highlights the effects of interference on multicore execution times on the YOLO real-time object detection software.

It demonstrates a slowdown in task execution time of almost a factor of 10 when we applied contention for shared resources used by that task.