Modular SystemLevel Performance Analysis

1
Modular System-Level Performance Analysis
Bode-RC Meeting, 19. February 2004
Marcel Verhoef marcel.verhoef_at_cs.kun.nl Embedded
Systems Institute TU Eindhoven, Netherlands
Ernesto Wandeler wandeler_at_tik.ee.ethz.ch Computer
Engineering and Networks Laboratory ETH Zurich,
Switzerland
2
Overview

• Problem Statement
• Modular Performance Analysis
• Case Study I Car Navigation System
• Case Study II Automated Design Space Exploration
  of a Network Processor
• Conclusions

3
Design Space for Embedded Systems
Which architecture is better suited for our
application?
RISC
LookUp
EDF
mE
mE
mE
TDMA
static
Priority
mE
mE
mE
WFQ
DSP
Cipher
4
Why Performance Estimation?
This process takes place on several levels of
abstraction.
5
Problems in Performance Estimation

• Distributed processing of applications on
  different resources
• Interaction of different applications on
  different resources

RISC
LookUp
DSP
Cipher
6
Related Work

• Most use simulation techniques and benchmark
  workloads, e.g. Crowley et al. 2000, Franklin,
  Wolf 2000-2002
• More restricted approaches, e.g.
• exploration of on-chip communication Lahiri et
  al. 2001
• OS issues Peterson et al. 1999-2001
• models of computation Kohler et al. 2000

• In this talk
• analytical method based on Real-Time
  CalculusThiele et al. 2000

7
Overview

• Problem Statement
• Modular Performance Analysis
• Case Study I Car Navigation System
• Case Study II Automated Design Space Exploration
  of a Network Processor
• Conclusions

8
A Three-Step Approach to Modular Performance
Analysis

• Build abstract models for first class citizens
  (event streams, resource units, functional units,
  run-time environment, mapping and scenarios)
• Build components
• Compose components to a system andanalyze

9
Step 1 The Big Picture and Mapping
Functional Task Model
T1
T2
T3
loadscenarios
Abstract Task Model
mapping relations
Abstract Components (Run-Time Environment)
abstract resource units
Abstract Architecture
resource units
Architecture Model
ARM9
DSP
10
Step 1 Event and Resource Models
How do we describe uncertain event streams and
resources?
11
Step 1 Abstract Event Streams

• We use the concept of arrival curves!

12
Step 1 Abstract Resource Units

• We use the concept of service curves!

maximum/minimum computing power in any interval
of length 2
computing power in time interval 0,2
13
Step 1 Abstract Functional Units

• From a functional model

14
Step 1 Abstract Functional Units
How do we calculate with abstract event streams
and resources units?

• to an abstract load model.

We use Real-Time Calculus! (min-max algebra)
15
Step 1 Abstract Functional Units
16
Step 2 Build Abstract Components
How do we do scheduling?
17
Step 2 Scheduling I
Fixed Priority (FP)
18
Step 2 Scheduling II
share
Generalized Processor Sharing (GPS)
S
19
Step 3 Compose and Analyze
How can we estimate the load on resources?
How can we estimate delay and memory?
How can we compose abstract components?
How can we add a new application?
ARM9
DSP2
Bus
DSP1
20
Step 3 Compose and Analyze
bu,l
au,l
b
21
Everything Together
22
Overview

• Problem Statement
• Modular Performance Analysis
• Case Study I Car Navigation System
• Case Study II Automated Design Space Exploration
  of a Network Processor
• Conclusions

23
Case Study Car Navigation System

• Car radio with integrated navigation system
• Several tasks may execute concurrently in a multi
  processor architecture
• User interface needs to be responsive
• Traffic messages (TMC) need to be processed in a
  timely way, especially important for traffic
  warnings

24
User Interface
25
System Architecture
MMI
NAV
RAD
DB
26
Task 1 Change Audio Volume
27
Task 2 Lookup Destination Address
28
Task 3 Receive TMC Messages
29
Architecture Alternatives

• Bus connection
• Point-2-point connections
• Radio / Navigation on one CPU
• Radio / MMI on one CPU
• All tasks on one CPU

30
Architecture Alternatives
22 MIPS
22 MIPS
72 kbps
57 kbps
MMI
MMI
11 MIPS
113 MIPS
11 MIPS
113 MIPS
NAV
RAD
NAV
RAD
72 kbps
72 kbps
72 kbps
260 MIPS
22 MIPS
130 MIPS
113 MIPS
260 MIPS
RAD
MMI
RAD
NAV
MMI
NAV
MMI
RAD
NAV
31
Step 1 Abstract Task Model and Mapping
Hndl
Dec
Disp
Receive TMC Application
Abstract Task Model
Mapping
Abstract Resource Model
MMI
Bus Architecture
NAV
RAD
32
Step 1 Abstract Loads and Resources

• Abstract Event Stream Model
• Address Lookup
• (1 event / sec)
• Abstract Resource Model
• RISC CPU
• (113 MIPS)

au
events
al
1
s
1
MIPS
bl,bu
113
s
1
33
Step 2 Building Components

• We use pre-emptive fixed priority scheduling for
  all components and applications
• Highest Priority Change Volume
• Medium Priority Address Lookup
• Lowest Priority Receive TMC

34
Step 3 Scheduling Network
MMI
NAV
RAD
35
Step 3 Analysis End-to-End Delay
36
Step 3 Analysis End-to-End Delay
22 MIPS
22 MIPS
72 kbps
57 kbps
MMI
MMI
11 MIPS
113 MIPS
11 MIPS
113 MIPS
NAV
RAD
NAV
RAD
72 kbps
72 kbps
72 kbps
260 MIPS
22 MIPS
130 MIPS
113 MIPS
260 MIPS
RAD
MMI
RAD
NAV
MMI
NAV
MMI
RAD
NAV
37
Step 3 Analysis Sensitivity Analysis
NAV
MMI
What do we do? In the Bus-Architecture, we
separately increase the performance of each
resource unit and observe the effect to the
Receive TMC delay.
The MMI-Processor seems to be the bottleneck!
Some further analysis revealed, that by
increasing the MMI-Processor speed by only 7, we
can guarantee to meet all delay requirements in
the Bus-Architecture.
RAD
BUS
x-Axis performance of the respective resource
unit, stepwise from 100 - 200 y-Axis Receive
TMC delay
38
Overview

• Problem Statement
• Modular Performance Analysis
• Case Study Car Navigation System
• Case Study II Automated Design Space Exploration
  of a Network Processor
• Conclusions

39
Automated Design Space Exploration
Estimation
We use evolutionary algorithms for
multi-objective optimization!
40
Involved Tools
MOSES
All tools are available online www.tik.ee.ethz.ch
/moses www.tik.ee.ethz.ch/expo/expo.html www.tik.
ee.ethz.ch/genetic
EXPO
SPEA 2
Exploration Cycle
41
Network Processor Task Model
42
EXPO
43
Results
Cost
Performance for encryption/decryption
Performance for RT voice processing
44
Analysis vs. Simulation
load
45
Overview

• Problem Statement
• Modular Performance Analysis
• Case Study Car Navigation System
• Case Study II Automated Design Space Exploration
  of a Network Processor
• Conclusions

46
Conclusions
47
Involved People

• At ESI Eindhoven
• Jozef Hooman
• Marcel Verhoef
• At ETH Zurich
• Samarjit Chakraborty (now at NUS)
• Simon Künzli
• Alexander Maxiaguine
• Lothar Thiele
• Ernesto Wandeler

48
Thank you!