CTIC CONFERENCE – MAY 2013
www.thalesgroup.com
Development and certification
of Avionics Platforms on MultiCore processors
Marc GATTI – August 29th, 2013
Context
2 /


This presentation is based on the final report
that concludes the MULCORS project contracted
with EASA.
The reports
provides the main outputs,
recommendations and conclusions per EASA
Specifications attached to the Invitation to
Tender EASA.2011.OP.30.

CTIC CONFERENCE – MAY 2013


Access to MULCORS report
https://www.easa.europa.eu/safety-andresearch/research-projects/large-aeroplanes.php
AGENDA
3 /
Multi-core:






CTIC CONFERENCE – MAY 2013

Introduction
Problems to Solve
Regarding certification
Software Aspects
Failure Mitigation Means & COTS Relative
Features
Conclusion
CTIC CONFERENCE – MAY 2013
4 /
Introduction
MULTI-CORE
Multi-Core: Introduction
5 /

CTIC CONFERENCE – MAY 2013


Multi-Core processor
Architecture: Unified
Memory Access
Multi-Core processor
Architecture: Distributed
Architecture
Multi-Core processor
Architecture: Single
Address space, Distributed
Memory
Multi-Core: Introduction
6 /
Airb. SW
Airb. SW
Airb. SW
Drivers
Drivers
Drivers

O.S.
O.S.
O.S.

Intended Function
BSP
BSP
BSP
Core
Core
Core
Core
Core
Core
Cache
Cache
Cache
Cache
Cache
Cache
BUS
Register
BUS
Register
Register

Register
EXT MEMORY
External Network

HW adaptation Layer (BSP)
Hypervisor layer (when required)
Operating System
Drivers
Airborne Software
External Bus

Hypervisor
CTIC CONFERENCE – MAY 2013

EXT MEMORY
Register
Register
Register
INTERCONNECT
Register
7 /
Problems to Solve
CTIC CONFERENCE – MAY 2013
MULTI-CORE
Multi-Core: Introduction
8 /
CTIC CONFERENCE – MAY 2013

What’s a multicore processor?

Multicore processor characterized by N (N ≥ 2) processing cores + a set of
shared resources (Memories, PCIe, Ethernet, Cache, Registers, etc.)

Two main types of processors


The first one where interconnect between cores is based on an arbitrated bus

The second one where interconnect between cores is based on a network
Multicore management in certified embedded platform can be summarize to
shared resources conflicts management for DAL_A, DAL_B or DAL_C
constraints
Multi-Core: Introduction
9 /

Access conflits

Interconnect between cores

If InterConnect = bus  Accesses arbitration is done at this level

If InterConnect = network  Accesses arbitration depend of numbers of authorized
parallel routes (Memories accesses, Bus accesses, Networks accesses, etc.)
Conflicts
Management
CTIC CONFERENCE – MAY 2013
Conflicts
Management
Conflicts
Management
Conflicts
Management
Conflicts
Management
Multi-Core: Introduction
10 /

DETERMINISM IN EMBEDDED AIRCRAFT SYSTEMS

Abstract notion partially described in DO-297
 Definition based on





Multicore COTS Processors

CTIC CONFERENCE – MAY 2013
Execution Integrity
WCET analysis
Platform Usage Domain
Robust Partitioning (not only for IMA system)
Conflicts Management
 Spatial Management: how to manage accesses to be sure that one
core can’t access to a space reserved for another core.
 Temporal Management:
 For Memory Accesses
 Operating System
 Architecture Choice regarding Industry needs (AMP or SMP)
11 /
Regarding Certification
CTIC CONFERENCE – MAY 2013
MULTI-CORE
12 /

CTIC CONFERENCE – MAY 2013

Processor Selection
Manufacturer Selection criteria
 Experience in Avionic domain
 Experience with the certification process
 Publication
 Life expectancy
 Long term support
 Design information on COTS processor
 Robustness tests like SEE (Single Event Effect) or SER
Processor Architecture Focus
 Virtual Memory service
 MMU components
 Use of hierarchical memory to improve Software
performances
Multi-Core Processor features
13 /

INTERCONNECT





The first shared resource between cores.
Interleaves concurrent transactions sent by the cores to the
shared resources
Architecture and impact on determinism
Architecture and partitioning insurance
Interconnect services to be managed
 Arbitration



