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