Real-Time Systems. Real-Time Systems. Verification by testing. Verification by testing

Transcription

1 EDA222/DIT161 Real-Tme Systems, Chalmers/GU, 2014/2015 Lecture #8 Real-Tme Systems Real-Tme Systems Lecture #8 Specfcaton Professor Jan Jonsson Implementaton System models Executon-tme analyss Department of Computer Scence and Engneerng Chalmers Unversty of Technology Verfcaton Verfcaton by testng Verfcaton by testng Congratulatons, Bulder Bob! It seems to be strong enough ths tme. Let s open the brdge. Dad? How do they know how much weght a brdge can handle? They drve bgger and bgger trucks over the brdge untl t collapses! Then they take the weght of the last truck and rebuld the brdge Oh, I guess I should have known that! Honey, f you don't know the answer, just SAY so! So, s ths how brdges (or other mechancal constructons) are bult? Free translaton from Swedsh by J. Jonsson Of course not! There are models (propertes of materals) and theores (laws of mechancs) nvolved to determne n advance that a constructon wll wthstand the predcted load. 1

2 EDA222/DIT161 Real-Tme Systems, Chalmers/GU, 2014/2015 Lecture #8 Verfcaton by models & theory Verfcaton How do we perform verfcaton (schedulablty analyss)? So, why cannot computer systems be bult and verfed n advance usng models and theores? Well, they can usng system models and schedulablty analyss Introduce abstract models of system components: (computaton requrements, tmng constrants) Processor model (resource capactes) Run-tme model (task states, dspatchng) Predct whether task executons wll meet constrants Use tmng-correct abstract system models Make sure that computaton requrements never exceed resource capactes Generate a (partal or complete) run-tme schedule resultng from task executons and detect worst-case scenaros Verfcaton Desgnng a real-tme system How do we facltate schedulablty analyss? Concurrent and reactve programmng paradgm Sutable schedulable entty (thread, method, ) Language constructs for expressng applcaton constrants for schedulable enttes (data types, annotatons, macros, ) WCET must be dervable for schedulable enttes (specal cauton wth usage of dynamc language constructs) Determnstc task executon Tme tables or statc/dynamc task prortes Preemptve task executon Run-tme protocols for access to shared resources (dynamc prorty adjustment and non-preemptable code sectons) New desgn! Specfcaton Implementaton Verfcaton What Logcal should functon be done & When Temporal should functon t be done? How System should mplementaton t be done? Can Abstract t be done system wth models the gven Schedulablty mplementaton? analyss 2

3 EDA222/DIT161 Real-Tme Systems, Chalmers/GU, 2014/2015 Lecture #8 Run-tme model The run-tme model expresses the state of a task: Implementaton Abstract model watng sgnal ready wat nterrupt runnng dspatch vod task1(object *self, nt p) { Acton1(); SEND(Perod1, Deadlne1, self, task1, p); vod task2(object *self, nt p) { Acton2(); SEND(Perod2, Deadlne2, self, task2, p); τ 1 τ = { C, T, D, O Runnng: Currently executng task Ready: Task that s avalable for executon Watng: Task that cannot execute because t s needs access to a resource other than the processor vod kckoff(object *self, nt p) { AFTER(Offset1, &app1, p); AFTER(Offset2, &app2, p); man() { TINYTIMBER(&app_man, kckoff, 0); τ 2 τ = { C, T, D, O The task model expresses the tmng behavor of a task: The statc parameters descrbe characterstcs of a task that apply ndependent of other tasks. These parameters are derved from the specfcaton or the mplementaton of the system For example: perod, deadlne, WCET Statc task parameters: τ τ = { C, T, D, O C :(undsturbed) WCET T : perod D :(relatve) deadlne O :(absolute) tme offset The dynamc parameters descrbe effects that occur durng the executon of a task. These parameters are a functon of the run-tme system and the characterstcs of other tasks For example: start tme, completon tme, response tme 0 C D t O T 3