of incoming requests
Arbitration rules
Arbiter internal logic
Network topology
 Allocation of the physical destination devices
 Allocation of a path to the destination.
 Support for atomic operations,
CTIC CONFERENCE – MAY 2013

Hardware locking mechanisms
 Snooping mechanisms for cache coherency
 Inter Processors Interruptions (IPI) for inter-core
communications
Multi-Core Processor features
14 /

SHARED CACHE

Shared cache in Embedded Aircraft Systems requires a solution to the
following problems:
 Shared
cache content prediction.
 Cache content integrity. .
 Concurrent accesses impact.

Cache organizations
 Fully associative
 N-way set associative
 Direct mapped cache

CTIC CONFERENCE – MAY 2013

cache
Replacement policies
CACHE COHERENCY MECHANISM

Required in architecture that integrates several storage devices
hosting same data.

Coherency protocols:
 Invalidate protocols
 Update protocols
Multi-Core Processor features
15 /

SHARED SERVICES

Providing Shared Services among the cores.
 Interrupts
generation and routing to cores
 Core and processor clock configurations
 Timer configurations
 Watchdog configurations
 Power supply and reset
 Support for atomic operations
CTIC CONFERENCE – MAY 2013

CORES

Support execution of multiple software instances in parallel.

Use of inter-core interrupts.

Memory mapping defined in the Memory Management Unit.
 Warning: A non-coherent configuration may weaken Robust Partitioning.
Multi-Core Processor features
16 /

PERIPHERALS: MAIN MEMORY AND I/O’S

Sharing main memory  sharing physical storage resources and
memory controllers.
 Space
partitioning: Storage resource can be partitioned when necessary.
 Sharing

Shared I/O features similar to shared services configuration:
 Access
CTIC CONFERENCE – MAY 2013
accesses to the memory have to be well managed.
simultaneously read and/or write buffers.

Classic rules of time and space partitioning can be applied

Initiate specific protocols operations: uninterrupted access is required during the
protocol execution to be able to fulfill correctly the concerned protocol.
 Concurrent
accesses to shared I/O may occur simultaneously from different
cores.

Some I/O are accessed according to a protocol, others are accessed from a read
and/or write buffer  Atomic access patterns have to be ensured.
17 /
Software Aspects
CTIC CONFERENCE – MAY 2013
MULTI-CORE
Partitioned system features
18 /

Components evolution to take benefit of multi-core platforms


The most “flexible” component is the
integration software layer. Possible designs:

A single OS instance shared among all the cores

A private OS instance per core

A virtualization layer hosting several operating systems
in dedicated virtual machines.
Partition Deployment

One partition is activated on all cores and has an exclusive access to platform
resources
CTIC CONFERENCE – MAY 2013
 Symmetrical

Multi-processing (SMP).
Each partition are activated on one core with true parallelism between partitions
 Asymmetrical Multi-processing (AMP).
