fakultät für informatikinformatik 12
technische universität dortmund
Mapping: Applications Platforms- Sessions 7-9 -
Peter MarwedelTU DortmundInformatik 12
Germany
Slides use Microsoft cliparts. All Microsoft restrictions apply.
- 2 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Schedule of the course
Time Monday Tuesday Wednesday Thursday Friday
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 Brief break Brief break Brief break
11:15-12:30
6: Lab*: Ptolemy
10: Lab*: Scheduling
14: Lab*: Mem. opt.
18: Lab*: Mem. opt.
12:30 Lunch Lunch Lunch Lunch Lunch
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:20 Break Break Break Break Break
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ätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Hypothetical design flow
Specifications
Embedded System HW
Standard Software, Real-Time Operating Systems
Applications of applications to execution platforms
Evaluation
Testing
Optimization of Embedded Systems
App
licat
ion
Kno
wle
dge
- 4 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Scope of mapping algorithms
Useful terms from hardware synthesis: Resource Allocation
Decision concerning type and number of available resources
Resource AssignmentMapping: Task (Hardware) Resource
xx to yy binding:Describes a mapping from behavioral to structural domain, e.g. task to processor binding, variable to memory binding
SchedulingMapping: Tasks Task start timesSometimes, resource assignment isconsidered being included in scheduling.
- 5 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Real-time scheduling
Assume that we are given a task graph G=(V,E).
Def.: A schedule of G is a mapping V Tof a set of tasks V to start times from domain T.
V1 V2 V4V3
t
G=(V,E)
T
Typically, schedules have to respect a number of constraints, incl. resource constraints, dependency constraints, deadlines.Scheduling = finding such a mapping.
- 6 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Hard and soft deadlines
Def.: A time-constraint (deadline) is called hard if not meeting that constraint could result in a catastrophe [Kopetz, 1997].
All other time constraints are called soft.
We will focus on hard deadlines.
- 7 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Periodic and aperiodic tasks
Def.: Tasks which must be executed once every p units of time are called periodic tasks. p is called their period. Each execution of a periodic task is called a job.
All other tasks are called aperiodic.
Def.: Tasks requesting the processor at unpredictable times are called sporadic, if there is a minimum separation between the times at which they request the processor.
- 8 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Preemptive and non-preemptive scheduling
Non-preemptive schedulers:
Tasks are executed until they are done.
Response time for external events may be quite long. Preemptive schedulers: To be used if
- some tasks have long execution times or- if the response time for external events to be short.
- 9 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Dynamic/online scheduling
Dynamic/online scheduling:Processor allocation decisions (scheduling) at run-time; based on the information about the tasks arrived so far.
- 10 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Static/offline scheduling
Static/offline scheduling:Scheduling taking a priori knowledge about arrival times, execution times, and deadlines into account.Dispatcher allocates processor when interrupted by timer. Timer controlled by a table generated at design time.
In a time-triggered system, the temporal control structure of all tasks is established a priori by off-line support-tools.
- 11 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Cost functions
Cost function: Different algorithms aim at minimizing different functions.
Def.: Maximum lateness = maxall tasks (completion time – deadline)
Is <0 if all tasks complete before deadline.
t
T1
T2Max. lateness
- 12 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Classes of mapping algorithmsconsidered in this course
Classical scheduling algorithmsMostly for independent tasks & ignoring communication, mostly for mono- and homogeneous multiprocessors
Resource access protocols Dependent tasks as considered in architectural
synthesisInitially designed in different context, but applicable
Hardware/software partitioningDependent tasks, heterogeneous systems,focus on resource assignment
Design space exploration using genetic algorithmsHeterogeneous systems, incl. communication modeling
- 13 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Aperiodic scheduling- Scheduling with no precedence constraints -
Let {Ti } be a set of tasks. Let:
ci be the execution time of Ti ,
di be the deadline interval, that is, the time between Ti becoming available and the time until which Ti has to finish execution.
ℓi be the laxity or slack, defined as ℓi = di - ci
fi be the finishing time.
ℓi
di
cit
i
- 14 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Uniprocessor with equal arrival times
Preemption is useless.
Earliest Due Date (EDD): Execute task with earliest due date (deadline) first.
EDD requires all tasks to be sorted by their (absolute) deadlines. Hence, its complexity is O(n log(n)).
fifi fi
- 15 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Optimality of EDD
EDD is optimal, since it follows Jackson's rule:Given a set of n independent tasks, any algorithm that executes the tasks in order of non-decreasing (absolute) deadlines is optimal with respect to minimizing the maximum lateness.
Proof (See Buttazzo, 2002):
Let be a schedule produced by any algorithm A
If A EDD Ta, Tb, da ≤ db, Tb immediately precedes
Ta in .
Let ' be the schedule obtained by exchanging Ta and Tb.
- 16 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Exchanging Ta and Tb cannot increase lateness
Max. lateness for Ta and Tb in is Lmax(a,b)=fa-da
Max. lateness for Ta and Tb in ' is L'max(a,b)=max(L'a,L'b)
Two possible cases
1. L'a ≥ L'b: L'max(a,b) = f'a – da < fa – da = Lmax(a,b)since Ta starts earlier in schedule '.
2. L'a ≤ L'b: L'max(a,b) = f'b – db = fa – db ≤ fa – da = Lmax(a,b) since fa=f'b and da ≤ db
L'max(a,b) ≤ Lmax(a,b)Tb
TbTa
'
Ta
fa=f'b
- 17 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
EDD is optimal
Any schedule with lateness L can be transformed into an EDD schedule n with lateness Ln ≤ L, which is the minimum lateness.
EDD is optimal (q.e.d.)
- 18 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Earliest Deadline First (EDF)- Horn’s Theorem -
Different arrival times: Preemption potentially reduces lateness.
Theorem [Horn74]: Given a set of n independent tasks with arbitrary arrival times, any algorithm that at any instant executes the task with the earliest absolute deadline among all the ready tasks is optimal with respect to minimizing the maximum lateness.
- 19 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Earliest Deadline First (EDF)- Algorithm -
Earliest deadline first (EDF) algorithm: Each time a new ready task arrives: It is inserted into a queue of ready tasks, sorted by their
absolute deadlines. Task at head of queue is executed. If a newly arrived task is inserted at the head of the
queue, the currently executing task is preempted.Straightforward approach with sorted lists (full comparison with existing tasks for each arriving task) requires run-time O(n2); (less with binary search or bucket arrays).
Sorted queue
Executing task
- 20 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Earliest Deadline First (EDF)- Example -
Later deadline no preemption
Earlier deadline preemption
- 21 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Least laxity (LL), Least Slack Time First (LST)
Priorities = decreasing function of the laxity (the less laxity, the higher the priority); dynamically changing priority; preemptive.
ℓℓ
ℓℓ
ℓℓ
ℓℓℓ
ℓℓℓ
- 22 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Scheduling with precedence constraints
Task graph and possible schedule:
- 23 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Simultaneous Arrival Times:The Latest Deadline First (LDF) Algorithm
LDF [Lawler, 1973]: reads the task graph and among the tasks with no successors inserts the one with the latest deadline into a queue. It then repeats this process, putting tasks whose successor have all been selected into the queue.At run-time, the tasks are executed in the generated total order.LDF is non-preemptive and is optimal for mono-processors.
If no local deadlines exist, LDF performs just a topological sort.
- 24 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Asynchronous Arrival Times:Modified EDF Algorithm
This case can be handled with a modified EDF algorithm.The key idea is to transform the problem from a given set of dependent tasks into a set of independent tasks with different timing parameters [Chetto90].This algorithm is optimal for mono-processor systems.
If preemption is not allowed, the heuristic algorithm developed by Stankovic and Ramamritham can be used.
- 25 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Overview
© L. Thiele, ETH Zürich, 2006
Equal arrival timesNon preemptive
Arbitrary arrival timespreemptive
Independent tasks
EDD (Jackson) EDF (Horn)
Dependent tasks LDF (Lawler) EDF* (Chetto)
Scheduling of aperiodic tasks with real time constraints:Table with some known algorithms:
- 26 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Periodic scheduling
For periodic scheduling, the best that we can do is to design
an algorithm which will always find a schedule if one exists.
A scheduler is defined to be optimal iff it will find a
schedule if one exists.
T1
T2
- 27 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Periodic scheduling
Let pi be the period of task Ti, ci be the execution time of Ti, di be the deadline interval, that is, the time between a job
of Ti becoming available and the time until the same job Ti has to finish execution.
ℓi be the laxity or slack, defined as ℓi = di - ci pi
di
ci ℓi
- 28 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Average utilization
Average utilization:
n
i i
i
p
c
1
Necessary condition for schedulability(with m=number of processors):
m
- 29 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Independent tasks:Rate monotonic (RM) scheduling
Most well-known technique for scheduling independentperiodic tasks [Liu, 1973].Assumptions: All tasks that have hard deadlines are periodic.
All tasks are independent.
di=pi, for all tasks.
ci is constant and is known for all tasks.
The time required for context switching is negligible.
For a single processor and for n tasks, the following equation holds for the average utilization µ:
)12( /1
1
nn
i i
i np
c
- 30 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Rate monotonic (RM) scheduling- The policy -
RM policy: The priority of a task is a monotonically decreasing function of its period.
At any time, a highest priority task among all those that are ready for execution is allocated.
Theorem: If all RM assumptions are met, schedulability is guaranteed.
- 31 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Maximum utilization for guaranteed schedulability
Maximum utilization as a function of the number of tasks:
)2ln()12((lim
)12(
/1
/1
1
n
n
nn
i i
i
n
np
c
- 32 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Example of RM-generated schedule
T1 preempts T2 and T3.T2 and T3 do not preempt each other.
- 33 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Case of failing RM scheduling
Task 1: period 5, execution time 2Task 2: period 7, execution time 4µ=2/5+4/7=34/35 0.97 2(21/2-1) 0.828
Missed deadline
Missing computations scheduled in the next period
- 34 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Intuitively: Why does RM fail ?
No problem if p2 = m p1, mℕ :
T1
T2
t fits
T1
T2
t
should be completed
Switching to T1 too early, despite early deadline for T2
leviRTS animation
- 35 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Critical instants
Definition: A critical instant of a task is the time at which the release of a task will produce the largest response time.
Lemma: For any task, the critical instant occurs if that task is simultaneously released with all higher priority tasks.
Proof: Let T={T1, …,Tn}: periodic tasks with i: pi ≦ pi +1.
Source: G. Buttazzo, Hard Real-time Computing Systems, Kluwer, 2002
- 36 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Critical instances (1)
Response time of Tn is delayed by tasks Ti of higher priority:
cn+2ci
Tn
Ti
t
Maximum delay achieved if Tn and Ti start simultaneously.
Maximum delay achieved if Tn and Ti start simultaneously.
cn+3ci
Tn
Ti
t
Delay may increase if Ti starts earlierDelay may increase if Ti starts earlier
- 37 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Critical instants (2)
Repeating the argument for all i = 1, … n-1:
The worst case response time of a task occurs when it is released simultaneously with all higher-priority tasks. q.e.d.
Schedulability is checked at the critical instants.
If all tasks of a task set are schedulable at their critical instants, they are schedulable at all release times.
Observation helps designing examples
- 38 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Properties of RM scheduling
RM scheduling is based on static priorities. This allows RM scheduling to be used in standard OS, such as Windows NT.
No idle capacity is needed if i: pi+1=F pi:
i.e. if the period of each task is a multiple of the period of the next higher priority task, schedulability is then also guaranteed if µ 1.
A huge number of variations of RM scheduling exists.
In the context of RM scheduling, many formal proofs exist.
- 39 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Summary
Mapping of applications to platforms Scheduling algorithms for aperiodic task sets
• Earliest Due Date (EDD)• Earliest Deadline First (EDF)• Least Laxity (LL)• Latest Deadline First (LDF)
Scheduling algorithms for periodic task sets• rate monotonic scheduling (RMS)
- 40 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Coffee/tea break (if on schedule)
Q&A?
- 41 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Schedule of the course
Time Monday Tuesday Wednesday Thursday Friday
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 Brief break Brief break Brief break
11:15-12:30
6: Lab*: Ptolemy
10: Lab*: Scheduling
14: Lab*: Mem. opt.
18: Lab*: Mem. opt.
12:30 Lunch Lunch Lunch Lunch Lunch
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:20 Break Break Break Break Break
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
- 42 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
EDF
EDF can also be applied to periodic scheduling.
EDF optimal for every period
Optimal for periodic scheduling
EDF must be able to schedule the example in which RMS failed.
- 43 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Comparison EDF/RMS
RMS:
EDF:EDF:
T2 not preempted, due to its earlier deadline.
EDF-animation
- 44 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
EDF: Properties
EDF requires dynamic priorities
EDF cannot be used with a standard operating system just providing static priorities.
- 45 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Comparison RMS/EDF
RMS EDF
Priorities Static Dynamic
Works with std. OS with fixed priorities
Yes No
Uses full computational power of processor
No,just up till µ=n(21/n-1)
Yes
Possible to exploit full computational power of processor without provisioning for slack
No Yes
- 46 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Sporadic tasks
If sporadic tasks were connected to interrupts, the execution
time of other tasks would become very unpredictable.
Introduction of a sporadic task server,periodically checking for ready sporadic tasks;
Sporadic tasks are essentially turned into periodic tasks.
- 47 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Resource access protocols
Critical sections: sections of code at whichexclusive access to some resource must be guaranteed.Can be guaranteed with semaphores S or “mutexes”.
P(S)
V(S)
P(S)
V(S)
P(S) checks semaphore to see if resource is available and if yes, sets S to “used“. Uninterruptible operations!If no, calling task has to wait.
V(S): sets S to “unused“ and starts sleeping task (if any).
Mutually exclusiveaccessto resourceguarded byS
Task 1 Task 2
- 48 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Priority inversion
Priority T1 assumed to be > than priority of T2.If T2 requests exclusive access first (at t0), T1 has to wait until T2 releases the resource (time t3), thus inverting the priority:
In this example:duration of inversion bounded by length of critical section of T2.
- 49 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Duration of priority inversion with >2 taskscan exceed the length of any critical section
Priority of T1 > priority of T2 > priority of T3.T2 preempts T3:T2 can prevent T3 from releasing the resource.
critical sectionnormal execution
- 50 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Solutions
Disallow preemption during the execution of all critical sections.
Simple, but creates unnecessary blocking as unrelated tasks may be blocked.
© L. Thiele, ETH Zürich, 2006
T3
T2
T1
T1 blocked
critical sectionnormal execution
- 51 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
The MARS Pathfinder problem (1)
“But a few days into the mission, not long after Pathfinder started gathering meteorological data, the spacecraft began experiencing total system resets, each resulting in losses of data.The press reported these failures in terms such as "software glitches" and "the computer was trying to do too many things at once".” …
- 52 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
The MARS Pathfinder problem (2)
“Pathfinder contained an "information bus", …a shared memory area used for passing information between different components of the spacecraft.”
A bus management task ran frequently with high priority to move certain kinds of data in and out of the information bus. Access to the bus was synchronized with mutual exclusion locks (mutexes).”
The meteorological data gathering task ran as an infrequent, low priority thread, … When publishing its data, it would acquire a mutex, do writes to the bus, and release the mutex. ..
The spacecraft also contained a communications task that ran with medium priority.”
High priority: retrieval of data from shared memoryMedium priority: communications taskLow priority: thread collecting meteorological data
- 53 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Coping with priority inversion:the priority inheritance protocol
Tasks are scheduled according to their active priorities. Tasks with the same priorities are scheduled FCFS.
If task T1 executes P(S) & exclusive access granted to T2: T1 will become blocked.If priority(T2) < priority(T1): T2 inherits the priority of T1. T2 resumes. Rule: tasks inherit the highest priority of tasks blocked by it.
When T2 executes V(S), its priority is decreased to the highest priority of the tasks blocked by it.If no other task blocked by T2: priority(T2):= original value. Highest priority task so far blocked on S is resumed.
Transitive: if T2 blocks T1 and T1 blocks T0,then T2 inherits the priority of T0.
- 54 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Example
T3 inherits the priority of T1 and
T3 resumes.
How would priority inheritance affect our example with 3 tasks?
V(S)
- 55 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Priority Inheritance Protocol (PIP)
Example with nested critical sections
© L. Thiele, ETH Zürich, 2006
T1
T3
T2
p3
a
critical sectionnormal execution
b
P(a) P(b)
b
P(b)
P(a)
b
V(b)
a
V(a)
a
t1 t2 t3
P3
P2
P1
V(a)
V(b)
b
- 56 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Priority Inheritance Protocol (PIP)
Example of transitive priority inheritance:
© L. Thiele, ETH Zürich, 2006Source: G. Buttazzo
T1
T3
T2
p3
bP(b)
P(b)P(a)
P(a)
bV(b)
bV(a)
a
t1 t2 t3
P3
P2
P1
V(a)
V(b)a a
b
T1 blocked by T2, T2 blocked by T3
T3 inherits priority from T1 via T2
critical sectionnormal execution
- 57 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Priority Inheritance Protocol (PIP)
Problem: Deadlock
critical sectionnormal execution
b
a
b
P(a)
P(b)
P(b)
P(a)
T1
T2
P(a)
P(a)P(b)
P(b)
V(a)
V(a)V(b)
V(b)
T1 T2……
……
© L. Thiele, ETH Zürich, 2006Source: G. Buttazzo
- 58 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Priority inversion on Mars
Priority inheritance also solved the Mars Pathfinder problem: the VxWorks operating system used in the pathfinder implements a flag for the calls to mutex primitives. This flag allows priority inheritance to be set to “on”. When the software was shipped, it was set to “off”.
The problem on Mars was corrected by using the debugging facilities of VxWorks to change the flag to “on”, while the Pathfinder was already on the Mars
[Jones, 1997]
- 59 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Remarks on priority inheritance protocol
Possible large number of tasks with high priority.
Possible deadlocks.
Ongoing debate about problems with the protocol:
Victor Yodaiken: Against Priority Inheritance,http://www.fsmlabs.com/articles/inherit/inherit.html
Finds application in ADA: During rendez-vous,task priority is set to the maximum.
More sophisticated protocol: priority ceiling protocol.
- 60 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Impact on access methods for remote objects
Software packages for access to remote objects;Example: CORBA (Common Object Request Broker Architecture).Information sent to Object Request Broker (ORB) via local stub. ORB determines location to be accessed and sends information via the IIOP I/O protocol.
Access times not predictable.
- 61 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Real-time (RT-) CORBA
A very essential feature of RT-CORBA is to provide end-to-end predictability of timeliness in a fixed priority
system. This involves respecting thread priorities between client
and server for resolving resource contention, and bounding the latencies of operation invocations. Thread priorities might not be respected when threads
obtain mutually exclusive access to resources RT-CORBA includes provisions for bounding the time
during which such priority inversion can happen. Priority management for primitives for mutually exclusive
access to resources. Priority inheritance protocol must be available in implementations of RT-CORBA.
- 62 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Classes of mapping algorithmsconsidered in this course
Classical scheduling algorithmsMostly for independent tasks & ignoring communication, mostly for mono- and homogeneous multiprocessors
Resource access protocols Dependent tasks as considered in architectural
synthesisInitially designed in different context, but applicable
Hardware/software partitioningDependent tasks, heterogeneous systems,focus on resource assignment
Design space exploration using genetic algorithmsHeterogeneous systems, incl. communication modeling
- 63 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Classification of Scheduling Problems
Scheduling
Independent Tasks
RMS, EDF, LLF
Dependent Tasks
Resource constrained
Time constrained
Uncon-strained
ASAP,ALAPFDSLS
1 Proc.
LDF
- 64 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Dependent tasks
The problem of deciding whether or not a schedule existsfor a set of dependent tasks and a given deadlineis NP-complete in general [Garey/Johnson].
Strategies:
1. Add resources, so that scheduling becomes easier
2. Split problem into static and dynamic part so that only a minimum of decisions need to be taken at run-time.
3. Use scheduling algorithms from high-level synthesis
- 65 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Taskgraph
Assumption: execution time = 1for all tasks
a
b c d e f g
h i j
k l m
n
z
- 66 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
As soon as possible (ASAP) scheduling
ASAP: All tasks are scheduled as early as possible
Loop over (integer) time steps: Compute the set of unscheduled tasks for which all
predecessors have finished their computation Schedule a selected subset of these tasks to start at the
current time step.
- 67 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
As soon as possible (ASAP) scheduling: Example
=0
=2
=3
=4
=5
a
b c d e f g
h i j
k l m
n
z
=1
- 68 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
As-late-as-possible (ALAP) scheduling
ALAP: All tasks are scheduled as late as possible
Start at last time step*:
Schedule tasks with no successors and tasks for which all successors have already been scheduled.
* Generate a list, starting at its end
- 69 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
As-late-as-possible (ALAP) scheduling: Example
=0
=2
=3
=4
=5Start
a
b c d e f g
h i j
k l m
n
z
=1
- 70 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
(Resource constrained) List Scheduling
List scheduling: extension of ALAP/ASAP method
Preparation:
Topological sort of task graph G=(V,E)
Computation of priority of each task:
Possible priorities u:
• Number of successors
• Longest path
• Mobility = (ALAP schedule)- (ASAP schedule)
Source: Teich: Dig. HW/SW Systeme
- 71 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Mobility as a priority function
urgent
less urgent
Mobility is not very precise
=1
=2
=3
=4
=5
=1
=2
=3
=4
=5
a
b c d e f g
h i j
k l m
n
z
=0
a
b c d e f g
h i j
k l m
n
z
=0
- 72 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Algorithm
List(G(V,E), B, u){i:=0; repeat { Compute set of candidate tasks Ai ; Compute set of not terminated tasks Gi ; Select Si Ai of maximum priority r such that |Si| + |Gi| ≤ B (*resource constraint*) foreach (vj Si): (vj):=i; (*set start time*) i:=i+1; } until (all nodes are scheduled); return ();}
Complexity: O(|V|)
may be repeated for different task/ processor classes
- 73 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Example
Assuming B=2, unit execution time and u: path length
u(a)=u(b)=4u(c)=u(f)=3u(d)=u(g)=u(h)=u(j)=2u(e)=u(i)=u(k)=1i: Gi=0
a b
i
c f
g
h j
k
d
ea b
c
f
g
d
e
h
i
j
k
=0
=1
=2
=3
=4
=5
Modified example based on J. Teich
- 74 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
(Time constrained) Force-directed scheduling
Goal: balanced utilization of resourcesBased on spring model;Originally proposed for high-level synthesis
* [Pierre G. Paulin, J.P. Knight, Force-directed scheduling in automatic data path synthesis, Design Automation Conference (DAC), 1987, S. 195-202]
© ACM
- 75 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Phase 1: Generation of ASAP and ALAP Schedule
=1
=2
=3
=4
=5
=1
=2
=3
=4
=5
a
b c d e f g
h i j
k l m
n
z
=0
a
b c d e f g
h i j
k l m
n
z
=0
- 76 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Phase 2: Compution of Distribution Graphs D(i)
R(j)={ (ASAP(j)) .. (ALAP(j)) }
=1
=2
=3
=4
=5
=1
=2
=3
=4
=5
a
b c d e f g
h i j
k l m
n
z
=0
a
b c d e f g
h i j
k l m
n
z
=0
0
1
2
3
4
5
2 31 4 5
otherwise
if
:0
)(1
,jRi
|R(j)|ijP
i
j
ijPiD ),()(
- 77 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Next: computation of “forces”
Direct forces push each task into the direction of lower values of D(i). Impact of direct forces on dependent tasks taken into account by
indirect forces Balanced resource usage smallest forces For our simple example and time constraint=6:
result = ALAP schedule
0
1
2
3
4
5
2 31 4 5
i
=1
=2
=3
=4
=5
a
b c d e f g
h i j
k l m
n
z
=0
- 78 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Overall approach
procedure forceDirectedScheduling;begin
AsapScheduling;AlapScheduling;while not all tasks scheduled do
beginselect task T with smallest total force;schedule task T at time step minimizing forces;recompute forces;
end;end
May be repeated for different task/ processor classes
Not sufficient for today's complex, heterogeneous hardware platforms
- 79 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Trend: multiprocessor systems-on-a-chip (MPSoCs)
http
://w
ww
.mps
oc-f
orum
.org
/200
7/sl
ides
/Hat
tori.
- 80 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Multiprocessor systems-on-a-chip (MPSoCs) (2)
http
://w
ww
.mps
oc-f
orum
.org
/200
7/sl
ides
/Hat
tori.
- 81 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Multiprocessor systems-on-a-chip (MPSoCs) (3)
http
://w
ww
.mps
oc-f
orum
.org
/200
7/sl
ides
/Hat
tori.
- 82 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Multiprocessor systems-on-a-chip (MPSoCs) (4)
http
://w
ww
.mps
oc-f
orum
.org
/200
7/sl
ides
/Hat
tori.
- 83 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Multiprocessor systems-on-a-chip (MPSoCs) (5)
http
://w
ww
.mps
oc-f
orum
.org
/200
7/sl
ides
/Hat
tori.
- 84 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Summary
Mapping of applications to platforms Scheduling algorithms for periodic task sets
• Earliest Deadline First (EDF) Preemptive scheduling + mutexes Priority inversion
The priority inheritance protocol (PIP) reduces problems.However, PIP adds to the complexity.Better avoid this effect altogether (e.g. by using a DF MoC).
Scheduling for dependent task sets• ASAP, ALAP, list scheduling, force directed scheduling
Architectures of Multiprocessor Systems on a Chip (MPSoCs)
- 85 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Questions (if on schedule)?
Q&A?
- 86 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Schedule of the course
Time Monday Tuesday Wednesday Thursday Friday
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 Brief break Brief break Brief break
11:15-12:30
6: Lab*: Ptolemy
10: Lab*: Scheduling
14: Lab*: Mem. opt.
18: Lab*: Mem. opt.
12:30 Lunch Lunch Lunch Lunch Lunch
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:20 Break Break Break Break Break
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
- 87 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Hardware/software partitioning
Functionality to be implemented in software or in hardware?
Need to consider special purpose hardware in the long run?“No”, for fixed functionality, but “yes” in general, since“By the time MPEG-n can be implemented in software, MPEG-n+1 has been invented” [de Man]
- 88 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Hardware/software partitioning: approach
[Niemann, Hardware/Software Co-Design for Data Flow Dominated Embedded Systems, Kluwer Academic Publishers, 1998 (Comprehensive mathematical model)]
Processor P1
Processor P2 Hardware
Specification
Mapping
Inputs to COOL:1. Target technology2. Design constraints3. Required behavior
- 89 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Steps of the COOL partitioning algorithm (1)
1. Translation of the behavior into an internal graph model
2. Translation of the behavior of each node from VHDL into C
3. Compilation• All C programs compiled for the target processor,• Computation of the resulting program size, • estimation of the resulting execution time
(simulation input data might be required) 4. Synthesis of hardware components:
leaf nodes, application-specific hardware is synthesized. High-level synthesis sufficiently fast.
- 90 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Steps of the COOL partitioning algorithm (2)
5. Flattening of the hierarchy:
• Granularity used by the designer is maintained.
• Cost and performance information added to the nodes.
• Precise information required for partitioning is pre-computed
6. Generating and solving a mathematical model of the optimization problem:
• Integer programming IP model for optimization.Optimal with respect to the cost function(approximates communication time)
- 91 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Steps of the COOL partitioning algorithm (3)
7. Iterative improvements: Adjacent nodes mapped to the same hardware component are now merged.
8. Interface synthesis: After partitioning, the glue logic required for interfacing processors, application-specific hardware and memories is created.
- 92 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
An integer linear programming modelfor HW/SW partitioning
Notation:
Index set I denotes task graph nodes.
Index set L denotes task graph node typese.g. square root, DCT or FFT
Index set KH denotes hardware component types.e.g. hardware components for the DCT or the FFT.
Index set J of hardware component instances
Index set KP denotes processors.All processors are assumed to be of the same type
- 93 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
An ILP model for HW/SW partitioning
Xi,k: =1 if node vi is mapped to hardware component type
k KH and 0 otherwise.
Yi,k: =1 if node vi is mapped to processor k KP and 0
otherwise.
NY ℓ,k =1 if at least one node of type ℓ is mapped to
processor k KP and 0 otherwise.
T is a mapping from task graph nodes to their types:T: I L
The cost function accumulates the cost of hardware units:
C = cost(processors) + cost(memories) + cost(application specific hardware)
- 94 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Constraints
Operation assignment constraints
KHk KPk
kiki YXIi 1: ,,
All task graph nodes have to be mapped either in software or in hardware.
Variables are assumed to be integers.
Additional constraints to guarantee they are either 0 or 1:
1:: , kiXKHkIi
1:: , kiYKPkIi
- 95 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Operation assignment constraints (2)
ℓ L, i:T(vi)=cℓ, k KP: NY ℓ,k Yi,k
For all types ℓ of operations and for all nodes i of this type:if i is mapped to some processor k, then that processor must implement the functionality of ℓ.
Decision variables must also be 0/1 variables:
ℓ L, k KP: NY ℓ,k 1.
- 96 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Scheduling
Processorp1 ASIC h1
FIR1 FIR2
v1 v2 v3 v4
v9 v10
v11
v5 v6 v7 v8
e3 e4
t
p1
v8 v7
v7 v8
or
...
... ...
...
t
c1
or
...
... ...
...e3
e3
e4
e4t
FIR2 on h1
v4 v3
v3 v4
or
...
... ...
...
Communication channel c1
- 97 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Scheduling / precedence constraints
For all nodes vi1 and vi2 that are potentially mapped to the same processor or hardware component instance, introduce a binary decision variable bi1,i2 withbi1,i2=1 if vi1 is executed before vi2 and
= 0 otherwise.Define constraints of the type(end-time of vi1) (start time of vi2) if bi1,i2=1 and(end-time of vi2) (start time of vi1) if bi1,i2=0
Ensure that the schedule for executing operations is consistent with the precedence constraints in the task graph.
Approach just fixes the order of execution and avoids the complexity of computing start times during optimization.
- 98 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Example
HW types H1, H2 and H3 with costs of 20, 25, and 30.
Processors of type P.Tasks T1 to T5.Execution times:
T H1 H2 H3 P
1 20 100
2 20 100
3 12 10
4 12 10
5 20 100
- 99 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Operation assignment constraints (1)
T H1 H2 H3 P
1 20 100
2 20 100
3 12 10
4 12 10
5 20 100
X1,1+Y1,1=1 (task 1 mapped to H1 or to P)X2,2+Y2,1=1X3,3+Y3,1=1X4,3+Y4,1=1X5,1+Y5,1=1
KHk KPk
kiki YXIi 1: ,,
- 100 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Operation assignment constraints (2)
Assume types of tasks are ℓ =1, 2, 3, 3, and 1.
ℓ L, i:T(vi)=cℓ, k KP: NYℓ,k Yi,k
Functionality 3 to be implemented on
processor if node 4 is mapped to it.
- 101 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Other equations
Time constraints leading to: Application specific hardware required for time constraints under 100 time units.
T H1 H2 H3 P
1 20 100
2 20 100
3 12 10
4 12 10
5 20 100
Cost function:C=20 #(H1) + 25 #(H2) + 30 # (H3) + cost(processor) + cost(memory)
- 102 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Result
For a time constraint of 100 time units and cost(P)<cost(H3):
T H1 H2 H3 P
1 20 100
2 20 100
3 12 10
4 12 10
5 20 100
Solution (educated guessing) :T1 H1T2 H2T3 PT4 PT5 H1
- 103 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Application example
Audio lab (mixer, fader, echo, equalizer,balance units); slow SPARC processor1µ ASIC libraryAllowable delay of 22.675 µs (~ 44.1 kHz)
SPARCprocessor
ASIC(Compass,1 µ)
External memory
Outdated technology; just a proof of concept.
- 104 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Design space for audio lab
Everything in software: 72.9 µs, 0 2 Everything in hardware: 3.06 µs, 457.9x106 2
Lowest cost for given sample rate: 18.6 µs, 78.4x106 2,
- 105 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
HW/SW partitioningin the context of mapping applications to processors
Handling of heterogeneous systems
Handling of task dependencies
Considers of communication (at least in COOL)
Considers memory sizes etc (at least in COOL)
For COOL: just homogeneous processors
No link to scheduling theory
Still handles just a single processor type
- 106 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Survey of Mapping Techniques
1st Workshop on Mapping ApplicationsTo MPSoCs, Rheinfels castle, June, 2008Information: http://www.artist-embedded.org/artist/-Mapping-of-Applications-to-MPSoCs-.html
Automatic parallelization of C-code(see talk by Heiko Falk)
Work at ETH Zürich (SPEA2, Lothar Thiele)
Work at RWTH Aachen (MAPS, Leupers)
Work at Leiden University (Daedalus, Ed Deprettere)
Mapping to the CELL processor (U. Bologna and others)
Work at IMEC (D. Verkest)
- 107 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Daedalus Design-flow
System-level synthesis
Library ofIP cores
Platform specification
Sequentialapplication
Parallel application specification
AutomaticParallelization
High-levelModels
Mappingspecification
System-level design space exploration
Explore, modify, select instances
Multi-processor System on Chip(Synthesizable VHDL and C/C++ code for processors)
RTL-levelModels
Common XMLInterface
Library ofIP cores
KPNgenSesame
ESPAM
Xilinx Platform Studio (XPS)
RTL-LevelSpecification
System-LevelSpecification
Synthesizable VHDL
C/C++ code for processors
MP-SoC
Kahn Process Network
Sequentialapplication
© E. Deprettere,U. Leiden
- 108 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Example architecture instances for a single-tile JPEG encoder:
JPEG/JPEG200 case study
2 MicroBlaze processors (50KB) 1 MicroBlaze, 1HW DCT (36KB)
6 MicroBlaze processors (120KB) 4 MicroBlaze, 2HW DCT (68KB)
Vin
8KB
4x2KB
4x2KB
4x16KB
32KB
16KB 32KB2KB
32KB
2KB
2KB 2KB
2KB2KB 2KB
8KB
8KB
8KB
32KB 4KB
VLE, Vout
DCT, Q
DCT, Q
DCT, Q
DCT, Q
Vin,DCT Q,VLE,Vout Vin,Q,VLE,Vout
Vin
Q
Q
VLE, Vout
DCT
DCT
DCT
© E. Deprettere,U. Leiden
- 109 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Sesame DSE results: Single JPEG encoder DSE
© E. Deprettere,U. Leiden
- 110 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Work at ZürichMapping Scenario: Overview
Given1. specification of the task structure (task model) = for each flow the
corresponding tasks to be executed2. different usage scenarios (flow model)
Soughtprocessor implementation (resource model) =
architecture* + task mapping + schedulingObjectives:
1. maximize performance2. minimize cost
Subject to:1. memory constraints2. delay constraints
*: 2 cases:1. fixed architecture2. architecture to be designed
based on Thiele’s slides
(performance model)
- 111 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Design Space
Scheduling/Arbitration
proportionalshareWFQ
staticdynamicfixed priority
EDFTDMA
FCFS
Communication Templates
Architecture # 1 Architecture # 2
Computation Templates
DSP
E
Cipher
SDRAMRISC
FPGA
LookUp
DSP
TDMA
Priority
EDF
WFQ
RISC
DSP
LookUp
Cipher
E E E
E E E
static
Which architecture is better suited for our application?
© L. Thiele, ETHZ
- 112 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Application Model
Example of a simple stream processing task structure:
© L. Thiele, ETHZ
- 113 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Practical problem in automotive design
Which processor should run the software?
- 114 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 115 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 116 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 117 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 118 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 119 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 120 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Exploration Cycle
EXPO – Tool architecture (1)
MOSES
EXPO SPEA 2
selectionof “good” architectures
system architectureperformance values
task graph, scenario graph,
flows & resources
© L. Thiele, ETHZ
- 121 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
SYMTA/S: System optimization using evolutionary algorithms
[R. Ernst et al.: A framework for modular analysis and exploration of
heteterogenous embedded systems, Real-time Systems, 2006, p. 124]
- 122 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 123 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 124 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 125 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 126 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 127 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
© L. Thiele, ETHZ
- 128 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Results
Performance for encryption/decryptio
n
Performance forRT voice processing
© L. Thiele, ETHZ
- 129 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Summary
Mapping applications for complex heterogeneous multiprocessor platforms needs
allocation (if hardware is not fixed)
binding of tasks to resources
scheduling
Approaches presented
HW/SW codesign tool COOL
Daedalus (briefly)
Symta/S (briefly)
SPEA2: Evolutionary algorithms in use at ETH Zürich
- 130 -technische universitätdortmund
fakultät für informatik
p. marwedel, informatik 12, 2008
TU Dortmund
Brief break (if on schedule)
Q&A?
Top Related