An Abstract Modeling Approach Towards System-Level Design-Space Exploration

1
An Abstract Modeling Approach Towards
System-LevelDesign-Space Exploration
F.N. van Wijk1, J.P.M. Voeten1, and A.J.W.M. ten
Berg2 1Information and Communication Systems
GroupFaculty of Electrical Engineering,
Eindhoven University of Technology 2Philips
Research Laboratories Eindhoven
2
Contents

• Motivation
• Modeling concepts
• Simulation
• Performance analysis
• Design-space exploration exercise
• Conclusion and future work

3
Motivation

• Traditional hardware/software co-design methods
  suffer from too many iterations that consume too
  much costly development time.

4
Abstraction pyramid
Source P. Lieverse et al. A Methodology for
Architecture Exploration of Heterogeneous Signal
Processing Systems, Journal of VLSI Signal
Processing, vol. 29, no. 3, 2001.
5
Abstraction pyramid
6
Motivation

• Traditional hardware/software co-design methods
  suffer from too many iterations that consume too
  much costly development time.
• ÞNeed for specification and design methods that
  support fast exploration of design alternatives
  at an early stage of the design trajectory at a
  system-level of abstraction

Embedded systems have heterogenous
architecture. ÞUse Y-chart
7
The Y-chart
Application(s)
Architecture
Source A.C.J. Kienhuis. Design Space Exploration
of Stream-based Dataflow Architectures Methods
and Tools, Ph.D. thesis, Delft University of
Technology, 1999.
8
Motivation

• Traditional hardware/software co-design methods
  suffer from too many iterations that consume too
  much costly development time.
• ÞNeed for specification and design methods that
  support fast exploration of design alternatives
  at an early stage of the design trajectory at a
  system-level of abstraction
• Embedded systems have heterogenous architecture.
• ÞUse Y-chart

ÞUse abstract executable models Taking
well-founded design decisions requires a
well-defined modeling language ÞUse POOSL
9
POOSL

• The Parallel Object-Oriented Specification
  Language POOSL is a formal specification language
  based on a probabilistic timed version of process
  algebra CCS and on the basic concepts of
  traditional object-oriented programming languages
  (Smalltalk, Java, C).
• Why use POOSL?
• formal semantics
• expressiveness
• abstraction
• compositional
• behavioral and structural

• real-time
• probabilistic
• transparency

10
Example POOSL model
11
Validation
12
Contents

• Motivation
• Modeling concepts
• Simulation
• Performance analysis
• Design-space exploration exercise
• Conclusion and future work

13
Model structure
System Model
Functional Model
T3
T1
T2
Mapping
Resource Model
R1
R2
R3
R4
Performance Analysis
14
Resource Model

• Three basic, parameterizable resource types
• Processing Resource (P)
• Communication Resource (C)
• Storage Resource (S)

15
Resource Model

• Three basic, parameterizable resource types
• Processing Resource (P)
• Operate()()
• instruction String instructionDelay Real
• task?resourceRequest(instruction)
• instructionDelay instructionTable
  getDelay(instruction)
• delay(instructionDelay)
• task!acknowledge
• Operate()().
• Communication Resource (C)
• Storage Resource (S)

16
Resource Model

• Three basic, parameterizable resource types
• Processing Resource (P)
• Communication Resource (C)
• Operate()()
• packetSize, duration Real
• fifo?requestBW(packetSize)
• delay(transferDelay packetSize)
• fifo!ready
• Operate()().
• Storage Resource (S)

17
Resource Model

• Storage Resource (S)
• Operate()()
• packetSize Real
• sel
• room gt 0fifo?malloc(packetSize)
• if room gt packetSize then room room -
  packetSize
• else packetSize room room 0 fi
• fifo!grant(packetSize, room)
• or
• fifo?free(packetSize)
• room room packetSize
• fifo!ready(room)
• les
• Operate()().

18
An example communication channel
19
Contents

• Motivation
• Modeling concepts
• Simulation
• Performance analysis
• Design-space exploration exercise
• Conclusion and future work

20
Structure diagram
Functional Model
M a p p i n g
Resource Model
21
Message flow diagram
22
Message flow diagram
23
Contents

• Motivation
• Modeling concepts
• Simulation
• Performance analysis
• Design-space exploration exercise
• Conclusion and future work

24
Model Analysis

• Each model is equipped with a mathematically
  defined semantics.
• Each model uniquely defines a timed probabilistic
  labelled transition system.
• This LTS is the basis for all analyses
• Formal verification (exhaustive)
• Simulation-based verification (non-exhaustive)
• Analytical performance evaluation (exhaustive)
• Simulation-based performance evaluation
  (non-exhaustive).

25
Performance Analysis

• Specify the performance metric as a (temporal)
  reward.
• Examples utilizations, jitter, buffer fill
  levels, throughput.
• Determine the long-run average metric value
• Analytically
• Generate the complete timed probabilistic
  labelled transition system
• Interpret it as a Markov chain with (temporal)
  reward structure
• Compute performance metric by means of
  equilibrium analysis
• Certain/precise results but only applicable in
  case of relatively small finite-state systems.
• By simulation
• Generate one execution trace
• Estimate the metric value, confidences and errors
  by means of the central limit theorem for Markov
  chains
• Uncertain results but applicable in case of large
  and even infinite-state systems.

26
Contents

• Motivation
• Modeling concepts
• Simulation
• Performance analysis
• Design-space exploration exercise
• Conclusion and future work

27
Example Producer-Filter-Consumer (PFC)
alternative 1
28
Example Producer-Filter-Consumer (PFC)
alternative 2
29
PFC-example (contd)

30
PFC-example (contd)
31
PFC-example Performance Analysis
32
Contents

• Motivation
• Modeling concepts
• Simulation
• Performance analysis
• Design-space exploration exercise
• Conclusion and future work

33
Conclusions

• An abstract modeling approach to system-level
  design-space exploration for complex
  heterogeneous systems has been presented.
• The approach supports fast exploration of
  alternative realizations using abstract
  executable formal models.
• Functional models are mapped onto Resource models
  (strict coupling, mutually disconnected
  resources) and together form a System Model.
• Strict coupling enables the modeling of
  non-determinism.
• Both control and data oriented behavior can be
  expressed.
• Modeling of resource sharing is straightforward.
• Simulation-based performance analysis yields
  performance figures. Based on the formal
  semantics of POOSL, their accuracy can be
  estimated.

34
Future Work

• Add support for stream-based functional models.
• Assess performance metrics, their representation
  and accuracy analysis further.
• Extension of schedulers / arbiters to support
  multiple resource scheduling policies.
• Þ Validation of the approach against a relevant
  industrial case is ongoing.

35
Thank you.Questions?

• Eindhoven University of Technology
• Information and Communication Systems Group
• http//www.ics.ele.tue.nl
• f.n.v.wijk_at_tue.nl