4 july 2005 overview traineeship: mapping of data structures in multiprocessor systems nick de...
Post on 19-Dec-2015
213 Views
Preview:
TRANSCRIPT
4 July 2005
overview
Traineeship: Mapping of data
structures in multiprocessor
systemsNick de Koning0513849a.h.m.d.koning@student.tue.nl
1
Content
1. Introduction
2. Problem definition
3. Approach
4. Implementation
5. To do list
6. Future work
2
Content
1. Introduction
2. Problem definition
3. Approach
4. Implementation
5. To do list
6. Future work
3
Introduction
• Why this project?
– Mapping of data structures in multiprocessor
systems
• Chips are getting memory dominated
• Upcoming of multiprocessor systems
4
Introduction
• Estimations: > 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
5
TriMedia 32A200 Mhz0.18u 16.9 mm2
Introduction
• Power consumption is (becoming) the bottleneck
in chip design
• Power consumption is crucial in embedded
systems!!!
6
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 < V1 then P2 < P1
7
Introduction
2005 Intel developer forum, San Francisco 8
Introduction
http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_608,00.html 9
IntroductionMemory 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
Introduction
In order to map the data structures onto the available
memories,
a designer needs to know:
1. What are the data structures that are used in the
application?
2. What are the memory requirements of the
application?
11
Content
1. Introduction
2. Problem definition
3. Approach
4. Implementation
5. To do list
6. Future work
12
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
Problem definition
Multiprocessor template:
Local memory
Remote memory
14
Problem definition
Calculating stack size requirements, example:
Scope tree
15
Problem definition
But, what happens if the C-code changes to this?
16
Problem definition
Scope tree
17
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
Content
1. Introduction
2. Problem definition
3. Approach
4. Implementation
5. To do list
6. Future work
19
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
Approach
Intermezzo: Let’s introduce some notations!
21
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
Approach
23
Approach
• Writing out a recursive cycle as a string can be quite a
job…
• Let’s introduce a shorthand notation based on logical
expressions:
24
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
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
Approach
Or, more abstract:
Bound by FCG
Tighter bound due control + dataflow
27
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
ApproachSpecifying 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
Approach
Optimisations are possible!
30
Content
1. Introduction
2. Problem definition
3. Approach
4. Implementation
5. To do list
6. Future work
31
ImplementationImplemented 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
Implementation
Stack size calculation algorithm (pseudo code):
33
Implementation
Path + function
Valid / invalid
Is implemented
34
ImplementationExample:
Path = main, foo_3, foo_1Function = foo_3
s1 = main, foo_3, foo_1, (foo_2)10
s2 = main, foo_3, foo_2
35
Implementation
Path + function
Recursion = foo_2Repeat = 10
Path = main, foo_3, foo_1Function = foo_2
s1 = main, foo_3, foo_1, (foo_2)10
s2 = main, foo_3, foo_2
Not implemented yet
36
ImplementationExample XML input file and
FCG:
37
Implementation
Example program output:
38
Implementation
39
Implementation
40
Implementation
41
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
Content
1. Introduction
2. Problem definition
3. Approach
4. Implementation
5. To do list
6. Future work
43
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
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
top related