��������������� ����������������������������������������������������� !���"�#��"�������������������$�%�����&� !'����� (��%�������"�� Designing a real-time system Parallel & Distributed What should be done & Real-Time Systems New design! When should it be done? Specification How should it be done? Lecture #2 Implementation Risat Pathan Can it be done with the given implementation? Department of Computer Science and Engineering Verification Chalmers University of Technology Verification Verification Since timeliness is such an important characteristic of a What is needed for formal verification? real-time system: how do we verify that the timing • A good timing model constraints are met for a given system implementation? Enables expressing the timing properties of the application in a syntactically unambiguous way Enables timing constraints to be reflected at all design levels: from specification level (end-to-end constraints) to implementation level • A good schedulability analysis Enables prediction of required processing capacity, e.g. # and … so we don’t miss that speed of processors, of the hardware (when software is known) hard deadline … … so we don’t miss too Enables prediction of required resource usage from the software … while we at the same time many soft deadlines … (when hardware implementation is known) avoid analyzing all possible software execution scenarios �
��������������� ����������������������������������������������������� !���"�#��"�������������������$�%�����&� !'����� (��%�������"�� Verification Verification What sources of uncertainty exist in formal verification? How do we simplify formal verification? • Non-determinism in tasks’ WCET (undisturbed execution) • Concurrent and reactive programming paradigm – Input data and internal state controls execution paths – Suitable schedulable unit of concurrency (task, thread, …) – Memory access patterns control delays in processor – Language constructs for expressing application constraints architecture (pipelines and cache memories) for schedulable unit (priorities, delays, …) – WCET must be derivable for schedulable unit (special caution • Non-determinism in tasks’ execution interference with usage of dynamic language constructs) (pseudo-parallel execution) • Deterministic task execution – Run-time execution model controls interference pattern – Time tables or static/dynamic task priorities • Conflicts in tasks’ demands for shared resources – Preemptive task execution – (Pseudo-)parallel task execution may give rise to uncontrolled – Run-time protocols for access to shared resources (dynamic blocking of shared hardware and software resources priority adjustment and non-preemptable code sections) Verification Task model How do we perform schedulability analysis? Implementation Abstract model • Introduce abstract models of system components: – Task model (computation requirements, timing constraints) – Processor model (resource capacities) void task1(Object *self, int p) { Action1(); SEND(Period1, Deadline1, self, task1, p); – Run-time model (task states, dispatching) } { } τ = C T D O , , , τ void task2(Object *self, int p) { • Predict whether task executions will meet constraints 1 1 1 1 1 1 Action2(); SEND(Period2, Deadline2, self, task2, p); } – Use abstract system models void kickoff(Object *self, int p) { AFTER(Offset1, &app1, p); – Make sure that computation requirements never exceed AFTER(Offset2, &app2, p); } τ { } resource capacities τ = C T D O , , , 2 2 2 2 2 2 main() { – Generate (partly or completely) run-time schedule resulting TINYTIMBER(&app_main, kickoff, 0); } from task executions and detect worst-case scenarios �
��������������� ����������������������������������������������������� !���"�#��"�������������������$�%�����&� !'����� (��%�������"�� Task model Task model The task model expresses the timing behavior of a task: Static task parameters: C i : (undisturbed) WCET T period : • The static parameters describe characteristics of a task i D i : (relative) deadline { } that apply independent of other tasks. τ i = C i , T i , D i , O i τ i O i : (absolute) time offset – Derived from the specification or implementation of the system – For example: period, deadline, WCET • The dynamic parameters describe effects that occur D i during the execution of the task. – Is a function of the run-time system and the characteristics 0 of other tasks t – For example: start time, completion time, response time C i O i T i Task model Task model Dynamic task parameters: Different types of tasks: a i , k : arrival time of k th instance s i , k : start time of k th instance • Periodic tasks { } f i , k : completion time of k th instance τ i = C i , T i , D i , O i τ – A periodic task arrives with a time interval T i i R i , k : response time of k th instance • Sporadic tasks th instance of τ i τ i , k : the k – A sporadic task arrives with a time interval ≥ T i • Aperiodic tasks τ τ τ i ,1 i ,2 i ,3 – An aperiodic task has no guaranteed minimum time between 0 t two subsequent arrivals s i , k f i , k � A priori schedulable real-time systems can only contain a i , k = O i + ( k − 1) ⋅ T i R i , k = f i , k − a i , k periodic and sporadic tasks. a i , k R i , k { } R i = max τ i ∈ T , k ≥ 1 R i , k (worst-case response time) #
��������������� ����������������������������������������������������� !���"�#��"�������������������$�%�����&� !'����� (��%�������"�� Processor model Run-time model Homogeneous processors: Task states: • Waiting • Identical processors – Task has not yet arrived for the first time, or has finished – WCET is a constant executing but not re-arrived • Ready Heterogeneous processors: – Task has arrived and can potentially execute on the processor • Uniform processors (kept waiting in a ready queue) • Running – WCET is the product of a basic execution time and a – Task is currently executing on the processor scaling factor Dispatcher: • Unrelated processors • A run-time mechanism that takes the first element (task) – WCET is not related for different processors in the ready queue and executes it on the processor. Evaluating a real-time system Evaluating a real-time system How do we measure and compare performance? An important part of real-time system design is to • Quantify system performance have techniques that generate good schedules. – Choose useful performance measures (metrics) • Perform objective performance analysis τ 1 – Choose suitable evaluation methodology – Examples: theoretical and/or experimental analysis τ 2 • Compare performance of different designs – Make trade-off analysis using chosen performance measures 0 5 10 15 20 25 t • Identify fundamental performance limitations – Find “bottleneck” mechanisms that affect performance Is this a good schedule? What do we need to decide the quality? �
Recommend
More recommend
