120 likes | 249 Views
3rd International Real-Time Scheduling Open Problems Seminar. Undoing the Task: Moving Timing Analysis back to Functional Models. Marco Di Natale, Haibo Zeng Scuola Superiore S. Anna – Pisa, Italy McGill University – Montreal, Canada. Model-based Design.
E N D
3rd International Real-Time Scheduling Open Problems Seminar Undoing the Task: Moving Timing Analysis back to Functional Models Marco Di Natale, Haibo Zeng Scuola Superiore S. Anna – Pisa, Italy McGill University – Montreal, Canada
Model-based Design • Popular in many application domains of real-time systems • Automotive • Avionics • To deal with complexity • Model everything for design (engineering) and analysis (science) • It is necessary to select a modeling language in the most natural and easy way • The four tenets on the right are fundamental to model-based design • No program by hand • Starting point is functional model • Automatic generation of implementation is key • Synthesis of tasks, priorities, allocation, communication mechanisms … by Ali Behboodian, DSP Magazine Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng
Undoing the Task Real-time research has been looking at ways to look inside the task and find smaller granularity entities and/or models for conditional execution. • Examples: • Task graphs (see left) • Identify a task segment to be managed without preemption (see [1]) • Identify a task segment to be executed at a different priority level (see [2]) • … • [1] M. Bertogna, G. Buttazzo, and G. Yao, “Improving feasibility of fixed priority tasks using non-preemptive regions”, RTSS 2011 • [2] R. Davis and A. Wellings, “Dual Priority Scheduling” RTSS, 1995. Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng
Synchronous Models: Simulink/Stateflow • Synchronous FSMs are used in the most popular model-based design tools • SCADE • Simulink/Stateflow e1=2ms e2=5ms e1/{action1();o1} i1 o1 S1 0.25 i2 o2 e2/{action2();o2} e1/{action3();o1} 2 S2 0.3 0.1 1 in om S3 e2/{action4();o2} 0.15 The system is a network of “dataflow” blocks and Stateflow (EFSM) blocks Where are the tasks? Timing constraints? Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng
Problem Statement: Input System is a network of blocksbj of two types Regular (Dataflow): periodTj (an integer multiple of a system-wide base periodTb) inputsij,p. at each kTjoutput and state are updated, with a WCETgj. State machine (Stateflow): can have multiple activation events ej,p. at any multiple of the event periods kTj,p, different transitions may be taken. each update function has a WCET labeled as gj,q Order of execution For two communicating blocks If bj has a feedthrough semantics, then bi → bj This partial order of execution of functions can be enforced by static code scheduling inside the task or by the scheduler This precedence constraint can be avoided by adding a delay bi bj Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng
Problem Statement: Input 3 2 1 0 4 3 2 1 0 2 A A A B C D B B D tv=0: A,B,D,C tv=1:A,B tv=2: A,B,D 4 A Behavior in Simulation T=1 zero logical execution time zero logical communication time C T=4 B D T=2 T=1 2 Order in simulation: A->B->D->C fc(4,2) 4 2 Behavior in Implementation 4 3 2 2 1 0 A A A B B B • The requirement of preserving the behavior in functional model can impose additional constraints • Either tighter deadline for block C • Or other mechanisms (but possibly with memory overhead) D 1 4 fc(4,1)? C C tr=1 tr=0 tr=2 Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng
Problem Statement • Unlike traditional manual programming, in MBD • the task (or threads) model becomes an intermediate artifact • the timing analysis becomes part of a synthesis problem (to facilitate automatic code generation) • Analysis problem • deadline may depends on the function-to-task mapping • additional requirements from the correct implementation of function models • Synthesis problem: • mapping functions into tasks • assigning the execution order of functions inside tasks, • assigning the task parameters (priority, deadline, offset) • assigning scheduling attributes to functions (including preemptability and preemption threshold) • designing communication Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng
Example Open Problem • Given • functional model (composed of multiple communicating state machine blocks and dataflow blocks) • a multicore platform as the implementation architecture • Find • mapping of state machine actions and block reactions onto tasks • placement of tasks onto the cores • assignment of task activation offsets and priorities • Such that • functional model semantics are preserved • each block finish in time for the follower blocks Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng
Example Open Problem II • Given • functional model (composed of multiple communicating state machine blocks and dataflow blocks) • a multicore platform as the implementation architecture • Find • mapping of state machine actions and block reactions onto tasks • placement of tasks onto the cores • assignment of task activation offsets and priorities • assignment of preemption thresholds to actions inside the tasks • Such that • functional model semantics are preserved • each block finish in time for the follower blocks • memory usage is minimized Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng
Thank you! Initial discussion on the example problems [3] M. Di Natale and H. Zeng, “Task implementation of synchronous finite state machines,” in Proc. the Conference on Design, Automation, and Test in Europe, 2012. [4] H. Zeng and M. Di Natale, “Schedulability Analysis of Periodic Tasks Implementing Synchronous Finite State Machines,” in Proc. 23rd Euromicro Conference on Real-Time Systems, 2012. Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng
Baseline (Single-Task) Implementation The generated code runs in the context of a 1 ms task (gcd), but reactions do not occur every 1ms e1=2ms e2=5ms e1/{action1();o1} A single task forces the execution of all the actions at the same priority level i1 o1 S1 0.25 i2 o2 e2/{action2();o2} e1/{action3();o1} 2 S2 0.3 0.1 1 in om S3 e2/{action4();o2} 0.15 Simple periodic model: Worst-case exec time of a reaction to any event – deadline at 1ms – quite pessimistic Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng
Partitioned (Multi-task) Implementation Applicable if the priority of a transition is determined by the corresponding event e1=2ms e2=5ms e1/{action1();o1} i1 o1 S1 0.25 o2 i2 e2/{action2();o2} e1/{action3();o1} 2 S2 0.3 0.1 • One task for each event rate. • Priority of transitions is handled by task priorities • Single reaction execution by an “inhibit signal” • Atomicity (state consistency) by deadlines. 1 in om S3 e2/{action4();o2} 0.15 e1=2ms e2=5ms Undoing the Task: Moving Timing Analysis back to Functional Models M. Di Natale, H. Zeng