Multicore Processor (MCP)have long been part of our everyday lives. They are a feature of our laptop PCs, our phones, and our tablets. MCP designs address the problem of processors hitting the ceiling of their physical limitations in terms of their clock speeds and how effectively they could be cooled and still maintain accuracy. By moving to extra cores on a single processor chip, manufacturers avoid problems with the clock speeds by effectively multiplying the amount of data that could be handled by the Central Processing Unit (CPU).
Standard (open loop) control processing
Computing systems ranging from laptop PCs and mobile devices right through to industrial control systems, automotive systems and aeronautical applications are designed to run one or more tasks concurrently (sidebar).
Laptops and mobile devices deploy standard control processing, where the control process runs at a particular speed with no deadline. Increasing the performance of these systems is a simple matter of increasing the speed of the processor.
Laptops and mobile devices deploy standard (aka open loop) control processing, where the control process runs at a particular speed with no deadline. Increasing the performance of these systems is a simple matter of increasing the speed of the processor.
Real time (closed loop) control processing
Real-time control systems are closed loop, allowing only a tight time window to gather data, process that data, and update the system. If the time window is missed, then the stability of the system is degraded – and that can be catastrophic to critical applications.
The closed loop process must complete its execution within an allotted time
Unlike our laptops and mobile phones, until recently these hard real-time applications have been dedicated to single core devices. Indeed, until very recently they were simply not sanctioned for civil aviation applications, for example.
In principle, compared to a discrete multi-processor design, multi-core processors offer several significant benefits including:
Hardware shared resources
The problem is that the use of MCPs increases the risk of interference between processing cores, due to Hardware Shared Resources (HSRs). This interference presents an issue when designing a system that not only requires repeatable system output given a set of inputs but also ensures that applications are executed within a given repeatable time frame.
For instance, this diagram illustrates that when hierarchical memory is shared, interference can occur in multiple areas.
Hardware interference paths in shared hierarchical memory
The interference doesn’t just cause minor delays—it widens the execution-time distribution, creating an unpredictable execution pattern. Instead of a sharp, well-defined execution time peak, you get a broad distribution with a long tail.
Hardware interference widens the execution time distribution
The problem with robust partitioning
In principle, robust software partitioning can help because it allows resources to be allocated to each partition – and hence the tasks running in it. The problem is that the majority of HSRs cannot be cleanly partitioned because they are implicitly allocated only when a task in a software partition (SWP) accesses them.
This makes restricting a SWP to its allocation of HSRs practically unachievable – especially given the scale of problem exhibited in many MCPs. For example, everything in the shaded area of the Xilinx ZYNQ UltraScale+ MPSoC block diagram (below) is an HSR, and only a handful can be explicitly allocated.
Xilinx ZYNQ UltraScale+ MPSoC block diagram
While multicore processors have revolutionized general-purpose computing by improving performance, power efficiency, and form factor, they pose significant challenges for hard real-time applications. The fundamental issue lies in hardware shared resources (HSRs), which introduce unpredictable interference between processing cores. This interference results in execution-time variability, making it difficult to guarantee that critical tasks will complete within strict timing constraints.
Despite advances in software partitioning and resource allocation strategies, the reality is that most HSRs cannot be fully isolated, leading to non-deterministic system behaviour. For safety-critical applications such as aerospace, automotive, and industrial automation, where precise timing is non-negotiable, these uncertainties present significant challenges to the adoption of multicore processors.
The optimal solution to this conundrum is a combination of precise static analysis to identify the most demanding source code, and a more empirical tuning of system configuration through execution time measurement and interference analysis.
More information on the challenges of safely designing hard real-time applications for MCPs and LDRA’s contribution to a solution can be found here:
Blog: A holistic approach to embracing the adoption of MCPs
Blog: Why hardware interference poses a challenge to the adoption of MCPs
Website: Worst-Case Execution Time (WCET) and execution time analysis in critical embedded systems
Mark Pitchford has over 30 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally. Since 2001, he has worked with development teams looking to achieve compliant software development in safety and security critical environments, working with standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0.
Mark earned his Bachelor of Science degree at Nottingham Trent University, and he became a Chartered Engineer over 35 years ago. He now works as Technical Specialist with LDRA Software Technology.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707