Multicore timing services

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

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

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.

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.