CTIC CONFERENCE – MAY 2013 Development and certification of Avionics Platforms on Multi- Core...

CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

www.thalesgroup.com

Development and certification of Avionics Platforms on Multi-Core

processorsMarc GATTI – August 29th, 2013

2 /2 /

Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.This document is the property of Thales Group and may not be copied or communicated without written consent of Thales S.A.

CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

Context

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.

Access to MULCORS report https://www.easa.europa.eu/safety-and-research/researc

h-projects/large-aeroplanes.php

https://www.easa.europa.eu/safety-and-research/research-projects/large-aeroplanes.php

https://www.easa.europa.eu/safety-and-research/research-projects/large-aeroplanes.php

3 /3 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

AGENDA

Multi-core: Introduction Problems to Solve Regarding certification Software Aspects Failure Mitigation Means & COTS Relative

Features

Conclusion

4 /4 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

MULTI-COREIntroduction

5 /5 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

Multi-Core: Introduction

Multi-Core processor Architecture: Unified Memory Access

Multi-Core processor Architecture: Distributed Architecture

Multi-Core processor Architecture: Single Address space, Distributed Memory

6 /6 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013


EXT MEMORY

Core

Cache

BUS

INTERCONNECT

Register Register RegisterRegister

Register Register

Core

Cache

Core

Cache

Core

Cache

BUSRegister Register

Core

Cache

Core

Cache

EXT MEMORY

Ex

tern

al

Bu

s

Ex

tern

al

Ne

two

rk

BSP BSP BSP

Hypervisor

O.S. O.S. O.S.

Drivers Drivers Drivers

Airb. SW Airb. SW Airb. SW Intended Function

HW adaptation Layer (BSP) Hypervisor layer (when required) Operating System Drivers Airborne Software

7 /7 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

MULTI-COREProblems to Solve

8 /8 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013


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

9 /9 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

Access conflits

Interconnect between cores


Si InterConnect = BUSSi InterConnect = Réseau

ConflictsManagement

ConflictsManagement

ConflictsManagement

ConflictsManagement

ConflictsManagement

If InterConnect = network Accesses arbitration depend of numbers of authorized parallel routes (Memories accesses, Bus accesses, Networks accesses, etc.)

If InterConnect = bus Accesses arbitration is done at this level

10 /10 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013


DETERMINISM IN EMBEDDED AIRCRAFT SYSTEMS Abstract notion partially described in DO-297

Definition based on Execution Integrity WCET analysis Platform Usage Domain Robust Partitioning (not only for IMA system)

Multicore COTS Processors 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 SystemArchitecture Choice regarding Industry needs (AMP or SMP)

11 /11 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

MULTI-CORERegarding Certification

12 /12 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

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

13 /13 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

Multi-Core Processor features

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,

Hardware locking mechanisms Snooping mechanisms for cache coherency Inter Processors Interruptions (IPI) for inter-core communications

14 /14 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013


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 cache Direct mapped cache

Replacement policies

CACHE COHERENCY MECHANISM Required in architecture that integrates several storage devices

hosting same data. Coherency protocols:

Invalidate protocols Update protocols

15 /15 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013


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

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.

16 /16 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013


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 accesses to the memory have to be well managed.

Shared I/O features similar to shared services configuration: Access 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 /17 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

MULTI-CORESoftware Aspects

18 /18 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

Partitioned system features

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.

Components evolution to take benefit of multi-core platforms

Partition Deployment One partition is activated on all cores and has an exclusive access to platform

resources

Symmetrical Multi-processing (SMP).

Each partition are activated on one core with true parallelism between partitions

Asymmetrical Multi-processing (AMP).

19 /19 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

Operating System global view

From Single Core to Multi-Core in AMP (Asymmetric multi-processing)

CORE

BRIDGE

Memory Controller

I/OController

BUS / NetworkInterface

Space & Time Partitionning

Operating System

CORE

INTERCONNECT

Memory Controller

I/OController


Operating System

CORE

Operating System

Space & Time Partitionning Space & Time Partitionning

APP1

T1

T2

T3

T4

APP2

T1

T2

T3

APP3

T1

T2

T3

T4

T5

Memory Controller

SolveConflict

Example of two cores processor and two memory controllers.For more than two cores (or less than two Memory Controller) conflicts to the Memory Controller have to be managed

