As computing power continues to evolve, multicore processors (MCPs) have become the standard, offering improved performance and efficiency. However, with this evolution comes new challenges—especially when it comes to timing and resource allocation.
On a single-core processor, all resources, including memory, are dedicated solely to that core. But introduce multiple cores, and suddenly, these resources must be shared. This sharing can lead to timing delays as different tasks compete for access.
For instance, this diagram illustrates that when hierarchical memory is shared, interference can occur in multiple areas. This 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 peak, you get a broad distribution with a long tail.
Hardware interference paths in shared hierarchical memory
While this issue is generally insignificant outside of safety-critical applications, it becomes crucial where both safety and precise timing are essential.
DO-178C is the primary document referenced by certification authorities to approve all commercial software-based civil aviation systems, and A(M)C 20-193 contains supplementary guidance to help apply that standard to multicore-based applications.
No matter what sector you work in, this document is worth a look because the objectives it specifies for the use of MCPs in critical applications are logical and constructive, and not sector specific. The documentreferences robust resource and time partitioning, which can be arranged by various means including RTOSs and hypervisors. The thinking is that correctly configured, such platforms can remove or greatly reduce interference issues to the extent that the different cores can be treated as separate devices from the perspective of WCET
However, there is a caveat. Here’s how robust partitioning is typically applied using (for example) a separation kernel/hypervisor:
Applying robust partitioning using a separation kernel/hypervisor
“Guest” installations run in Virtual Machines. Each VM is a complete computing environment configured by a system designer, who specified each VM component: CPU cores, graphics controller, memory, and virtual, paravirtual and physical devices.
However, only a few of these Hardware Shared Resources are available for explicit allocation. The majority of HSRs cannot be cleanly partitioned because they are implicitly allocated the instant a Software Partition (SWP) accesses them. So, the processors must compete on a first-come-first-served basis for such resources, and stall for numerous cycles if the HSR is busy.
This makes restricting a SWP to its allocation of HSRs by means of robust partitioning alone practically unachievable.
Unlike single processor applications, even without the complication of interference channels the task of finding a schedule of X tasks on Y processor cores such that all tasks meet their deadline has no efficient algorithm. Combined with the challenge of multicore interference channels, the resulting situation demands a rethink of many established practices reliant upon the constraints implied by single-core devices.
These challenges mean that verification and validation in the MCP environment is more empirical than for SCPs, and for that reason Wind River and Rockwell Collins recently emphasized the need for feedback loops in the development process. It is highly likely that interference research will lead to changes in system or software requirements, and conversely that changes in system functional requirements will drive new interference channels or affect existing ones
An iterative process for interference analysis
The challenges posed by hardware interference in multicore processors (MCPs) highlight the complexities of modern computing, particularly in safety-critical environments. While robust partitioning and certification frameworks like DO-178C and A(M)C 20-193 provide structured approaches to mitigate interference, they are not complete solutions. The unpredictable nature of shared resource contention makes worst-case execution time analysis more difficult and necessitates empirical validation approaches.
As the industry continues to refine its understanding of MCP behaviour, ongoing research and iterative development processes will be essential to ensuring both reliability and safety.
The optimal solution to this conundrum at present 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