4 EDA222/DIT161 Real-Tme Systems, Chalmers/GU, 2014/2015 Lecture #8 Statc task parameters: C Task s worst-case executon tme (WCET) Represents the longest undsturbed executon tme for one teraton of the task Derved as a functon of the task s program code D Task s relatve deadlne (responsveness constrant) Represents the maxmum allowed tme wthn whch the task must complete ts executon Apples relatve to the tme when the task becomes executable Derved as a functon of the envronment (e.g., laws of nature, control theory,...) Statc task parameters: T Task s perodcty Represents how often the task should be repeated Each teraton of the task has the same WCET O Task s tme offset Represents the frst arrval tme of the task, e.g., the earlest tme nstant at whch the task becomes executable Apples relatve to a gven orgn ( epoch ) of the system The arrval tme of the n:th teraton of a task then becomes A = O + ( n 1) T n Executon-tme analyss Dfferent types of tasks: Perodc tasks A perodc task arrves wth a tme nterval T Sporadc tasks A sporadc task arrves wth a tme nterval T Program (no nput data) Real-tme compler Compler + WCET analyss Code WCET Aperodc tasks An aperodc task has no guaranteed mnmum tme between two subsequent arrvals Hard real-tme systems can only contan perodc and sporadc tasks. for (=1; <=N; ++) { f (A > K) A = K-1; A = K+1; f (A < K) A = K; A = K-1; 42 4

5 EDA222/DIT161 Real-Tme Systems, Chalmers/GU, 2014/2015 Lecture #8 Motvaton: Executon-tme analyss Worst-case executon tme (WCET) s mportant snce t s a prerequste for (hard) schedulablty analyss resource needs should be estmated early n the desgn phase The executon tme of a task depends on program structure + nput data ntal system state temporal propertes of the system (OS + hardware) nternal and external system events Estmaton of WCET should consequently be made whle the program s compled! Requrements: Executon-tme analyss WCET must be pessmstc but tght 0 Estmated WCET Real WCET < ε (ε small compared to real WCET) pessmstc: to make sure assumptons made n the schedulablty analyss of hard real-tme tasks also apply at run tme tght: to avod unnecessary waste of resources durng schedulng of hard real-tme tasks The computatonal complexty of the analyss method must be tractable Executon-tme analyss A smple (yet challengng) example Executon tme Derve WCET for the followng program: estmated WCET real WCET Input data for (=1; <=N; ++) { f (A > K) A = K-1; (T1) A = K+1; (E1) f (A < K) A = K; (T2) A = K-1; (E2) Issues to consder: Input data s unknown Iteraton bounds must be known to facltate analyss Path exploson 4^N paths n ths example Excluson of non-executable (false) paths T1 + E2 s a false path n the example 5

6 EDA222/DIT161 Real-Tme Systems, Chalmers/GU, 2014/2015 Lecture #8 A smpler (but non-trval) example Formulaton of the WCET problem Derve WCET for the followng statement: Issues to consder: A = A / B; Executon tme: affected by cache msses, ppelne conflcts, exceptons... depends on prevous and (!) subsequent nstructons also depends on (unknown) nput data Observatons: accurate estmaton of WCET must be based on a detaled tmng model of the system archtecture uncertantes are handled by makng worst-case assumptons Gven a system (= program structure + system platform) fnd the program s worst-case executon tme for all possble nput data, ntal system states and (nternal and external) system events Fundamental ssues Path analyss Issues n the analyss of program paths how to lmt WCET (f necessary, pessmstcally) how to elmnate false paths (n order to derve a tght WCET estmate) Issues n the analyss of temporal behavor everythng that takes tme must be modeled n a realstc fashon (or at least not optmstcally) accurate and effectve tmng model of the system platform (nfluence of, e.g., cache memores, ppelnng, ) consequences of system events at run tme (e.g.: exceptons, nterrupts, context swtches) A control flow graph (CFG) descrbes the structure of the program Tmng analyss problem: Fnd the longest executable path n the program s CFG CFG may not contan cycles Non-executable paths must be elmnated 6

