A Framework for the Derivation of WCET Analyses for Multi-Core - - PowerPoint PPT Presentation

A Framework for the Derivation of WCET Analyses for Multi-Core Processors

Michael Jacobs

Department of Computer Science Saarland University

August 20, 2014

computer science

saarland

university

computer science

saarland

university

Multi-Core Processors

Cores share common HW resources

◮ Mostly caches and buses

Reduces:

◮ Weight ◮ Energy consumption ◮ Production costs

Thus also interesting for embedded systems Downside: Interference

◮ Cores no longer behave independently

Precise WCET analysis is challenging

◮ Exact consideration of all interference effects too costly

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 1 / 13

computer science

saarland

university

WCET Analysis for Multi-Core Processors

Existing approaches not sufficient:

◮ Compositionality assumed ◮ Cache analysis not integrated

with pipeline analysis

◮ No dynamic bus arbitration

⇒ Modern processors not supported!

Need for new WCET analyses Various HW platforms

◮ Each requires specific analysis

Hand-crafting analyses is tedious Each analysis needs soundness proof We propose a framework

◮ Derive analyses according to it ◮ Soundness as consequence of derivation

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 2 / 13

computer science

saarland

university

A Framework for the Derivation of WCET Analyses

for Multi-Core Processors

Start with sound analysis

◮ Similar to single-core analysis ◮ Pessimistic about resource sharing ◮ But simple to prove sound

Consider system properties

◮ Hold for the concrete system ◮ Bound shared resource interference

Lift the system properties

◮ To abstraction level of the existing analysis ◮ According to formal criterion

Improved analysis

◮ Based on existing analysis ◮ Incorporates lifted properties ◮ Prunes infeasible behavior

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 3 / 13

computer science

saarland

university

Outline

1

Introduction

2

Simple Approach: Pruning Based on Lifted System Properties

3

Iterative Extension: Trading in Precision for Efficiency

4

Conclusion

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 4 / 13

computer science

saarland

university

Concrete System and a WCET Analysis

Traces

Concrete-system behavior

◮ Set Traces of execution behaviors ◮ WCETCi = maxt∈Traces etCi(t)

Traces

• Traces

γtrace

Existing sound analysis for core Ci

◮ Similar to single-core analysis ◮ Pessimistic about resource sharing ◮ Result forms set

Traces of abstract traces

◮ Sound:

• ˆ

t∈ Traces γtrace(ˆ

t) ⊇ Traces

◮ WCET bound:

maxˆ

t∈ Traces UBetCi(ˆ

t) ≥ WCETCi

Traces

γtrace ˆ

t

Problem: infeasible abstract traces

◮

Infeas = {ˆ t | ˆ t ∈ Traces ∧ γtrace(ˆ t) ∩ Traces = ∅}

◮ Increase WCET bound ◮ Can safely be pruned ◮ How to detect them?

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 5 / 13

computer science

saarland

university

System Properties and Lifting Them

Set of system properties

◮ Prop = {P1, . . . , Pp} ◮ Hold for all execution behaviors:

∀Pk ∈ Prop : ∀t ∈ Traces : Pk(t)

time

la la la

. . . ≤ n − 1 times

Access request

Example: Round-Robin bus arbitration

