system level design space exploration for mpsoc: methods, algorithms and new infrastructure
DESCRIPTION
Universidad de Las Palmas de Gran Canaria Programa de doctorado Sistemas Inteligentes y Aplicaciones Numéricas en Ingeniería. System Level Design Space Exploration for MPSoC: Methods, Algorithms and New Infrastructure. European Doctorate Institute for Applied Microelectronics (IUMA). - PowerPoint PPT PresentationTRANSCRIPT
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
System Level Design Space Exploration for MPSoC: Methods, Algorithms and New Infrastructure
PhD student: Zai Jian Jia Li
Supervisors: Prof. Antonio NúñezAssist. prof. Tomás Bautista
Universidad de Las Palmas de Gran CanariaPrograma de doctorado Sistemas Inteligentes y
Aplicaciones Numéricas en Ingeniería
Las Palmas de Gran Canaria, January 25, 2011
European Doctorate Institute for Applied Microelectronics (IUMA)
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
2
OUTLINE
• Introduction and context
• Motivation, challenges and goals
• Approaches and contributions
• Results
• Conclusions and future work
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
3
• Systems-on-Chip design challenges
– The continuous technology progress is leading to a major capacity of integration on chip.
– System composted of a big number and variety of components: processing elements (PEs), network elements (NEs), storages elements (SEs); I/O devices…
– As a result, this Increasing level of integration is leading to more complex embedded Systems-on-Chip (SoC).
– This issue also represents several challenges for the system designers.
INTRODUCTION
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
4
• Challenges (I)
Heterogeneous architectural components: SoC composed of multiple and different types of PEs, SEs, NEs… Example: Multiprocessor System-on-Chip (MPSoC).
=> Flexible and reusable platform for a family of product and easily modified for the market needs.
Exploration of a large number of design decisions: designers have to make decisions about a large amount of design decisions or design options. Example: number and types, mapping, architectural topology, HW/SW partition, allocation of the components in the architecture…
=> The more flexible and complex the platform is, the larger number of design options should be taken into account.
INTRODUCTION
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
5
• Challenges (II)
Multiple design constraints: in addition to the huge number of design decisions that should be explored, designers also have to take into account many design objectives. Example: performance, cost/area, power consumptions…
=> Optimal solution inside the design space that satisfy the design constraints: efficiency and without over-dimensioning.
New techniques and generic framework: to assist to designers in the exploration and design process. We would need flexible and reusable approaches, without resorting to ad-hoc strategies designed for particular cases.
=> Strategies to carry out the design process in a time efficient way, as well as to reduce significantly the effort of designers.
INTRODUCTION
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
6
INTRODUCTION
• System level design (SLD)
– SLD has been proposed as a complement to the traditional design methods at Register Transfer Level (RTL), as well as to improve the productivity of system designers.
– Essential difference between SLD and RTL: SLD works at a higher abstraction level => elements with a higher granularity level and less implementation details.
– Working at a higher abstraction level implies to trade off certain accuracy with respect to RTL design.
– System level design indeed presents important benefits to the system designers.
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
7
INTRODUCTION
• Some benefits of System level design
Simplify significantly the design effort: new design or modification of a previous design can be obtained in an easier way than if using a lower abstraction level.
Speed up the simulation time: as consequence of working with less implementation details, system level simulations can run 2 and 3 orders of magnitude faster than RTL simulations => rapid exploration of large number of design points or design solutions.
Making decisions at an earlier stage of design process: allow designers to have a clear overview and the impacts of different design decisions on system behaviours => without building or developing a full-detailed system design.
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
8
OUTLINE
Introduction and context
• Motivation, challenges and goals
• Approaches and contributions
• Results
• Conclusions and future work
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
9
MOTIVATION AND GOALS
Context of this work: Design Space Exploration at System Level.
Design space
Design space dimension 1
Design space dimension 2
Design space dimension 3
Design point A
Design point B
Design point C
Design point DDesign point E
Dd1 A
Dd3 ADesign point A
Dd2 A
Dd1 B
Dd2 B
Dd3 B
Design point B
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
10
Context of this work: Design Space Exploration at System Level.
Design space
Design space dimension 1
Design space dimension 2
Design space dimension 3
Dd1 A
Dd3 ADesign point A
Dd2 A
Dd1 B
Dd2 B
Dd3 B
Design point B
Design objective 1
Design objective 2
Design point A
Design point B
Design point C
Design point DDesign point E
Design objective 3Design point A
Design point B
Design point C
Design point DDesign point E
Solution(s) or candidate solution(s)
MOTIVATION AND GOALS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
11
• Design Space Exploration (DSE) for MPSoC at System level
System-level DSE for MPSoC often can be seen as a multiobjective optimization design problem.
The more design options, the larger the resulting design space is => and the more effort and time is needed to carry out the DSE.
• Components of the DSE process
Search methods, evaluation techniques and generator of system design description.
MOTIVATION AND GOALS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
12
Search method
Design space
• The search method is used to travel systematically through the design space.
• Goal: identify and select design points (from the design space) that are analyzed further by the evaluation techniques.
• Different strategies: exhaustive search, random sampling, incorporating knowledge of design space (e.g., genetic algorithms), heuristic-based algorithms…
Components of system-level DSE process
MOTIVATION AND GOALS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
13
Search method
Design space
Evaluation technique
Performace, power, cost…
System metrics
• Evaluation technique assess the quality of each design point selected by the search method.
• The quality of solutions is measured in terms of different system metrics: packets/data processed per second, system traffic, number of each type of components actually used in the architecture…
•System-level simulation and analytical methods (formal rules, mathematical formulations…)
Components of system-level DSE process
• The search method is used to travel systematically through the design space.
• Goal: identify and select design points (from the design space) that are analyzed further by the evaluation techniques.
• Different strategies: exhaustive search, random sampling, incorporating knowledge of design space (e.g., genetic algorithms), heuristic-based algorithms…
MOTIVATION AND GOALS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
14
Generator of system description
Application model
Architecture model
Mapping model System
model Design points descriptions
Evaluation technique
Performace, power, cost…
Search method
Design space
System metrics
Components of system-level DSE process• Evaluation technique assess the quality of each design point selected by the search method.
• The quality of solutions is measured in terms of different system metrics: packets/data processed per second, system traffic, number of each type of components actually used in the architecture…
•System-level simulation and analytical methods (formal rules, mathematical formulations…)
MOTIVATION AND GOALS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
15
Evaluation technique
Performace, power, cost…
Search method
Design space
Generator of system description
Application model
Architecture model
Mapping model System
model Design points descriptions
System metrics
Components of system-level DSE process
• In the practice, many efforts are based on ad-hoc approaches: create manually, or use customized control scripts…
• Rewrite these control scripts for different DSE => labour intensive, error-prone, bottlenecks of productivity…
MOTIVATION AND GOALS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
16
Evaluation technique
Performace, power, cost…
Search method
Design space
Generator of system description
Application model
Architecture model
Mapping model System
model Design points descriptions
System metrics
DSE infrastructureUser
specifications
Components of system-level DSE process
• In the practice, many efforts are based on ad-hoc approaches: create manually, or use customized control scripts…
• Rewrite these control scripts for different DSE => labour intensive, error-prone, bottlenecks of productivity…
MOTIVATION AND GOALS
AU
TOMATI
C
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
17
• Goals
An approach to handle the increasing level of design options.
Strategies and algorithms to solve the multiobjective optimization design problem in a time and effort efficient way.
A framework that allows for incorporating different combinations of search strategies and evaluation techniques in an automatic and fast way.
A single and generic infrastructure for system-level DSE experiments, which provides a flexible and reusable environment to systematically explore the design space without resorting to ad-hoc efforts.
MOTIVATION AND GOALS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
18
OUTLINE
Introduction and context
Motivation, challenges and goals
• Approaches and contributions
• Results
• Conclusions and future work
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
19
Platform dimension
Arch. component dimension
Mapping dimension
……
Design options or design decisions
• “Dimension-oriented DSE approach”
– A novel concept and methodology for system-level MPSoC DSE.
– A large design space defined by a huge number of design options can be explicitly separated and hierarchically organized into dimensions or exploration levels.
APPROACHES AND CONTRIBUTIONS
Topology of the platform
Number and type of componentsTasks migrationHW/SW partitionResources allocation and organizationTasks clustering
Storage capacityDifferent clock domainsScheduling policy
Topology of the platform
Number and type of componentsTasks migrationHW/SW partitionResources allocation and organizationTasks clustering
Storage capacityDifferent clock domainsScheduling policy
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
20
• Dimension-oriented DSE approach: benefits
Extensibility: remove and add new exploration levels with additional design options.
Flexibility: explore simultaneously all dimensions of the design space or to fix one or more of these dimensions (e.g., a fixed architecture) and focus the exploration within other dimensions.
Use a single search methods for exploring the whole design space, or use a separate and different search method to co-explore the design space => not perform the DSE as multiple independent explorations, but the results from all dimensions are simultaneously taken into account.
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
21
• Dimension-oriented DSE approach
If no information is exchanged between different search methods in the co-exploration process, we can have an under-exploration problem and/or even worse, we cannot ensure the convergence.
},,{ Amap
Aarc
Apla dddA
},,{ Bmap
Barc
Bpla dddB
Result after a single evaluation: A is better than B
=¿
¿
Aplad
Aarcd
Bplad
Barcd
is better than
is better than
?
?
or
Solution: Establish explicit relationships between different search methods used in the co-exploration process. There are many ways, e.g., by means of hierarchical fitness functions => the search methods that work at higher abstraction dimensions require more information for a better overview of the design space.
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
22
• “NASA framework”
– NASA (Non Ad-hoc Search Algorithm) is a modular infrastructure for system-level MPSoC DSE experiments.
– A software environment that allows designers to deploy our dimension-oriented approach, as well as to integrate a generator of system design description.
– A single and generic framework that allows for integrating different combinations of search methods and evaluation techniques in a plug & play fashion.
– A flexible and reusable infrastructure to carry out system-level multidimensional DSE experiments in a fast and automatic way.
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
23
• NASA framework
Application specifications
Components specifications
Architecture constraints
Modules configuration
User specifications
Evaluator
Fitness function
Platform
Architectural Components
MappingMetrics reader
Fitness files
Simulator System model
Translator
Mapping model
Architecture model
Application model
Feasibility Checker
Connectivity
Components
Design-options files (checked)
Tasks and channels
Design-options files
Search
Platform
Architectural components
Mapping Architectural intermediate
file
Arch. Platform Generator
Platform instance
Architecture instance
Design-options files (checked)
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
24
Application specifications
Components specifications
Architecture constraints
Modules configuration
User specifications//Type PE
PE1=ARMPE2=MIPSPE3=PPC
//Type SESE1=SDRSE2=DDR
//Type NENE1=BUSNE2=XBANE3=P2P
Num. NE=3Num. SE=2Num. PE=3
……
#define NUMBER_SEARCH 3#define TYPE_SEARCH_1 “GA”#define SOURCE_SEARCH_1 “../search/GA/”…#define MAX_NUMBER_PE 3#define MAX_NUMBER_SE 2#define MAX_NUMBER_NE 3…#define TYPE_PE_1 “ARM”#define PARAMETER_FILE_PE1 “../library/PE/arm.txt”…#define TYPE_SE_1 “SDR”#define PARAMETER_FILE_SE1 “../library/SE/sdr.txt”…#define NUMBER_TASKS 7#define NUMBER_CHANNLES 12#define TASK1 “RGB2YCrCb”#define TASK1_SOURCE “../app/rgb2ycrcb/”…
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
25
Application specifications
Components specifications
Architecture constraints
Modules configuration
User specifications//Type PE
PE1=ARMPE2=MIPSPE3=PPC
//Type SESE1=SDRSE2=DDR
//Type NENE1=BUSNE2=XBANE3=P2P
Num. NE=3Num. SE=2Num. PE=3
……
BTU 11 2 3 4 5
BTU 21 2 3 4 5
BTU 31 2 3 4 5
BTU 51 2 3 4 5
BTU 61 2 3 4 5
Meta-platform
Network 1
Network 2
BTU 41 2 3 4 5
Network 4
Network 3
Network 5 Network 6
1
2 3
4
56
7
Element container
Basic Topology Unit is a logical pattern composed of a number of the element containers and a network container
1 2 3 4 5Network container
BTU
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
26
Application specifications
Components specifications
Architecture constraints
Modules configuration
User specifications//Type PE
PE1=ARMPE2=MIPSPE3=PPC
//Type SESE1=SDRSE2=DDR
//Type NENE1=BUSNE2=XBANE3=P2P
Num. NE=3Num. SE=2Num. PE=3
……
BTU 11 2 3 4 5
BTU 21 2 3 4 5
BTU 31 2 3 4 5
BTU 51 2 3 4 5
BTU 61 2 3 4 5
Meta-platform
Network 1
Network 2
BTU 41 2 3 4 5
Network 4
Network 3
Network 5 Network 6
1
2 3
4
56
7
Element container
Basic Topology Unit is a logical pattern composed of a number of the element containers and a network container
1 2 3 4 5Network container
BTU
Search
Platform
Architectural components
Mapping
Evaluator
Fitness function
Platform
Architectural Components
MappingMetrics reader
Fitness files
Simulator System model
Translator
Mapping model
Architecture model
Application model
Feasibility Checker
Connectivity
Components
Design-options files (checked)
Tasks and channels
Design-options files
Architectural intermediate
file
Arch. Platform Generator
Platform instance
Architecture instance
Design-options files (checked)
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
27
Search
Platform
Architectural components
Mapping
1 Search Algorithm (SA)
Adaptor in
SAAdaptor
out
Search
SA
SA
SA
Platform
Architectural components
Mapping
Dimension-oriented DSE approach:
1) Multiple Search Algorithms
2) Different (tailored) search algorithm per dimension
3) Fixe one dimension
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
28
Search
Platform
Architectural components
Mapping
Design-options file
……darc1
darckProcessors Memories
Architectural components string……
……Channels
Mapping string……
Tasks
……
dpla1
dplakNetworks Architectural elements
sub-string
Platform string……
dmap1
dmapk
… …dpla1 dplaj dplak
… …darc1 darcj darck
… …dmap1 dmapj dmapkDesign point (dpk)
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
29
Feasibility Checker
Connectivity
Components
Tasks and channels
Search
Platform
Architectural components
Mapping
Application specifications
Components specifications
Architecture constraints
Modules configuration
User specifications
Evaluator
Fitness function
Platform
Architectural Components
MappingMetrics reader
Fitness files
Simulator System model
Translator
Mapping model
Architecture model
Application model
Design-options files (checked)
Design-options files
Architectural intermediate
file
Arch. Platform Generator
Platform instance
Architecture instance
Design-options files (checked)
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
30
Feasibility Checker
Connectivity
Components
Tasks and channels
…
…
NE1 NE2 NE3 NE4 NE5 NE6
1 0 0 2 0 0
Infeasible platform string
Users specification
NE1 = Bus
NE2 = XBA
BTU 11 2 3 4 5
BTU 2 BTU 3
BTU 41 2 3 4 5
BTU 5 BTU 6
Infeasible platform (isolate BTU)
bus
xba
Feasible platformBTU 1
1 2 3 4 5
BTU 3
BTU 4 BTU 5 BTU 6
bus
BTU 21 2 3 4 5
xba
…
…
NE1 NE2 NE3 NE4 NE5 NE6
1 2 0 0 0 0
Feasible platform string
Checked design-options file
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
31
Feasibility Checker
Connectivity
Components
Tasks and channels
…
…
NE1 NE2 NE3 NE4 NE5 NE6
1 0 0 2 0 0
Infeasible platform string
Users specification
NE1 = Bus
NE2 = XBA
BTU 11 2 3 4 5
BTU 2 BTU 3
BTU 41 2 3 4 5
BTU 5 BTU 6
Infeasible platform (isolate BTU)
bus
xba
Feasible platformBTU 1
1 2 3 4 5
BTU 3
BTU 4 BTU 5 BTU 6
bus
BTU 21 2 3 4 5
xba
…
…
NE1 NE2 NE3 NE4 NE5 NE6
1 2 0 0 0 0
Feasible platform string
Checked design-options file
Application specifications
Components specifications
Architecture constraints
Modules configuration
User specifications
Search
Platform
Architectural components
Mapping
Evaluator
Fitness function
Platform
Architectural Components
MappingMetrics reader
Fitness files
Simulator System model
Translator
Mapping model
Architecture model
Application model
Design-options files (checked)
Design-options files
Architectural intermediate
file
Arch. Platform Generator
Platform instance
Architecture instance
Design-options files (checked)
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
32
• Translator module converts NASA’s internal format of a design point to the specific format required by each evaluation technique.
• For example, integration of a new simulator in NASA only requires the adaptation of the Translator module.
YML-basad architecture model
Command lines based architecture model
Architectural intermediate file
Sesame Translator
CASSE Translator
Translator module
APPROACHES AND CONTRIBUTIONS
Different system-level simulators
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
33
Feasibility Checker
Connectivity
Components
Tasks and channels
Search
Platform
Architectural components
Mapping
Application specifications
Components specifications
Architecture constraints
Modules configuration
User specifications
Evaluator
Fitness function
Platform
Architectural Components
MappingMetrics reader
Fitness files
Simulator System model
Translator
Mapping model
Architecture model
Application model
Design-options files (checked)
Design-options files
Architectural intermediate
file
Arch. Platform Generator
Platform instance
Architecture instance
Design-options files (checked)
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
34
• “Heuristic-based mapping algorithms”
– DSE experiments: using a single genetic algorithm vs multiple genetic algorithms.
– Hierarchical DSE strategy with heuristic-based mapping algorithms => Fixed platform, variable architectural components and mappings.
– Objective: multi-objective optimization mapping problem => optimal configuration of a target platform for the mapping of a real-time application, while achieving real-time constraint, minimizing system traffic load, maximizing resource usage as well as the load balancing.
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
35
• Heuristic-based mapping algorithms
Estimation phase:
– Heuristic algorithms and analytical estimation function => exploring and pruning the design space.
– Map a minimum number of logical clusters onto the components of the MPSoC platform => constraints: real-time, system traffic load, load balancing and resource usage.
Simulation phase:
– Candidate solutions obtained in estimation phase are assessed with a system-level simulator.
– Analytical estimation usually focuses on the relevance of subset of design decisions, as well as often fail to consider non-linear system behaviours => make an accurate evaluation difficult without the use of simulation.
APPROACHES AND CONTRIBUTIONS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
36
• Heuristic-based mapping algorithms
APPROACHES AND CONTRIBUTIONS
System-level simulator
Application task graph
Simulation phase
system model generator
Potential mappings
Application specification
Real-time constraint
Architectural template
Select mapping
ConstraintsSatisfied
No satisfied
Best mapping
Components library
Tasks clustering
HW/SW partitioning Assignment
Static performance estimation
Estimation phaseNASA configuration
Search
Feasibility checker
Arc. Platform Gen.
Translator
Simulator
Evaluator
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
37
OUTLINE
Introduction and context
Motivation, challenges and goals
Approaches and contributions
• Results
• Conclusions and future work
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
38
• Co-exploration vs traditional exploration
DSE with multiple genetic algorithms (3GA) vs a single genetic algorithm (1GA).
RESULTS
Parameter Nr. Types ValuesPE ≤ 6 3 ARM, PPC, MIPSSE ≤ 3 2 DDR, SDRNE ≤ 4 3 Bus, Fully-connected, Customized-network
Dimensions (β) 3 - Platform, architectural components and mapping
Search algs. (SA) 1 or 3 1 Genetic algorithmsGA Selection (S) 1 1 Proportional with elitismGA Crossover (C) 1 2 1-point and 2-pointC probability (pc) 5 - [0.1,0.3,0.5,0.8,1.0]GA Mutation (M) 1 2 Simultaneous (M=1) and Independent (M=6)M probability (pm) 5 - [0.1,0.3,0.5,0.8,1.0]Search iterations (I) 41 - -Population size (N) 10 - Nr. of individuals per iteration
Target application: Visual tracking algorithm (ULPGC)
System level simulator: CASSE (ULPGC)
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
39
950
1000
1050
1100
1150
1200
1250
1300
1350
1400
20 70 120 170 220 270 320 370 420Accumulated diversity
Bes
t fitn
ess
valu
e (p
acke
ts/s
)
1GA1x6
1GA2x1
3GA1x6
3GA2x6
10 iterations
950
1000
1050
1100
1150
1200
1250
1300
1350
1400
20 70 120 170 220 270 320 370 420
Accumulated diversity
Bes
t fitn
ess
valu
e (p
acke
ts/s
)
1GA1x6
1GA2x1
3GA1x6
3GA2x6
20 iterations
950
1000
1050
1100
1150
1200
1250
1300
1350
1400
20 70 120 170 220 270 320 370 420Accumulated diversity
Bes
t fitn
ess
valu
e (p
acke
ts/s
)
1GA1x6
1GA2x1
3GA1x6
3GA2x6
30 iterationspc0.8pm0.3
950
1000
1050
1100
1150
1200
1250
1300
1350
1400
20 70 120 170 220 270 320 370 420
Accumulated diversity
Bes
t fitn
ess
valu
e (p
acke
ts/s
)
1GA1x6
1GA2x1
3GA1x6
3GA2x6
40 iterations
• Co-exploration vs traditional exploration
RESULTS
3GA
1GA
3GA
1GA
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
40
• Co-exploration vs traditional exploration
RESULTS
400
600
800
1000
1200
1400
0 100 200 300 400Explored design points
Fitn
ess
valu
es (p
acke
ts/s
)
0 5 10 15 20 25 30 35 40
Iterations
1GA1x6
1GA2x1
3GA1x6
3GA2x6
Real time
Metrics to compare the quality of different DSE approaches:
-Convergence
-Diversity
-CoverageCONVERGENCE
DIVERSITYCOVERAGE
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
41
• Co-exploration vs traditional exploration– In this set of experiments: fitness values=> performance (packets/s).
– 3GA can converge progressively to solutions with a higher fitness value, while 1GA often cannot converge to solutions with higher fitness value (e.g., cannot achieve to the real-time constraint).
RESULTS
400
600
800
1000
1200
1400
0 100 200 300 400Explored design points
Fitn
ess
valu
es (p
acke
ts/s
)
0 5 10 15 20 25 30 35 40
Iterations
1GA1x6
1GA2x1
3GA1x6
3GA2x6
Real time
Real-time constraint
1GA
3GA
Local optima
solutions
3GA can achieve to solutions satisfying the real-time constraint after 15~19 iterations.
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
42
• Co-exploration vs traditional exploration
RESULTS
1GA: after 40 iterations
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
43
3GA: after 40 iterations
• Co-exploration vs traditional exploration
RESULTS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
44
• Co-exploration vs traditional exploration
RESULTS
3GA: after 10 iterations3GA: after 20 iterations3GA: after 30 iterations3GA: after 40 iterations
These solutions still need to be refined for their validations
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
45
• Hierarchical strategy vs Co-exploration
– DSE using our heuristic algorithms to explore and prune the design space vs Co-exploration using 2GA.
– Target MPSoC platform, and variable architectural components and mappings.
– Quality of DSE in term of the average runtime of DSE experiments:
• Co-exploration: 60 simulations x 30 second per simulation = 1800 s.• Hierarchical: 30 ~ 90 s => 2 orders of magnitude more efficient.
– Quality of design solutions in term of four design objectives:(1) Number of resources actually used; (2) resources usage; (3) Minimize PE load unbalancing; (4) Minimize system traffic load.
RESULTS
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
46
• Hierarchical strategy vs Co-exploration
(1) Number of resources actually used; (2) resources usage; (3) Minimize PE load unbalancing; (4) Minimize system traffic load.
RESULTS
RTC (frames/s) (1)* (2) (3) (4)
25Hierarchical 3 (0) 88.875 % 11.533 % 49.045 %
Co-exploration 4 (3) 66.656 % 29.066 % 87.308 %
28Hierarchical 4 (2) 71.655 % 18.427 % 58.903 %
Co-exploration 5 (3) 57.324 % 30.026 % 97.124 %* Number of PE (SE) used in the solution.
– Co-exploration approach also can achieve these optimal solutions or even better solutions => running more iterations.
– Co-exploration with 2GA can provide a set of Pareto Optima solutions => designers decide which strategy to used according to their need.
Higher quality
solutions After 20 iterations
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
47
OUTLINE
Introduction and context
Motivation, challenges and goals
Approaches and contributions
Results
• Conclusions and future work
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
48
• The main goal pursues new approaches that facilitate the system-level design space exploration process => concepts, infrastructure, methods and algorithms.
• It is important to stress that system-level design has been proposed as a complement of the traditional design methods => candidates solutions have to be refined for their validation.
• As future work, it would be interesting to link our approaches to a design flow at lower abstraction level.
• Develop more DSE experiments, integrating other search techniques, simulation tools and application domains, etc, in order to prove progressively the full capability of our approaches.
CONCLUSIONS AND FUTURE WORK
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
THANKS YOU VERY MUCH FOR YOUR ATTENTION!
Universidad de Las Palmas de Gran Canaria
Las Palmas de Gran Canaria, January 25, 2011
Inst
itute
for A
pplie
d M
icro
elec
tron
ics
IUM
A -
ULP
GC
System Level Design Space Exploration for MPSoC: Methods, Algorithms and New Infrastructure
PhD student: Zai Jian Jia Li
Supervisors: Prof. Antonio NúñezAssist. prof. Tomás Bautista
Universidad de Las Palmas de Gran CanariaPrograma de doctorado Sistemas Inteligentes y
Aplicaciones Numéricas en Ingeniería
Las Palmas de Gran Canaria, January 25, 2011
European Doctorate Institute for Applied Microelectronics (IUMA)