multicore architecture for critical real-time embedded systems multicores in crtes: critical...

1
Multicore Architecture for Critical Real-Time Embedded Systems Multicores in CRTEs: Critical Real-Time Embedded Systems (CRTESs) are in everyday life • CRTESs require time correctness Tasks must finish before their deadline In safety-critical real-time embedded systems missing a deadline can have catastrophic consequences! CRTESs require higher performance than what provided by current embedded processors Advantages Disadvantages High performance Increases safety, comfort, and the number and quality of services • Represent a good solution Better performance per watt ratio than single core Simple core design which prevents time anomalies • It is harder to perform WCET analysis for CMPs than for single- core because of Inter-task Interferences Inter-task interferences accessing shared resources make the execution time vary • Execution time, and so the WCET of a Hard Real Time (HRT) task depends on the workload • Hard real-time systems (e.g. automoti-ve) are composed by tasks developed by different sub- suppliers In a CMP, changing a task requires to re-analyze the whole system again • It is essential that dependencies between the different sub-systems are minimized Results with a real case study : Honeywell collision avoidance application This work has been supported by the Ministry of Science and Technology of Spain under contract TIN-2007-60625, by the HiPEAC European Network of Excellence and by the MERASA STREP-FP7 European Project under the grant agreement number 216415. Marco Paolieri is supported by the Catalan Ministry for Innovation, Universities and Enterprise of the Catalan Government and European Social Funds. Eduardo Quiñones is supported by Juan de la Cierva postdoctoral contract from the Ministry of Education and Science (MEC), Spain. Our real-time analyzable CMP architecture Guarantees by design that the maximum delay a request accessing a hardware shared resource may suffer due to inter- task interferences has an Upper Bound Delay (UBD) • On top of it, we introduce an execution mode (i.e. WCET Computation Mode) that allows computing a WCET estimation of HRT artificially delaying every request to a shared resource by UBD. •The processor also implements a normal execution mode where no additional delay is introduced. • The WCET Computation Mode has been applied to 2 shared resources: On-chip shared bus DDRx SDRAM Memory Controller Cache partitioning is used to prevent L2 interferences among different HRT tasks: bankization • Our real-time analyzable CMP HON application running with 1 HRT task DDRx SDRAM Memory Systems: a Worst-Case Execution Time Perspective Memory System: The resource with the highest effect on WCET is the memory controller The time it takes a memory request to be processed depends on the history of requests • We defined an analytical model to compute the upper bound delay (UBD) that a mem. request can suffer due to inter task memory interferences coming from other co- running tasks. Based on the generic timing constraints of DRAM memory devices and it allows selecting the device that leads to the lowest WCET estimation We present a Generic Analyzable Memory Controller (GAMC) for hard real-time CMPs : Provides a predictable memory access time Allows the computation of tight WCET estimations Based on our analytical model Implements extra hardware support to further reduce UBD Deals with refresh operations such that their effect is safely taken into account in the WCET analysis Marco Paolieri, Eduardo Quiñones, Francisco J. Cazorla, Mateo Valero {marco.paolieri, eduardo.quinones, francisco.cazorla, mateo.valero}@bsc.es PR_MC: CMP with a private memory controller per core MOET: Maximum Observed Execution Time Baseline: WCET for the HRT task when it runs in - isolation (full cache), - private mem. controller - without inter-task interferences - The effect of the memory controller is high -Tight estima- tions in average: 20% higher than MOET for HON using DDR2-800C We have proposed a CMP architecture that is time analyzable and provides high performance HON application running with 3 HRT tasks 1.0 1.2 1.4 1.6 1.8 2.0 128KB 64KB 32KB 16KB 8KB cache size assinged to HO N app. N orm alized W CET PR_M C M OET GAM C 1.0 1.2 1.4 1.6 1.8 2.0 128KB 64KB 32KB 16KB 8KB cache size assinged to HO N app. N orm alized W CET PR_M C M OET GAM C

Upload: eliezer-langdale

Post on 14-Dec-2015

