4 July 2005 overview Traineeship: Mapping of data structures in multiprocessor systems Nick de Koning

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 32A 200 Mhz 0.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 MHz50 MHz P 1 = f C V 1 P 2 = 2 f/2 C V 2 [simplified] If V 2 < V 1 then P 2 < P 1 7

Introduction 2005 Intel developer forum, San Francisco 8

Introduction 9

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

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 + data flow 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

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_3prefix2 = 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

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

Implementation Stack size calculation algorithm (pseudo code): 33

Implementation Path + function Valid / invalid Is implemented 34

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

Implementation Path + function Recursion = foo_2 Repeat = 10 Path = main, foo_3, foo_1 Function = foo_2 s1 = main, foo_3, foo_1, (foo_2) 10 s2 = main, foo_3, foo_2 Not implemented yet 36

Implementation Example 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