fakultät für informatik informatik 12 technische universität dortmund Specifications - Session 5 - Peter Marwedel TU Dortmund Informatik 12 Germany Slides use Microsoft cliparts. All Microsoft restrictions apply.

- 2 - technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Schedule of the course TimeMondayTuesdayWednesdayThursdayFriday 09:30- 11:00 1: Orientation, introduction 2: Models of computation + specs 5: Models of computation + specs 9: Mapping of applications to platforms 13: Memory aware compilation 17: Memory aware compilation 11:00 Brief break 11:15- 12:30 6: Lab*: Ptolemy 10: Lab*: Scheduling 14: Lab*: Mem. opt. 18: Lab*: Mem. opt. 12:30Lunch 14:00- 15:20 3: Models of computation + specs 7: Mapping of applications to platforms 11: High-level optimizations* 15: Memory aware compilation 19: WCET & compilers* 15:20Break 15:40- 17:00 4: Lab*: Kahn process networks 8: Mapping of applications to platforms 12: High-level optimizations* 16: Memory aware compilation 20: Wrap-up * Dr. Heiko Falk

- 3 - technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 From data flow to task graphs  “Lunatics” (S. Edwards) tried to build general purpose data flow computers, but failed  However, modern computers contain subsystems build on the data flow paradigm (scoreboard, Tomasulo’s algorithm)  Pure data flow frequently too restrictive: lack of modeling control, resources etc.  Data flow graphs are a special case of the somewhat more general task graphs. 

- 4 - technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Task graphs Many applications can be specified in the form of a set of communicating processes. Example: system with two sensors: mux temperature sensor humidity sensor FIFO Alternating read loop read_temp; read_humi until false; of the two sensors no the right approach.

- 5 - technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 The case for multi-process modeling MODULE main; TYPE some_channel = (temperature, humidity); some_sample : RECORD value : integer; line : some_channel END; PROCESS get_temperature; VAR sample : some_sample; BEGIN LOOP sample.value := new_temperature; IF sample.value > 30 THEN.... sample.line := temperature; to_fifo(sample); END END get_temperature; PROCESS get_humidity; VAR sample : some_sample; BEGIN LOOP sample.value := new_humidity; sample.line := humidity; to_fifo(sample); END END get_humidity; BEGIN get_temperature; get_humidity; END;  Blocking calls new_temperature, new_humidity  Structure clearer than alternating checks for new values in a single process How to model dependencies between tasks/processes?

- 6 - technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Dependences between processes/tasks Get_tem- perature Get_ humidity FIFO  General discussion of process networks main

- 7 - technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Task graphs Def.: A dependence graph is a directed graph G=(V,E) in which E  V  V is a partial order. If (v1, v2)  E, then v1 is called an immediate predecessor of v2 and v2 is called an immediate successor of v1. Suppose E* is the transitive closure of E. If (v1, v2)  E*, then v1 is called a predecessor of v2 and v2 is called a successor of v1. Nodes are assumed to be a “program“ described in some programming language, e.g. C or Java. Sequence constraint

- 8 - technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Task graphs 1. Timing information - Task graphs may contain additional information, for example: Timing information ] Arrival timedeadline