7 EDA222/DIT161 Real-Tme Systems, Chalmers/GU, 2014/2015 Lecture #8 Path analyss Shaw s Tmng Schema (1989): for (=1; <=N; ++) { f (A > K) A = K-1; (T1) A = K+1; (E1) f (A < K) A = K; (T2) A = K-1; (E2) The estmated WCET (WCETe) s the executon tme of the longest structural path through the program WCETe = N*(WCET(loop) + WCET(I1) + max(wcet(t1), WCET(E1)) + WCET(I2) + max(wcet(t2), WCET(E2))) Methods for path analyss Branches (alternatve paths) ntroduces the followng set of problems: 1. Iteratons (loops, recursons ) 2. Alternatve (f-then-, case ) Goal: Bound the number of teratons n a loop or recurson Elmnate non-executable (false) program paths Methods for path analyss The user annotates the program so that ts CFG only contans a lmted number of executable paths: Annotaton of loop bounds: Provde upper bounds on loop ndces and catch potental exceptons at run tme Elmnaton of false paths: Enumerate all possble paths and lst the set of false paths so that these can be avoded n the analyss Requres very detaled knowledge of the program s functon, but s therefore also very prone to errors! Methods for path analyss Automated method: Statc analyss (embedded n compler): Derve upper bounds on loop ndces requres an explct loop ndex does not always work for complcated termnaton condtons Elmnate false paths symbolcally execute the program and do assert wth respect to the possble values that varables are able to assume Prelmnary methods are promsng but only for farly smple programs where the analyss s trval! 7

8 EDA222/DIT161 Real-Tme Systems, Chalmers/GU, 2014/2015 Lecture #8 Methods for path analyss Tmng analyss for RISC processors The realty? Shaw s tmng schema mplctly assume that the executon tme of each language statement s constant and known Ths s a qute realstc assumpton for a mcro-controller type of processor that lacks ppelned executon lacks cache memores does not generate exceptons However, for the RISC type processor archtectures, these methods yeld very pessmstc results! RISC processors have several advanced mechansms (ppelnng, cachng, branch predcton, out-of-order executon, ) that cause sgnfcant varaton n the executon tme of a processor nstructon. We must therefore estmate the executon tme for each executable path through the program and at the same tme account for these mechansms. Ths can be solved by parttonng the program code nto code blocks and analyze each block separately. Today, mature methods for tmng analyss only exst for ppelnng and cachng. Tmng analyss for RISC processors Tmng analyss of cache memory Processor wth ppelne: IF ID EX M WB ICACHE DCACHE Sources of tme varatons: structural conflcts data conflcts branch conflcts Sources of tme varatons: cache msses Issues: Not enough to nvestgate an solated code block mss/ht depends on prevous executons of the code Instructon cache behavor s predctable for each path known sequence of code Data cache behavor s more dffcult to analyze data addresses can depend on the program s nput data 8

9 EDA222/DIT161 Real-Tme Systems, Chalmers/GU, 2014/2015 Lecture #8 Tmng analyss of ppelne Methods for tmng analyss Issues: Not enough to nvestgate an solated code block conflcts may occur on the boundary between code blocks Ppelne behavor s predctable for each path known sequence of code Extenson of Shaw s Tmng Schema Analyss s performed at code block level Mergng of paths at certan code locatons by estmatng the effects of worst-case stuatons (reduces path exploson) Data flow analyss: Analyss performed at code block level Propagaton of ppelne and cache states between blocks Integer Lnear Programmng Formulate an ILP problem as a functon of executon tme and number of executons at code block level Challenges Challenges So far, non-preemptve executon of program code on a sngle processor has been assumed. In realty, pseudo-parallel executon s typcally used, somethng whch requres preemptve executon. Preemptons wll affect system state (.e., cache contents wll change and ppelne wll be flushed) and must therefore be accounted for n the analyss. However, t s dffcult to account for these effects n the analyss of WCET, whch means that t must be handled at a hgher level (.e., n the schedulablty analyss). So far, non-preemptve schedulng of program code on a sngle processor has been assumed. In realty, multcore processors are used n real-tme systems, somethng whch presents new problems. Several processors may have copes of the same code and data n ther local cache memores, and any updates wll nvaldate the other copes. Ths must be accounted for n the analyss.... 9