overview

1
overview

• Traineeship Mapping of data structures in
  multiprocessor systems

Nick de Koning0513849a.h.m.d.koning_at_student.tue.
nl
1
2
Content

• Introduction
• Problem definition
• Approach
• Implementation
• To do list
• Future work

2
3
Content

• Introduction
• Problem definition
• Approach
• Implementation
• To do list
• Future work

3
4
Introduction

• Why this project?
• Mapping of data structures in multiprocessor
  systems
• Chips are getting memory dominated
• Upcoming of multiprocessor systems

4
5
Introduction

• Estimations gt 90 chip area is memory in 2010!
• Chips are increasingly becoming memory dominated
• Logic scales faster with chip technology then
  memory
• Increasing memory requirements of multimedia
  applications

TriMedia 32A 200 Mhz 0.18u 16.9 mm2
5
6
Introduction

• Power consumption is (becoming) the bottleneck in
  chip design
• Power consumption is crucial in embedded
  systems!!!

6
7
Introduction

• Solution multiprocessor system-on-chip!

100 MHz
50 MHz
50 MHz
P1 f C V1
P2 2 f/2 C V2
simplified If V2 lt V1 then P2 lt P1
7
8
Introduction
8
2005 Intel developer forum, San Francisco
9
Introduction
9
http//www.amd.com/us-en/Corporate/VirtualPressRoo
m/0,,51_104_608,00.html
10
Introduction

• Memory spaces seen by an application
• Stack stores local data structures
• Heap holds dynamically allocated memory
• Global data space stores global (and static)
  data structures
• System-on-chips of the future incorporate many IP
  cores and memories need for memory re-use!
• A designer sees all these memories... How and
  which data structures of the application will
  (s)he put in what memory ?

10
11
Introduction

• In order to map the data structures onto the
  available memories,
• a designer needs to know
• What are the data structures that are used in the
  application?
• What are the memory requirements of the
  application?

11
12
Content

• Introduction
• Problem definition
• Approach
• Implementation
• To do list
• Future work

12
13
Problem definition

• Memory requirements application
• Stack size requirements
• Memory required for global data structures
• Heap not considered
• Dynamic memory allocation is hardly used in
  embedded systems
• Applications in C-programming language
• THE programming language for embedded systems
• Stack size requirements only accurate without
  compiler optimisations

13
14
Problem definition

• Multiprocessor template

Remote memory
Local memory
14
15
Problem definition

• Calculating stack size requirements, example

Scope tree
15
16
Problem definition

• But, what happens if the C-code changes to this?

16
17
Problem definition
Scope tree
17
18
Problem definition

• Problem not every function call in the
  application code is executed in practice due to
  control flow and data flow, how to deal with them
  ?!

18
19
Content

• Introduction
• Problem definition
• Approach
• Implementation
• To do list
• Future work

19
20
Approach

• An automated memory requirements calculator only
  sees the function call graph!
• F C G nodes are functions arrows represents
  the call of another function

20
21
Approach

• Intermezzo Lets introduce some notations!

21
22
Approach

• Define the following sets

In this context a string represents a sequence
of function calls. For example Alphabet F
main, foo1, foo2, foo3 ? ? F? ? (main,
foo1, foo3)
22
23
Approach
23
24
Approach

• Writing out a recursive cycle as a string can be
  quite a job
• Lets introduce a shorthand notation based on
  logical expressions

24
25
Approach

• A recursive cycle written as a logical expression
  can contain nested recursive cycles
• Length, prefix and concatenation also operate on
  strings written as logical expression
• Example
• foo_1, foo_2, foo_1, foo_2, foo_1, foo_2
• (foo_1, foo_2)3
• Example

25
26
Approach

• Q Why are these strings required?

• A1
• The automated memory size calculator does not
  take control flow and data flow into account!
• It only knows the function call graph
• For instance, recall

26
27
Approach

• Or, more abstract

Bound by FCG
Tighter bound due control data flow
27
28
Approach

• Q Why are these strings required?
• A2
• The user must limit the observed space to only
  contain the feasible region!
• The user specifies the sequences of function
  calls that are feasible as strings to the memory
  requirements calculator!

28
29
Approach

• Specifying strings for an application
• Use logical expression to capture recursive
  cycles efficiently
• Use prefix strings to re-use common parts in
  strings
• For example, the following sequences can appear
  in an application
• ( s1   main, foo_3, foo_1, foo_2, foo_1, foo_2,
  foo_2, foo_2
• s2 main, foo_3, foo_1, foo_2, foo_1, foo_3,
  foo_3,foo_3.
• s3 main, foo_3, foo_3.
• Prefix strings are
• prefix1 main, foo_3 prefix2 prefix1, foo_1,
  foo_2, foo_1
• The user specifies
• s1 prefix2, (foo_2)3
• s2 prefix2, (foo_1)3
• s3 prefix1, foo_3

29
30
Approach

• Optimisations are possible!

30
31
Content

• Introduction
• Problem definition
• Approach
• Implementation
• To do list
• Future work

31
32
Implementation

• Implemented tool statesize
• Linux, C
• Based on SUIF Compiler system
• Evaluates C-programs
• Calculates memory requirements of applications
• Detects used global variables in the functions
  global memory requirements
• User input
• All allowed sequences of functions as strings
• Strings written as logical expressions in XML
  input file
• XML provides high level of re-use
• Supports use of prefix, logical expressions

32
33
Implementation

• Stack size calculation algorithm (pseudo code)

33
34
Implementation
Is implemented
Path function
Valid / invalid
34
35
Implementation
Example
Path main, foo_3, foo_1 Function foo_3
s1 main, foo_3, foo_1, (foo_2)10 s2 main,
foo_3, foo_2
35
36
Implementation
Not implemented yet
Path main, foo_3, foo_1 Function foo_2
Path function
Recursion foo_2 Repeat 10
s1 main, foo_3, foo_1, (foo_2)10 s2 main,
foo_3, foo_2
36
37
Implementation

• Example XML input file and FCG

37
38
Implementation

• Example program output

38
39
Implementation
39
40
Implementation
40
41
Implementation
41
42
Implementation

• Statesize
• Calculates stack size requirements
• With / without function calls
• Calculates global memory requirements
• Detects which global data structures are used
• Directly / indirectly
• Parses user specified strings (XML input file)

42
43
Content

• Introduction
• Problem definition
• Approach
• Implementation
• To do list
• Future work

43
44
To do list

• Statesize enhancements
• Implement optimisations
• Command line option write out all detected
  (nested) recursion cycles to XML file
• ? FCV add suffix checking e.g. foo3, foo1 ?
• Report
• Problem definition add section
• Implementation spec. FCV, spec. user input
• Write Case study and Future Work
• Case study
• Test on real multimedia application

44
45
Future work

• Add function overloading support
• Pre processing pass
• Embed in statesize uglier
• Full support regular expressions in XML input
  file
• In functions foo_
• In strings prefix, , suffix

45