A Round-Robin property: Prr(t) ⇔ [ #blockedCyclesCi(t) ≤ #accessesCi(t) · (n − 1) · la ] Lifted to abstract traces:

• Prr(ˆ

t) ⇔ [ LB#blockedCyclesCi(ˆ t) ≤ UB#accessesCi(ˆ t) · (n − 1) · la ] Intuition:

◮ ¬

Prr(ˆ t) ⇒ [ ∀t ∈ γtrace(ˆ t) : ¬Prr(t) ]

◮ ¬

Prr(ˆ t) ⇒ ˆ t ∈ Infeas

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 6 / 13

computer science

saarland

university

Pruning Infeasible Abstract Traces

Formal criterion for lifted properties Pk ∀ˆ

t ∈ Traces :

[ ∃t ∈ γtrace(ˆ

t) : Pk(t) ] ⇒ Pk(ˆ t) Consequence:

¬

Pk(ˆ t) ⇒ ˆ t ∈ Infeas Prune infeasible abstract traces:

• LessTraces = {ˆ

t | ˆ t ∈ Traces ∧

Pk∈Prop

Pk(ˆ t)} WCET bound still sound: maxˆ

t∈

• LessTraces

UBetCi(ˆ

t) ≥ WCETCi

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 7 / 13

computer science

saarland

university

Outline

1

Introduction

2

Simple Approach: Pruning Based on Lifted System Properties

3

Iterative Extension: Trading in Precision for Efficiency

4

Conclusion

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 8 / 13

computer science

saarland

university

Properties Arguing across Core Boundaries

Example: work conserving bus arbitration

A work conserving property: Pwc(t) ⇔ [ #blockedCyclesCi(t) ≤

• Cj∈(Cores\{Ci}) #accessCyclesCj(t) ]

Lifted to abstract traces:

• Pwc(ˆ

t) ⇔ [ LB#blockedCyclesCi(ˆ t) ≤

• Cj∈(Cores\{Ci})

UB#accessCyclesCj(ˆ

t) ] Abstract traces need to argue about all cores Introduce compound abstract traces

◮

Traces =

• TracesC1 × · · · ×

TracesCn

◮ γtrace( (

tC1, . . . , tCn) ) =

Ci∈Models γCi trace(

tCi)

Obtain

• LessTraces as before

Problem: compound set Traces likely unmanageably large

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 9 / 13

computer science

saarland

university

Overapproximating the compound set

• LessTraces

Idea: Analyze each core on its own

◮ But consider cumulative information from the analysis of other cores

Use iterative approach:

◮ Approximation variable

• ApproxCi per core Ci ∈ Cores

◮ Initialization:

• ApproxCi ←

TracesCi

◮ Update:

• ApproxCi = {

tCi | tCi ∈ TracesCi∧

• Pk∈Prop

PCi

k (

tCi, ( ApproxC1, . . . ,

• ApproxCn))}

The iterative approach. . .

◮ overapproximates projections of

• LessTraces

∀Ci ∈ Cores :

• ApproxCi ⊇ πCi(
• LessTraces)

◮ is an anytime algorithm ◮ allows any iteration strategy

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 10 / 13

computer science

saarland

university

Overapproximating the compound set

• LessTraces

Idea: Analyze each core on its own

◮ But consider cumulative information from the analysis of other cores

specially lifted for iterative approach Use iterative approach:

◮ Approximation variable

• ApproxCi per core Ci ∈ Cores

◮ Initialization:

• ApproxCi ←

TracesCi

◮ Update:

• ApproxCi = {

tCi | tCi ∈ TracesCi∧

• Pk∈Prop

PCi

k (

tCi, ( ApproxC1, . . . ,

• ApproxCn))}

The iterative approach. . .

◮ overapproximates projections of

• LessTraces

∀Ci ∈ Cores :

• ApproxCi ⊇ πCi(
• LessTraces)

◮ is an anytime algorithm ◮ allows any iteration strategy

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 10 / 13

computer science

saarland

university

Lifting Properties for the Iterative Approach

Further lift properties Pk to PCi

k per core Ci ∈ Cores

According to formal criteria:

◮ Soundness criterion ◮ Monotonicity criterion

Example: further lifted versions of Pwc

• PCi

wc(

tCi, ( ApproxC1, . . . ,

• ApproxCn))

⇔ [ LB#blockedCyclesCi

Ci(

tCi) ≤

• Cj∈(Cores\{Ci}) max

tCj ∈ ApproxCj UB#accessCycles Cj Cj(

tCj) ]

∀Cj = Ci :

P

Cj wc(

tCj, ( ApproxC1, . . . ,

• ApproxCn)) ⇔ 1

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 11 / 13

computer science

saarland

university

Lifting Properties for the Iterative Approach

Further lift properties Pk to PCi

k per core Ci ∈ Cores

According to formal criteria:

◮ Soundness criterion ◮ Monotonicity criterion

Example: further lifted versions of Pwc

Non-compound abstract trace (Core Ci)

• PCi

wc(

tCi, ( ApproxC1, . . . ,

• ApproxCn))

⇔ [ LB#blockedCyclesCi

Ci(

tCi) ≤

• Cj∈(Cores\{Ci}) max

tCj ∈ ApproxCj UB#accessCycles Cj Cj(

tCj) ]