222 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Multicore Architecture for Critical Real-Time Embedded Systems Multicores in CRTEs: Critical Real-Time Embedded Systems (CRTESs) are in everyday life CRTESs

Multicore Architecture for Critical Real-Time Embedded Systems

Multicores in CRTEs:• Critical Real-Time Embedded Systems (CRTESs) are in everyday life

• CRTESs require time correctness•Tasks must finish before their deadline• In safety-critical real-time embedded systems missing a deadline can have catastrophic consequences!

• CRTESs require higher performance than what provided by current embedded processors

Advantages Disadvantages• High performance• Increases safety, comfort, and the number and quality of services

• Represent a good solution• Better performance per • watt ratio than single core • Simple core design which prevents time anomalies

• It is harder to perform WCET analysis for CMPs than for single-core because of Inter-task Interferences• Inter-task interferences accessing shared resources make the execution time vary• Execution time, and so the WCET of a Hard Real Time (HRT) task depends on the workload

• Hard real-time systems (e.g. automoti-ve) are composed by tasks developed by different sub-suppliers• In a CMP, changing a task requires to re-analyze the whole system again• It is essential that dependencies between the different sub-systems are minimized

Results with a real case study: Honeywell collision avoidance application

This work has been supported by the Ministry of Science and Technology of Spain under contract TIN-2007-60625, by the HiPEAC European Network of Excellence and by the MERASA STREP-FP7 European Project under the grant agreement number 216415. Marco Paolieri is supported by the Catalan Ministry for Innovation, Universities and Enterprise of the Catalan Government and European Social Funds. Eduardo Quiñones is supported by Juan de la Cierva postdoctoral contract from the Ministry of Education and Science (MEC), Spain.

Our real-time analyzable CMP architecture

• Guarantees by design that the maximum delay a request accessing a hardware shared resource may suffer due to inter- task interferences has an Upper Bound Delay (UBD)

• On top of it, we introduce an execution mode (i.e. WCET Computation Mode) that allows computing a WCET estimation of HRT artificially delaying every request to a shared resource by UBD.

•The processor also implements a normal execution mode where no additional delay is introduced.

• The WCET Computation Mode has been applied to 2 shared resources:• On-chip shared bus • DDRx SDRAM Memory Controller

• Cache partitioning is used to prevent L2 interferences among different HRT tasks: bankization

• Our real-time analyzable CMP

HON application running with 1 HRT task

DDRx SDRAM Memory Systems: a Worst-Case Execution Time Perspective

• Memory System: • The resource with the highest effect on WCET is the memory controller

• The time it takes a memory request to be processed depends on the history of requests

• We defined an analytical model to compute the upper bound delay (UBD) that a mem. request can suffer due to inter task memory interferences coming from other co-running tasks.

• Based on the generic timing constraints of DRAM memory devices and it allows selecting the device that leads to the lowest WCET estimation

• We present a Generic Analyzable Memory Controller (GAMC) for hard real-time CMPs :• Provides a predictable memory access time• Allows the computation of tight WCET estimations• Based on our analytical model• Implements extra hardware support to further reduce UBD• Deals with refresh operations such that their effect is safely taken into account in the WCET analysis

Marco Paolieri, Eduardo Quiñones, Francisco J. Cazorla, Mateo Valero{marco.paolieri, eduardo.quinones, francisco.cazorla, mateo.valero}@bsc.es

PR_MC: CMP with a private memory controller per coreMOET: Maximum Observed Execution TimeBaseline: WCET for the HRT task when it runs in - isolation (full cache), - private mem. controller - without inter-task interferences

- The effect of the memory controller is high

-Tight estima-tions in average: 20% higher than MOET for HON using DDR2-800C

We have proposed a CMP architecture that is time analyzable and provides high performance

HON application running with 3 HRT tasks

1.01.21.41.61.82.0

128KB 64KB 32KB 16KB 8KB

cache size assinged to HON app.

Nor

mal

ized

WCE

T

PR_MC MOET GAMC

1.01.21.41.61.82.0

128KB 64KB 32KB 16KB 8KB

cache size assinged to HON app.

Nor

mal

ized

WCE

T

PR_MC MOET GAMC