Analysing the timing of multi-cores

For the last 3 years, Rapita has been a participant in the MERASA (Multi-Core Execution of Hard Real-Time Applications Supporting Analysability) project. The motivation of the project is that modern processors are increasingly using multi-core architectures to improve processing power, but nobody has a clear way to analyse the timing behaviour of such systems.

While increasing the speed of a processor is difficult due to increased power consumption and the limitations of silicon feature sizes, adding more cores can be comparatively cheap. Especially in the embedded market, the combination of multiplied processing power and low power requirements is very attractive. Unfortunately, for safety-critical systems there is a problem.

In a traditional single-core multitasking system, two applications can often share the same hardware with minimal difficulty. The operating system is able to ensure that the deadlines are met, and that misbehaving tasks are terminated or throttled without disrupting the behaviour of other real-time tasks. Similarly, in isolated multi-processing systems, such as distributed networks, tasks can operate in isolation and the only scheduling contention appears at the network layer. This can be handled by real-time network protocols, and the coarse level of synchronization needed can be handled by traditional scheduling approaches.

In multi-core and symmetric multiprocessing (SMP) systems, the interaction between tasks becomes finely interwoven at the instruction level: usually the main memory, system bus, I/O interfaces and increasingly L2 and higher cache are shared, introducing many opportunities for conflicts between the tasks.

Most importantly from a worst-case analysis perspective, these effects are often not bounded: extremely large delays can be seen when accessing memory simultaneously from two cores, and it's very difficult to pin down a maximum latency.

MERASA attempts to solve this problem by introducing techniques to place an upper bound on these interferences, enabling a more accurate worst-case timing analysis.

This is the first of a series of posts covering some of the outcomes from a project which finishes in October.