∀Cj = Ci :

P

Cj wc(

tCj, ( ApproxC1, . . . ,

• ApproxCn)) ⇔ 1

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 11 / 13

computer science

saarland

university

Lifting Properties for the Iterative Approach

Further lift properties Pk to PCi

k per core Ci ∈ Cores

According to formal criteria:

◮ Soundness criterion ◮ Monotonicity criterion

Example: further lifted versions of Pwc

Abstract traces of the other cores

• PCi

wc(

tCi, ( ApproxC1, . . . ,

• ApproxCn))

⇔ [ LB#blockedCyclesCi

Ci(

tCi) ≤

• Cj∈(Cores\{Ci}) max

tCj ∈ ApproxCj UB#accessCycles Cj Cj(

tCj) ]

∀Cj = Ci :

P

Cj wc(

tCj, ( ApproxC1, . . . ,

• ApproxCn)) ⇔ 1

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 11 / 13

computer science

saarland

university

Lifting Properties for the Iterative Approach

Further lift properties Pk to PCi

k per core Ci ∈ Cores

According to formal criteria:

◮ Soundness criterion ◮ Monotonicity criterion

Example: further lifted versions of Pwc

• PCi

wc(

tCi, ( ApproxC1, . . . ,

• ApproxCn))

⇔ [ LB#blockedCyclesCi

Ci(

tCi) ≤

• Cj∈(Cores\{Ci}) max

tCj ∈ ApproxCj UB#accessCycles Cj Cj(

tCj) ]

∀Cj = Ci :

P

Cj wc(

tCj, ( ApproxC1, . . . ,

• ApproxCn)) ⇔ 1

Cumulative information

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 11 / 13

computer science

saarland

university

Outline

1

Introduction

2

Simple Approach: Pruning Based on Lifted System Properties

3

Iterative Extension: Trading in Precision for Efficiency

4

Conclusion

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 12 / 13

computer science

saarland

university

Advantages of Using our Framework

A framework for the derivation of WCET analyses for multi-core processors Advantages:

◮ Standard derivation procedure ⋆ Does not inherently rely on the restricting assumptions of previous

approaches

◮ Soundness guarantee ◮ Trade-off between efficiency and precision ◮ Modular design of WCET analyses ◮ Assumptions about the system always explicit

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 13 / 13

computer science

saarland

university

How Does our Framework Compare to Existing Analyses?

Not at all!

◮ It is no analysis, but a framework to derive analyses.

How do derived analyses compare to existing analyses?

◮ It depends! ◮ Many parameters influence precision and performance: ⋆ Baseline analysis ⋆ Considered system properties ⋆ Iterative or non-iterative approach ⋆ Lifting decisions ⋆ Implementation details ◮ Existing analyses can likely also be derived ⋆ Although we did not try to so far

Many aspects still very abstract

◮ E.g. of which form Traces and

Traces are

◮ Just concrete enough to show: ⋆ the technical soundness of derived analyses ⋆ the high-level use of our framework, not of a particular derived analysis

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 14 / 13

computer science

saarland

university

Future Work

Framework so far only conceptual Step towards actual analysis implementations

◮ Execution behaviors are sequences of HW states ⋆ as obtained by cycle-wise transition ◮ Abstract traces are sequences of abstract states ⋆ abstract states as in abstract-interpretation-based WCET analysis ◮ Further lift properties from abstract traces to abstract states ⋆ In a way that: if a property holds for an abstract trace, its abstract state

version holds for all abstract states in the trace

◮ Goal: prune abstract states for which a property does not hold

Incorporate arrival curves

◮ To express cumulative information in the iterative approach

Experiment with different concrete system properties

◮ E.g. arguing about: ⋆ shared caches ⋆ cache coherence

Michael Jacobs WCET Analyses for Multi-Core Processors August 20, 2014 15 / 13