Multicore timing services

Solving the challenges of multicore timing analysis

To continue delivering regular performance improvements or general-purpose processors, manufacturers such as Freescale and ARM have turned to multi-core architectures. Multicore processors are now the norm in general-purpose devices such as laptops and mobile phones.

In the safety-critical software domain, multicore systems pose many new challenges during the certification process. One of the most difficult challenges is the calculation of the worst-case execution time of software, which must be achieved for certification of systems to meet safety guidelines such as DO-178C/ED-12C. Additional guidance on multicore timing in these contexts was released in the CAST-32A paper.

Approaches to timing analysis that are adequate for single core processors do not scale up to effective use on multicore systems. Manual methods are expensive, inaccurate and not easily repeatable, and no tool alone can provide adequate timing analysis estimates.

Rapita Systems' approach for performing timing analysis is offered in collaboration with the Barcelona Supercomputing Center and uses RapiTime to automate the capture and analysis of results from microbenchmarks written from experimental design. This approach provides the right balance of rigor, flexibility, precision and effort to deliver estimates of worst-case execution time that can be used even for the highest software criticality levels.

Find out more

Get in touch today for more information on our multicore timing services and to discuss your needs.

Our multicore timing analysis solution produces metrics to quantify and verify the timing behavior of software run on multicore systems while taking into account the effects of interference between different cores and tasks in the system.

Using a requirements-based testing approach, it combines expert engineering knowledge, microbenchmark software from groundbreaking academic research and industry-leading tool automation support to provide a unique solution that meets the needs of multicore system adoption.

Our multicore timing analysis process is a V-model process that we developed in line with DO-178 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 microbenchmarks (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.

We’re completely flexible, and we understand that different customers have different needs. As such, you can purchase any component of our multicore timing analysis solution separately if that’s what you need. This includes, but is not limited to:

Developing a one-button tool solution for multicore timing analysis would be impossible. This is because interference, which can have a huge impact on a task’s execution time, must be taken into account when analyzing multicore timing behavior.

Analyzing interference effects is a difficult challenge that cannot be automatically solved through a software-only solution. Using approaches developed for timing analysis of single-core systems would result in a high level of pessimism, as it would assume that the highest level of interference possible is feasible, while this is almost never the case.

We can analyze almost all hardware architectures. To analyze an architecture that we haven’t worked with before, we first identify what data we can collect from the hardware, then adapt microbenchmarks for the architecture and implement a strategy to collect data from it. This is all part of the solution.

We can collect a range of metrics by instrumenting your source code with RVS tools – this includes a range of execution time metrics including high-water mark and maximum execution times through RapiTime and scheduling metrics such as periodicity, separation and fragmentation through RapiTask.

We can also collect information on events that occur when your software executes by using performance counters. The information we can collect depends on the performance monitoring unit(s) (or equivalent) of your multicore hardware, often including events such as L2 cache accesses, bus accesses, memory accesses, and instructions executed.

The maximum number of metrics we can collect depends on the performance monitoring unit(s) (or equivalent) on the hardware. An ARM A53, for example, lets us collect at least 30 metrics, but only access 6 in a single test. By running tests multiple times, however, we could collect all 30 metrics.

For the general approach of analyzing how a specific task is affected by contention on a specific resource, we need to be able to synchronize the execution of the task with the execution of microbenchmarks that generate contention on the resource.

The primary constraint on supervisor/hypervisors is that we need to be able to configure the performance monitoring unit of the hardware to observe and record performance counters. Ideally, this should be supported without needing to execute in an elevated mode.

If you run a task while applying levels of interference that are not intelligently designed, execution time results will be wildly pessimistic.

To overcome this, we profile the task under analysis and analyze the sensitivity of the task to interference and the scheduling system being used. Using results from this analysis, we apply a realistic level of interference to the task to produce realistic worst-case execution time results.