Multicore tool

Latest news Aerospace Tech Week — November York Aerospace and Rocketry Society Update. What's in a good qualification kit?

Introducing the RapiTest Editor. Software verification on the Solar Orbiter. AMC Embedded Software Testing Tools. Aerospace Tech Week Americas Resources Technical resources for industry professionals. Latest White papers.

Latest Videos. Latest Case studies. Company Discover Rapita. Careers Working at Rapita. In the CASTA position paper published by the FAA, an interference channel is defined as "a platform property that may cause interference between independent applications". 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.

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. Our customers have qualified Rapi Time on several DOC DAL A projects where it has been successfully used to generate certification evidence by some of the most well-known aerospace companies in the world.

See our Case Studies. As well as providing a mature tool chain, we support the customer in ensuring that their test data is good enough, so that the timing information they generate from the target is reliable.

We also assess available observability channels as part of a processor analysis. This primarily applies to the use of performance counters, where we assess their accuracy and usefulness for obtaining meaningful insights into the system under observation. It is possible for companies to perform multicore timing analysis internally, but it is a highly complex undertaking which is very costly in terms of budget and effort.

Anecdotally, one of our customers reported that it took them five years and a budget in the millions of dollars to analyze one specific platform. Our Multicore Timing Solution and CASTA Compliance Solution are typically delivered as a turn-key solution, from initial system analysis and configuration all the way through to providing evidence for certification.

Some customers prefer to outsource only parts of the process to Rapita. For example, it is possible for a customer to purchase Rapi Daemons under license and use them to gather and analyze their own data. This includes, but is not limited to:.

RTOS vendors may provide partitioning mechanisms for their multicore processors, but these do not guarantee the complete elimination of multicore interference. Instead, they are designed to provide an upper limit on interference, sometimes at the expense of average-case performance. Yes: our approach can be used to get an in-depth understanding of how sensitive software can be to other software.

For example:. The information from this type of analysis can also provide insights into potential improvements to the implementation of the two tasks. Sensitive tasks are not always the guilty party: other tasks can be overly aggressive and cause delays in the rest of the system. For safety reasons, WCET will always be somewhat pessimistic. However, techniques that work well for single-core systems risk generating a WCET that is unreasonably large when applied to multicore systems, because the effects of contention can become disproportionate.

The objective, therefore, is to calculate a value that is plausible and useful, without being optimistic. Optimism in relation to WCET is inherently unsafe. It is possible to lessen the pessimism in WCET analysis by viewing the processor under observation through this paradigm. The degree to which we can reduce pessimism is dependent on how effectively we can analyze the system.

Factors influencing this include:. Cache partitioning is all about predictability, not performance. Your code may execute faster on average without cache partitioning, but it probably wouldn't be as predictable and could be quite sensitive to whatever executes in parallel. Cache partitioning aims to remove all the sensitivity to other tasks sharing the caches, thus making your task more predictable — but potentially at the expense of overall performance.

In critical systems, predictability is of far greater importance than performance. To analyze 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 Rapi Daemons the applications that generate contention on the resource.

Context switch information is also very valuable when performing multicore timing analysis. 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 RTB x to timestamp data.

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. Developing a one-button tool solution for multicore timing analysis would be impossible. 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. It is possible to collect a range of metrics by instrumenting your source code with the Rapita Verification Suite R VS , including a range of execution time metrics:.

It is also possible to collect information on events in your hardware using performance counters. The information we can collect depends on the performance monitoring unit s or equivalent of your system, but typically includes events such as L2 cache accesses, bus accesses, memory accesses and instructions executed.

We can also collect information about operating system activity such as task switching and interrupt handling via event tracing or hooks. Yes, we formally test and assess the accuracy of performance counters to ensure the validity of results we collect for the software under analysis.

Rapita Systems are uniquely positioned to offer the combination of expertise and tools required to effectively perform multicore timing analysis. Whilst the challenge of certifying multicore systems for safety-critical applications is a relatively new one for the industry as a whole, we have been researching this area for over a decade.

Rapita are working with key industry stakeholders, including major chip-manufacturers like NXP , to support them in refining the evidence required to satisfy certification authorities. Rapita have extensive experience in providing software verification solutions for some of the best-known aerospace and automotive companies in the world. Our multicore timing analysis solution comprises three components: a process, tool automation, and services. 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 Rapi Test and collect timing data Rapi Time and other metrics such as scheduling metrics Rapi Task from them.

Performance information is critical for most software development tools, including performance analysis tools, auto-parallelizing compilers, and other parallelizing tools. Moreover, operating systems, middleware, and other runtime libraries require basic architectural information for system configuration.

In addition, the SHIM standard can be used with hardware modeling to support architecture exploration. Inquiries regarding membership in the Multicore Association and participation in this working group should be made to Markus Levy markus. In line with the other working groups of the MCA, the SHIM specification will ultimately be publicly available to ensure unconstrained industry-wide adoption. Participation in this working group will ensure that your ideas are considered and potentially integrated into the specification.

The working group expects to complete the first SHIM specification in