Operating System global view
19 /
From Single Core to Multi-Core in AMP (Asymmetric multi-processing)
APP1
APP2
APP3
T1
T1
T1
T2
T2
T3
T3
T2
T3
T4
T4
T5
Space & Time Partitionning
Space & Time Partitionning
Space & Time Partitionning
Operating System
Operating System
Operating System
CORE
CORE
CORE
BRIDGE
CTIC CONFERENCE – MAY 2013
Memory
Controller
I/O
Controller
INTERCONNECT
BUS /
Network
Interface
Memory
Controller
Solve
Conflict
I/O
Controller
BUS /
Network
Interface
Memory
Controller
Operating System global view
20 /
From Single Core to Multi-Core in SMP (Symmetric multi-processing)
APP1
T1
APP2
APP3
T1
T1
T1
T2
T2
APP1
T2
T2
T3
T3
T3
T4
T4
T3
T5
T4
Space & Time Partitionning
Space & Time Partitionning
Operating System
Operating System
CORE
BRIDGE
CTIC CONFERENCE – MAY 2013
Memory
Controller
I/O
Controller
CORE
CORE
INTERCONNECT
BUS /
Network
Interface
Memory
Controller
Solve
Conflict
I/O
Controller
BUS /
Network
Interface
Memory
Controller
Current mono-core concept
21 /
APP2
APP1
T1
APP3
T1
T1
T2
T2
T3
T2
T3
T3
T4
T4
T5
Space & Time Partitionning
Operating System
CORE
BRIDGE
Memory
Controller
I/O
Controller
BUS /
Network
Interface
Thread /
Process
T4
T3
T1
T3
T3
T2
Partition 1
T1
Partition 2
T3
T2
T2
T1
T4
T1
T2
T1
OS
Core
CTIC CONFERENCE – MAY 2013
T5
T4
T1
T1
Appli. 1
T
Appli. 2
T
Appli. 3
T
idle
Partition 3
Partition 4
time
22 /
APP4
APP1
APP3
APP2
T1
T1
T1
T1
T1
T2
T3
T3
T2
T2
T3
T3
T4
T3
T4
T1
T2
T2
T2
AMP
APP5
APP5
T4
T3
T5
Space & Time Partitionning
Space & Time Partitionning
Operating System
Operating System
CORE
CORE
INTERCONNECT
Core 2
Memory
Controller
T5
T2
T2
T2
T1
T1
T3
T3
T2
T1
T2
T1
Partition 2.2
T1
T1
Partition 2.4
Partition 2.3
T4
T3 T3
T1
T3 T3
T3
T2
T1
Partition 1.1
T1
Partition 1.2
T3
T2
T2
T1
T2
T1
OS 2
T3
T3
Thread /
Process
T4
T4
Partition 1.1
CTIC CONFERENCE – MAY 2013
BUS /
Network
Interface
I/O
Controller
T1
T1
OS 1
Core 1
Memory
Controller
Appli. 1
T
Appli.2
T
Appli 3
T
Appli 4
T
Appli 5
T
Appli 6
T
Appli 7
T
idle
Partition 1.3
Partition 1.4
time
SMP
23 /
APP2
APP1
T3
APP3
T2
T1
T3
T1
T4
T2
In SMP mode, Processes,
Threads or Tasks should be
allocated to cores statically to
achieve determinism
T2
T4
T1
T3
T5
Space & Time Partitionning
Operating System
CORE
CORE
INTERCONNECT
I/O
Controller
T2
BUS /
Network
Interface
T2
Memory
Controller
T2
Thread /
Process
T2
T5
T4
T1T1
Partition 1
T4
T4
T3
T3
T1T3
Partition 2
T1T1
Partition 3
OS
Core 1 Core 2
CTIC CONFERENCE – MAY 2013
Memory
Controller
T3
T1
Appli. 1
T
Appli. 2
Appli. 3
T
T
idle
T1
Partition 4
time
24 /
Failure Mitigation Means & COTS Relative Features
CTIC CONFERENCE – MAY 2013
MULTI-CORE
Multi-Core: Failure Mitigation
25 /

FMEA and/or FFPA for a single or a multi-core processor is
not achievable at processor level


Software Error Rate  SEE (Single Event Effect)


Measurements on SER are usually performed by the manufacturers on
their own
Deep Sub Micronics

CTIC CONFERENCE – MAY 2013
Mitigation has to be provided, by the equipment provider, at board level
where this processor is used
DSM has impact of long term reliability
CTIC CONFERENCE – MAY 2013
26 /
CONCLUSION
CONCLUSIONS
27 /


Complexity of Multi-Core Processors

Has increased over the past few years,

Level of demonstration for design assurance remains at least the same
as or better than for COTS without such increment in complexity.
A COTS component remains a COTS component

CTIC CONFERENCE – MAY 2013

Features proprietary data from the COTS manufacturer
Approaches:

Access to additional data under agreements with the COTS manufacturer

And/or mitigation of potential COTS faults or errors at board or equipment
level,
CONCLUSIONS
28 /


MULCORS put emphasis on specific Multi-Core features
linked to Shared Resource Accesses like Memory, Bus,
Network, Internal Registers, Clock Management, etc.
Features that are the main differences between single-core
and multi-core devices that have to be managed

Airborne Software Level

Airborne Software behavior

Airborne Software applications allocation to cores can demonstrate the non-interaction
between cores.
 Interconnect
CTIC CONFERENCE – MAY 2013


behavior
Shall be well known and well managed
Hypervisor level

Hypervisor can be used to constraint the behavior of the interconnect.

Constraints reduce performances but offer determinism