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.

Schedule a call » Contact us »

Learn more

What is Rapita's multicore timing analysis solution?

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.

What components are involved in your multicore timing analysis solution?

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-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.

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

Can I take advantage of individual components of the multicore timing analysis solution?

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:

Tool licenses (RapiTest, RapiTime, RapiTask)
Services to integrate automation tools to work with your multicore system
RTBx hardware to collect trace data from your multicore system
Generic microbenchmark libraries
Services to port microbenchmarks to your multicore system
Services to perform multicore timing analysis

Can your solution help me with certification aspects of my multicore project?

Yes. Our multicore timing analysis solution can be used to produce timing evidence needed to satisfy DO-178C objectives (in line with CAST-32A guidance), and ISO 26262 standards.

Why don't you have a tool that automates the entire process?

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.

Which hardware architectures can you analyze?

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.

Which metrics can you collect from my multicore platform?

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.

How many performance counters can you collect per test?

This depends on your multicore platform.

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.

Can you analyze systems using asymmetric multiprocessing?

Yes. Our solution makes it easy to specify the core on which you run your tests, and the level of resource contention to apply from each other core in the system.

We can also analyze systems that use non-synchronized clocks such as those often present in AMP platforms, by using the RTBx to timestamp data.

Are there any constraints on the application scheduling, supervisor, or hypervisor?

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.

How do you ensure that worst-case execution time metrics are non-pessimistic?

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.

Do you verify the behavior of microbenchmarks?

Yes. We develop and test microbenchmarks against appropriate requirements, e.g. microbenchmark M should access resource R when run N times.

Do you test the validity of performance counters?

Yes, we formally test and assess the accuracy of performance counters to ensure the validity of results we collect for the software under analysis.