- 9 - technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Task graphs 2. I/O-information

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Task graphs 3. Shared resources

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Task graphs 4. Hierarchical task graphs -

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Multi-thread graphs (IMEC) Def.: A multi-thread graph M is defined as an 11-tuple (O, E, V, D,, , , E lat, E resp,  i,  av ) with:  O: set of operation nodes,  E: set of control edges,  V, D : refer to the access of variables,   : is the set of input/output nodes,   : associates execution latency intervals with all threads,  E lat, E resp,  i,  av are timing constraints.

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 MTG graphs: graphical notation

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Computational graphs in UML: Sequence Diagram deliverable 2.1

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Computational UML: Activity diagram © Cris Kobryn: UML 2001: A Standardization Odyssey, CACM, October, 1999 Extended Petri nets. Include decisions (like in flow charts). Graphical notation similar to SDL. “swimlane“

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Models of computation considered in this course Communication/ local computations Shared memory Message passing Synchronous | Asynchronous Communicating finite state machines StateChartsSDL Data flow modelNot useful(Simulink, LabView) Kahn process networks, SDF Von Neumann model C, C++, Java C, C++, Java with libraries CSP, ADA | Discrete event (DE) model VHDL, Verilog, SystemC Only experimental systems, e.g. distributed DE in Ptolemy

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Synchronous message passing: CSP  CSP (communicating sequential processes) [Hoare, 1985], rendez-vous-based communication: Example: process A.. var a... a:=3; c!a; -- output end process A.. var a... a:=3; c!a; -- output end process B.. var b c?b; -- input end process B.. var b c?b; -- input end

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Synchronous message passing: ADA After Ada Lovelace (said to be the 1st female programmer). US Department of Defense (DoD) wanted to avoid multitude of programming languages  Definition of requirements  Selection of a language from a set of competing designs (selected design based on PASCAL) ADA’95 is object-oriented extension of original ADA. Salient: task concept

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Synchronous message passing: ADA-rendez-vous task screen_out is entry call_ch(val:character; x, y: integer); entry call_int(z, x, y: integer); end screen_out; task body screen_out is... select accept call_ch... do.. end call_ch; or accept call_int... do.. end call_int; end select; Sending a message: begin screen_out.call_ch('Z',10,20); exception when tasking_error => (exception handling) end; Sending a message: begin screen_out.call_ch('Z',10,20); exception when tasking_error => (exception handling) end;

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Message passing libraries Example: MPI/Open MPI  Library designed for high-performance computing (hpc)  Based on asynchronous/synchronous message passing  Comprehensive, popular library  Available on a variety of platforms  Considered also for multiple processor system-on-a-chip (MPSoC) programming for embedded systems;  MPI includes many copy operations to memory  (memory speed ~ communication speed for MPSoCs); Appropriate MPSoC programming tools missing. p/mpi/MAIN.html#Getting_Started

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 MPI (1) Sample blocking library call (for C):  MPI_Send(buffer,count,type,dest,tag,comm) where -buffer: Address of data to be sent -count: number of data elements to be sent -type: data type of data to be sent (e.g. MPI_CHAR, MPI_SHORT, MPI_INT, …) -dest: process id of target process -tag: message id (for sorting incoming messages) -comm: communication context = set of processes for which destination field is valid -function result indicates success op/mpi/MAIN.html#Getting_Started

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 MPI (2) Sample non-blocking library call (for C):  MPI_Isend(buffer,count,type,dest,tag,comm,request) where -buffer … comm: same as above -request: the system issues a unique "request number". The programmer uses this assigned "handle" later (in a WAIT type routine) to determine completion of the non-blocking operation. op/mpi/MAIN.html#Getting_Started

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Models of computation VHDL as a prominent example of discrete event modeling: Communication/ Computation Shared memory Message passing blockingNon-blocking FSMStateChartsSDL Data flow modelKahn process networks, SDL Imperative von Neumann computing C, C++, JavaC, C++, Java with message passing libraries CSP, ADA Discrete event modelVHDL, Verilog, SystemC Just experimental systems, e.g. distributed discrete event simulation in Ptolemy

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Sensivity lists Sensivity lists are a shorthand for a single wait on- statement at the end of the process body: process (x, y) begin prod <= x and y ; end process; is equivalent to process begin prod <= x and y ; wait on x,y; end process;

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 VHDL semantics: initialization At the beginning of initialization, the current time, T c is 0 ns.  The driving value and the effective value of each explicitly declared signal are computed, and the current value of the signal is set to the effective value. …  Each... process … is executed until it suspends.  The time of the next simulation cycle (… in this case … the 1st cycle), T n is calculated according to the rules of step f of the simulation cycle, below.

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 VHDL semantics: The simulation cycle (1) Each simulation cycle starts with setting T c to T n. T n was either computed during the initialization or during the last execution of the simulation cycle. Simulation terminates when the current time reaches its maximum, TIME'HIGH. According to the standard, the simulation cycle is as follows: a)The current time, T c is set to T n. Stop if T n = TIME'HIGH and not  active drivers or process resumptions at T n. ?

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 VHDL semantics: The simulation cycle (2) b)Each active explicit signal in the model is updated. (Events may occur as a result.) Previously computed entries in the queue are now assigned if their time corresponds to the current time T c. New values of signals are not assigned before the next simulation cycle, at the earliest. Signal value changes result in events  enable the execution of processes that are sensitive to that signal. c)..

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 VHDL semantics: The simulation cycle (3) d e e d)  P sensitive to s: if event on s in current cycle: P resumes. e)Each... process that has resumed in the current simulation cycle is executed until it suspends*. * Generates future values for signal drivers.

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 VHDL semantics: The simulation cycle (4) f)Time T n of the next simulation cycle = earliest of 1.TIME'HIGH (end of simulation time). 2.The next time at which a driver becomes active 3.The next time at which a process resumes (determined by wait for statements). Next simulation cycle (if any) will be a delta cycle if T n = T c. f

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008  -simulation cycles … Next simulation cycle (if any) will be a delta cycle if T n = T c. Delta cycles are generated for delay-less models. There is an arbitrary number of  cycles between any 2 physical time instants: In fact, simulation of delay-less hardware loops might not terminate (don’t even advance T c ).

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008  -simulation cycles Simulation of an RS-Flipflop architecture one of RS_Flipflop is begin process: (R,S,Q,nQ) begin Q <= R nor nQ; nQ <= S nor Q; end process; end one; 0ns 0ns+  0ns+2  0ns+3  R S Q nQ ns 0ns+  0ns+2  0ns+3  R S Q nQ st  2nd   cycles reflect the fact that no real gate comes with zero delay.  should delay-less signal assignments be allowed at all?  cycles reflect the fact that no real gate comes with zero delay.  should delay-less signal assignments be allowed at all? 3rd 

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008  -simulation cycles and deterministic simulation semantics Semantics of a <= b; b <= a; ? Separation into 2 simulation phases results in deterministic semantics (  StateMate).

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 SystemC: Required features Requirements, solutions for modeling HW in a SW language:  C++ class library including required functions.  Concurrency: via processes, controlled by sensivity lists* and calls to wait primitives.  Time: Floating point numbers in SystemC 1.0. Integer values in SystemC 2.0; Includes units such as ps, ns, µs etc*.  Support of bit-datatypes: bitvectors of different lengths; 2- and 4-valued logic; built-in resolution*)  Communication: plug-and-play (pnp) channel model, allowing easy replacement of intellectual property (IP)  Deterministic behavior not guaranteed. * Good to know VHDL

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Transitions between thread states - Predicate/transition net model  activity chart  queuing model - run   ready ={} capacity=1 wait(t) ready notify(event)* notify(event, SC_ZERO_TIME)* wait (event) timeout°/advance simulation time *for (ready={}  ={}): for threads waiting for event °timeout=(ready={}  ={})  thread waiting time = min. of all waiting times wait(SC_ZERO_TIME) return update signals each time ready becomes {} (end of  cycle), see sc_signal prio=1 prio=2 prio=3 simulation start: dont_inits: placed in  waiting for static sensivity event others: placed in ready

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Ptolemy Ptolemy (UC Berkeley) is an environment for simulating multiple models of computation.  Ptolemy simulations

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 UML for real-time? Initially not designed for real-time. Initially lacking features:  Partitioning of software into tasks and processes  specifying timing  specification of hardware components  Projects on defining real-time UML based on previous work  ROOM [Selic] is an object-oriented methodology for real- time systems developed originally at Bell-Northern Research.  “UML profile for schedulability, performance and time“

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 SoC=system on a chip

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Example: Activity diagram with annotations See also W. Müller et al.: UML for SoC, [

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Summary  Task graphs Multi thread graph (IMEC)  Imperative languages CSP, ADA Communication libraries (MPI etc)  Discrete event systems (VHDL, SystemC)  UML profiles

technische universität dortmund fakultät für informatik  p. marwedel, informatik 12, 2008 Brief break (if on schedule) Q&A?