20 /20 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

Operating System global view

From Single Core to Multi-Core in SMP (Symmetric multi-processing)

CORE

BRIDGE

Memory Controller

I/OController



Operating System

CORE

INTERCONNECT

Memory Controller

I/OController


Operating System

CORE


APP2

T1

T2

T3

APP3

T1

T2

T3

T4

T5

Memory Controller

SolveConflict

APP1

T1

T2

T3

T4

APP1

T1

T2

T3

T4

Example of two cores processor and two memory controllers.For more than two cores (or less than two Memory Controller) conflicts to the Memory Controller have to be managed

21 /21 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

Current mono-core concept

timePartition 1 Partition 2 Partition 3 Partition 4

Cor

e

OS

T1

T2

T4

T1

T3

T1

T3

T2T1

T2

T4

T1

T3

T1

T2

T4

T3

T5Appli. 1

Appli. 2

Appli. 3

idle

T

T

T

Thread / Process

CORE

BRIDGE

Memory Controller

I/OController



Operating System

APP1

T1

T2

T3

T4

APP2

T1

T2

T3

APP3

T1

T2

T3

T4

T5

T1

22 /22 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

AMP

timePartition 1.1 Partition 1.2 Partition 1.3 Partition 1.4

Cor

e 2

Cor

e 1

OS

1

T1

T2

T3

T1

T3

T1

T2T3

T1

T2

T3

T1

T3

T1

T2

T4

T1

T3

OS

2

T1

T2

T4

T1

T3

T1

T2T3

T1

T2 T2

T1

T3

T1

T2

T4T5

T3

Appli 5

Appli 6

Appli 7

idle

T

T

T

Appli.2

Appli 3

Appli 4

T

T

T

Appli. 1 T

Thread / Process

Partition 1.1 Partition 2.2 Partition 2.3 Partition 2.4

CORE

INTERCONNECT

Memory Controller

I/OController


Operating System

CORE

Operating System

Space & Time Partitionning Space & Time Partitionning

Memory Controller

APP1T1

T2T3

T4

APP2T1

T2

T3

APP3T1

T2T3

T4

T5

APP4

T1

T2

T3

APP5

T1

T2

T3

APP5T1

T2

T3

T4

23 /23 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

SMP

Appli. 1

Appli. 2

Appli. 3

idle

T

T

T

T1T1

T3

T1T3 T1

T4

T1

T3

timePartition 1 Partition 2 Partition 3 Partition 4

Cor

e 1

Cor

e 2

T2

T4

T2 T2

T1T1

T3

T2

T4

OS

Thread / Process

CORE

INTERCONNECT

Memory Controller

I/OController


Operating System

CORE


Memory Controller

APP1

T1

T2

T3

T4

APP2

T1

T2

T3

APP3

T1T2

T3

T4

T5

T5

In SMP mode, Processes, Threads or Tasks should be allocated to cores statically to achieve determinism

24 /24 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

MULTI-COREFailure Mitigation Means & COTS Relative Features

25 /25 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

Multi-Core: Failure Mitigation

FMEA and/or FFPA for a single or a multi-core processor is not achievable at processor level

Mitigation has to be provided, by the equipment provider, at board level where this processor is used

Software Error Rate SEE (Single Event Effect)

Measurements on SER are usually performed by the manufacturers on their own

Deep Sub Micronics

DSM has impact of long term reliability

26 /26 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

CONCLUSION

27 /27 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

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.

CONCLUSIONS

A COTS component remains a COTS component

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,

28 /28 /


CT

IC C

ON

FE

RE

NC

E –

MA

Y 2

013

CONCLUSIONS

Features that are the main differences between single-core and multi-core devices that have to be managed

MULCORS put emphasis on specific Multi-Core features linked to Shared Resource Accesses like Memory, Bus, Network, Internal Registers, Clock Management, etc.

Airborne Software Level Airborne Software behavior

Airborne Software applications allocation to cores can demonstrate the non-interaction between cores.

Interconnect 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

CTIC CONFERENCE – MAY 2013 Development and certification of Avionics Platforms on Multi- Core...

Documents

Transcript of CTIC CONFERENCE – MAY 2013 Development and certification of Avionics Platforms on Multi- Core...