This document discusses challenges in qualifying multi-core processors for safety critical systems and presents initial research findings and an interim solution. It outlines that while multi-core processors provide performance benefits, they introduce new assurance challenges due to issues like cache coherence, interference between cores, and unpredictability. Practical experiments showed different software types being most impacted by different types of "enemy processes" designed to stress CPU, bus, or cache usage. The document proposes a stepped approach starting with restricting multi-core capabilities as understanding improves before enabling full multi-core functionality.

1. © Crown copyright 2016 Dstl
21 November 2016

2. Multi-Core (MC) Processor Qualification
for Safety Critical Systems
Dr Mark Hadley & Mike Standish
Dstl, Software and Systems Dependability Team
DSTL/PUB098248. © Crown copyright (2016), Dstl. This material is licensed under the terms of the Open Government Licence
except where otherwise stated. To view this licence, visit http://www.nationalarchives.gov.uk/doc/open-government-
licence/version/3 or write to the Information Policy Team, The National Archives, Kew, London TW9 4DU, or email:
psi@nationalarchives.gsi.gov.uk.
© Crown copyright 2016 Dstl
21 November 2016

3. Caveat
• The contents of this presentation should not be interpreted as
representing the views of the Ministry of Defence (MOD), nor
should it be assumed that they reflect any current or future MOD
policy.
• The information contained in this presentation cannot supersede
any statutory or contractual requirements or liabilities and is
offered without prejudice or commitment.
© Crown copyright 2016 Dstl
21 November 2016
.

4. What’s To Come
© Crown copyright 2016 Dstl
21 November 2016
.
What is
Multi-
Core?
Outline
of the
Problems
Practical
Research
Findings
An
Interim
Solution
Summary

5. What is Multi-Core?
© Crown copyright 2016 Dstl
21 November 2016
.

6. Multi-Core (MC): A Brief Description
• Single-core architectures have their limitations:
– Increased transistor density and higher clock frequencies cause more power
to be consumed per chip.
– Performance improvement resulting from an increase in the number of
transistors is relatively poor.
• MC is a solution to these limitations:
– Better increase in performance using MC than a more complex single core
design using the same die area.
– MC can reduce the power required for the same level of computation.
• Industry moving to MC and single-core chips are becoming obsolete.
– Space, automotive, and avionics domains are all moving to MC.
© Crown copyright 2016 Dstl
21 November 2016
MC - Multi-Core

7. MC Processor within an Architecture
© Crown copyright 2016 Dstl
21 November 2016
Multi-Core Processor
Core
1
RTOS
App 3App 2App 1
L1/L2
Cache
Core
2
L1/L2
Cache
Core
3
L1/L2
Cache
Core
4
L1/L2
Cache
L3 Shared Cache
Bus Interface
MC – Multi-Core
App – Application
RTOS – Real-Time Operating System
An
example!

8. The Current Problems
© Crown copyright 2016 Dstl
21 November 2016
.

9. MC has its Technical Challenges
• MC chips and designs have less pedigree than single-core architectures.
• How best to implement MC in terms of the Real-Time Operating System
(RTOS)?
– AMP (Asymmetric Multiprocessing), SMP (Symmetric Multiprocessing), BMP
(Bound Multiprocessing), use of Hypervisors etc.
– Combination of RTOS and Hypervisor (standard or DO-178B/C compliant)?
• Number of architectural design issues:
– Worst Case Execution Time (WCET).
– Cache Coherence.
– Interference – Shared Memory, Peripheral Devices.
– Program Coherence – Concurrency (Task Scheduling), Sequence of
Execution.
© Crown copyright 2016 Dstl
21 November 2016
MC - Multi-Core

10. Lack of Guidance for Airborne Use
• Neither RTCA/DO-254 nor RTCA/DO-178C documents specify how
microprocessors should be assured:
– (RTCA 2000. DO-254. Design Assurance Guidance for Airborne Electronic
Hardware).
– (RTCA 2011. DO-178C. Software Considerations in Airborne Systems and
Equipment Certification).
• Microprocessors are listed as Commercial-Off-The-Shelf (COTS)
components in RTCA/DO-254 (Glossary of Terms).
• CAST 32 provides some guidance (highlights potential issues), however,
it only relates to 2 core microprocessors.
– (CAST 2014. Position Paper: Certification Authorities Software Team (CAST)
32. Multi-Core Processors).
© Crown copyright 2016 Dstl
21 November 2016
.

11. Practical Research Findings
© Crown copyright 2016 Dstl
21 November 2016
.

12. Experiment Set-Up
• Four different examples of Software Under Test (SUT):
– Numerical Recipes (Mathematical algorithms).
– Matrix Multiplication.
– Memory Manipulation (General purpose activities).
– Cache Intensive (Memory throughput biased).
• Three different types of Enemy Process (EP), designed to target:
– CPU Use.
– Bus Use.
– Cache Use.
• Measure the effect of each EP on each SUT.
– No combinations of different EPs were considered.
© Crown copyright 2016 Dstl
21 November 2016
.

13. High-Level Results (1)
• SUT: Memory Manipulation
– Bus contention EP is biggest challenge for this form of SUT. Cache, less so;
CPU has little observable effect.
© Crown copyright 2016 Dstl
21 November 2016
EP - Enemy Process
SUT – Software Under Test

14. High-Level Results (2)
• SUT: Cache Intensive
– Cache EP has biggest effect (not surprising). It also has a significant effect
on predictability of timing.
© Crown copyright 2016 Dstl
21 November 2016
EP - Enemy Process
SUT – Software Under Test

15. • SUT: Cache Intensive; EP: CPU.
– An EP appears to provide a performance boost to a SUT: effect is very small;
but it serves as a reminder that MC microprocessors can yield unexpected
behaviours.
High-Level Results (3)
© Crown copyright 2016 Dstl
21 November 2016
EP - Enemy Process
SUT – Software Under Test
MC – Multi-Core

16. An Interim “Solution”
© Crown copyright 2016 Dstl
21 November 2016
.

17. A Stepped Journey
© Crown copyright 2016 Dstl
21 November 2016
.
“Uni-Core”
“Reduced
Multi-Core”
“Full
Capability
Multi-Core”
• “Simpler” architecture.
• “Simpler” to verify.
• Pedigree of use.
• Difficulties obtaining low-
level design data.
• Reduced capability via
restricted implementation.
• Additional difficulties with
verification.
• Full capability via
unrestricted implementation.

18. A Potential Approach
© Crown copyright 2016 Dstl
21 November 2016
MC – Multi-Core
RTOS – Real-Time Operating System
AMP - Asymmetric Multiprocessing
Only one “active” core within a MC
processor with the other cores
“non-active”.
Implemented for software
which can have a
Catastrophic failure
condition (“prevent
continued safe flight and
landing”) or
Hazardous/severe-major
failure condition (“serious
or potentially fatal injuries
to a small number of
occupants”).
Use of certified RTOS to ensure
space and time partitioning within
AMP cluster.
Reduced power management to
ensure no dynamic load shedding.
MC processor usage argument
within similar domains.

19. A Potential Approach (2)
© Crown copyright 2016 Dstl
21 November 2016
Full set of “active” cores within a
MC processor.
Implemented for software
which can have a Major
failure condition
(“discomfort to occupants,
possibly including injuries”)
or Minor failure condition
(“some inconvenience to
occupants”).
Use of non-certified RTOS within
SMP cluster.
MC processor usage argument
within similar domains.
MC – Multi-Core
RTOS – Real-Time Operating System
SMP - Symmetric Multiprocessing

20. Summary
• MC processors are now the prevalent form within most domains
and will be increasingly within the airborne domain.
• Lack of initial guidance on the qualification of MC processors.
• Practical research has demonstrated that MC processors can
display complicated behaviours.
• A stepped approach achieves a balance between MC processor
assurance and capability.
© Crown copyright 2016 Dstl
21 November 2016
MC – Multi-Core

21. © Crown copyright 2016 Dstl
21 November 2016

22. © Crown copyright 2016 Dstl
21 November 2016