Digitale Hardware/ Software-Systeme- P23 ppt

434 7 Software-Verifikation rungsreihenfolge der Instruktionen zu einem bestm ¨ oglichen bzw. schlechtestm ¨ ogli- chen Zeitverhalten f ¨ uhrt. F ¨ ur die Analyse wird angenommen, dass der Prozess den Prozessor exklusiv belegt, der Prozessor lediglich eine skalare Funktionseinheit be- sitzt, keine Interrupts unterst ¨ utzt und kein Betriebssystem auf dem Prozessor aus- gef ¨ uhrt wird. Weiterhin wird angenommen, dass das Programm keine rekursiven Funktionsaufrufe beinhaltet, keine dynamische Speicherallokation durchf ¨ uhrt und die Schleifen im Programm beschr ¨ ankt sind bzw. beschr ¨ ankt werden. Grundlage f ¨ ur die Programmpfadanalyse bildet der Kontrollflussgraph G C =(V C ,E C ) eines Prozes- ses. Die Knoten in dem Kontrollflussgraphen stellen Berechnungen (Grundbl ¨ ocke) dar, w ¨ ahrend Kanten Kontrollflussabh ¨ angigkeiten darstellen. Auf Basis des Kontroll- flussgraphen eines Prozesses l ¨ asst sich die engl. Worst Case Execution Time (WCET) formal definieren: Definition 7.4.1 (WCET). Ein Prozess besteht aus n Grundbl ¨ ocken, wobei jeder Grundblock b i eine Ausf ¨ uhrungszeit δ i hat und maximal x i mal ausgef ¨ uhrt wird. Dann ist die WCET δ max := n ∑ i:=1 δ i · x i (7.6) Somit besteht die Aufgabe der Programmpfadanalyse darin, herauszufinden, wie oft jeder Grundblock auf einem Pfad, der zu einer maximal langen Ausf ¨ uhrungs- zeit geh ¨ ort, ausgef ¨ uhrt wird. Die Bestimmung der BCET kann analog formuliert werden: Wie oft wird jeder Grundblock auf einem Pfad, der zu einer minimalen Ausf ¨ uhrungszeit geh ¨ ort, ausgef ¨ uhrt. Aufgrund dieser Analogie wird im Folgenden lediglich das WCET-Problem weiter betrachtet. Die zentrale Herausforderung bei der Programmpfadanalyse besteht allerdings darin, dass die Anzahl der m ¨ oglichen Ausf ¨ uhrungspfade exponentiell anw ¨ achst. Ohne weitere Beschr ¨ ankungen w ¨ urde Gleichung (7.6) beliebig anwachsen, d. h. δ max →∞. Aus diesem Grund wird die Anzahl der Ausf ¨ uhrungen x i eines Basis- blocks B i beschr ¨ ankt. Dabei werden zwei Arten von Beschr ¨ ankungen unterschieden: 1. Strukturelle Beschr ¨ ankungen ergeben sich aus der Struktur des Kontrollflussgra- phen. 2. Funktionale Beschr ¨ ankungen ergeben sich aus der Spezifikation des Prozesses. Strukturelle Beschr ¨ ankungen werden auch als Flussbeschr ¨ ankungen bezeichnet. Sie besagen, dass jedes Mal, wenn der Kontrollfluss einen Grundblock erreicht, der Kon- trollfluss diesen Grundblock auch wieder verlassen muss. Sei d : E C → Z ≥0 eine Funktion, die jeder Kante e ∈ E C im Kontrollflussgraph G C einen Wert zuweist, der anzeigt, wie oft der Kontrollfluss w ¨ ahrend einer Ausf ¨ uhrung ¨ uber diese Kante gegangen ist. Sei weiterhin in(v) := {e | e =(˜v,v) ∈ E C } die Menge eingehender Kanten in den Kontrollflussknoten v ∈V C und out(v) := {e | e =(v, ˜v) ∈ E C } die Menge ausgehender Kanten. Dann sieht die strukturelle Beschr ¨ ankung f ¨ ur Knoten v i ∈ V C der den Grundblock b i repr ¨ asentiert wie folgt aus: ∑ e j ∈in(v i ) d(e j )= ∑ e k ∈out(v i ) d(e k )=x i (7.7) 7.4 Zeitanalyse 435 Beispiel 7.4.1. Gegeben ist das Programm in Abb. 7.29a) mit dem in Abb. 7.29b) dargestellten Kontrollflussgraphen. Die Flussgleichungen ergeben sich zu: x 1 = d 1 = d 2 x 2 = d 2 + d 8 = d 3 + d 9 x 3 = d 3 = d 4 + d 5 x 4 = d 4 = d 6 x 5 = d 5 = d 7 x 6 = d 6 + d 7 = d 8 x 7 = d 9 = d 10 3 2 1 9 11 b 7 b 6 b 4 b 5 b 3 b 2 b 1 4 6,7 1 2 3 if (ok) else { j++; j=0; ok=true; } k++; } r=j; 4 5 6 7 8 9 10 11 s=k; a) C-Programm while (k<10) { b) CFG: d 1 d 2 d 3 d 4 d 5 d 6 d 7 d 8 d 9 d 10 Abb. 7.29. a) Programm und b) Kontrollflussgraph Obwohl der L ¨ osungsraum durch die Verwendung struktureller Beschr ¨ ankungen eingeschr ¨ ankt ist, k ¨ onnen immer noch unendliche große Ausf ¨ uhrungszeiten ent- stehen. Durch die Verwendung funktionaler Beschr ¨ ankungen wird dies verhindert. Funktionale Beschr ¨ ankungen ergeben sich aus der Spezifikation des Systems oder aus einer Programmanalyse. Funktionale Beschr ¨ ankungen begrenzen somit die An- zahl an Schleifendurchl ¨ aufen. Beispiele f ¨ ur das Programm aus Abb. 7.29 sind: 436 7 Software-Verifikation • Die while-Schleife wird maximal zehnmal durchlaufen: x 3 ≤ 10· x 1 . • Der Grundblock b 5 wird maximal einmal durchlaufen: x 5 ≤ 1. Durch funktionale Beschr ¨ ankungen werden unzul ¨ assige Ausf ¨ uhrungspfade aus der Betrachtung bei der Ermittlung der WCET herausgenommen. Mit Hilfe von strukturellen und funktionalen Beschr ¨ ankungen l ¨ asst sich die WCET-Analyse als ganzzahliges lineares Programm (engl. Integer Linear Program, ILP) formulieren: δ max := max  n ∑ i:=1 δ i · x i |B struct ∧B func  (7.8) Dabei bezeichnet B func die funktionalen Beschr ¨ ankungen. Die strukturellen Be- schr ¨ ankungen B struct lauten wie folgt: (d 1 = 1) ∧ n  i:=1 ⎛ ⎝ ∑ e j ∈in(v i ) d(e j )= ∑ e k ∈out(v i ) d(e k )=x i ⎞ ⎠ Modellierung der Zielarchitektur Der verwendete Prozessor, aber auch der Zustand in dem sich ein Prozessor bei der Prozessausf ¨ uhrung befindet, hat großen Einfluss auf die Ausf ¨ uhrungszeit ei- nes Grundblocks und somit des Prozesses. Um diese Einfl ¨ usse ber ¨ ucksichtigen zu k ¨ onnen, ist es notwendig, eine Modellierung der Zielarchitektur vorzunehmen, und auf Basis dieser Modelle die Absch ¨ atzung f ¨ ur eine gegebene Mikroarchitektur durch- zuf ¨ uhren. Besondere Schwierigkeiten werden dabei durch dynamische Effekte der Fließbandverarbeitung und der Caches, sowie durch Optimierungen der Compiler verursacht. Um die Ausf ¨ uhrungszeit eines einzelnen Grundblocks oder einer Sequenz von Grundbl ¨ ocken zu sch ¨ atzen, gibt es prinzipiell zwei M ¨ oglichkeiten: 1. ITA: ( engl. Instruction Timing Addition) ist eine Methode ¨ ahnlich der statischen Zeitanalyse von kombinatorischen Schaltungen (siehe Abschnitt 6.5). Dabei wird angenommen, dass jede Instruktion eine konstante Ausf ¨ uhrungszeit besitzt. Durch Summation aller Instruktionen in einem Grundblock erh ¨ alt man somit die Ausf ¨ uhrungszeit f ¨ ur den gesamten Grundblock. 2. PSS: (engl. Path Segment Simulation) basiert auf der zyklenakkuraten Simulati- on eines Basisblocks, wobei die zugrundeliegende Mikroarchitektur sehr genau modelliert werden kann. Um den Einfluss von Compiler-Optimierungen m ¨ oglichst klein zu halten, erfolgt die Zeitsch ¨ atzung auf compilierten Programmen. Die wesentlichen Architekturmerkmale bei der Modellierung der Zielarchitektur sind [154]: 7.4 Zeitanalyse 437 • Datenabh ¨ angige Ausf ¨ uhrungszeiten der Instruktionen: Datenabh ¨ angige Ausf ¨ uh- rungszeiten treten ¨ uberwiegend in CISC-Architekturen (engl. Complex Instruc- tion Set Computer) auf. Aber auch Prozessoren, die manche Instruktionen als Software-Funktionen realisieren, sind von diesem Aspekt betroffen. Da die Aus- f ¨ uhrungszeit einer Instruktion in diesem Fall von den Operanden abh ¨ angt, ist auch die Ausf ¨ uhrungszeit des Grundblocks von den Eingabedaten abh ¨ angig. W ¨ ahrend die ITA-Methode unterschiedliche Ausf ¨ uhrungszeiten einer Instruktion unterst ¨ utzen kann, ist dies in der PSS-Methode aufwendiger. • Fließbandverarbeitung: Die ITA-Methode kann Zeiteffekte durch die verschr ¨ ank- te Ausf ¨ uhrung von Instruktionen nicht ber ¨ ucksichtigen. Im Gegensatz dazu un- terst ¨ utzen die meisten PSS-Methoden die Modellierung von Pipelines (Fließ- bandverarbeitung). Problematisch ist allerdings, wenn die Pipeline-Tiefe so groß ist, dass selbst Grundbl ¨ ocke ¨ uberlappend ausgef ¨ uhrt werden k ¨ onnen. Dies ist ty- pischerweise bei nahezu allen aktuellen Prozessoren der Fall. Aus diesem Grund sollte die PSS-Methode nicht lediglich auf Grundbl ¨ ocke, sondern auf l ¨ angere Pfadsegmente angewendet werden. Dabei gilt: Je l ¨ anger das Pfadsegment, desto akkurater ist das Ergebnis. • Superskalare Architekturen: Bei superskalaren Mikroarchitekturen k ¨ onnen meh- rere Grundbl ¨ ocke parallel berechnet und Instruktionen dynamisch geplant wer- den. Die Analyse basierend auf der ITA-Methode kann hier nicht eingesetzt wer- den. Die Genauigkeit beim Einsatz der PSS-Methode h ¨ angt wiederum von der Pfadl ¨ ange ab. • Instruktionscaches: Bei Verwendung eines Instruktionscaches werden die In- struktionen eines Grundblocks b i auf l i Cachezeilen abgebildet. Jede Cachezei- le f ¨ uhrt dann abh ¨ angig von der Cachearchitektur und der Verdr ¨ angungsstrategie entweder zu einem Cache-Hit oder einem Cache-Miss: Als Erweiterung des ILP aus Gleichung (7.8) kann dies wie folgt modelliert werden: ∀i : ∀1 ≤ j ≤ l i : x i = x i, j = x hit i, j + x miss i, j (7.9) Sei δ hit i, j die Ausf ¨ uhrungszeit einer Instruktion im Falle, dass ein Cache-Hit vor- liegt, und δ miss i, j die Ausf ¨ uhrungszeit, falls ein Cache-Miss auftritt. Dann l ¨ asst sich die Kostenfunktion des ILP wie folgt ¨ andern: δ max := max  n ∑ i:=1 l i ∑ j:=1  δ hit i, j · x hit i, j + δ miss i, j · x miss i, j   (7.10) Aufgrund einer Konfliktanalyse k ¨ onnen Beschr ¨ ankungen f ¨ ur das Cache-Modell aufgestellt werden. In Gegenwart von Instruktionscaches macht lediglich der Einsatz der PSS-Methode Sinn. Bei der Verwendung der ITA-Methode m ¨ ussten Cache-Hits und Cache-Misses anderweitig ermittelt werden. • Datencaches: Bei der Verwendung von Datencaches hat die Zugriffsreihenfolge auf Daten einen großen Einfluss auf die Ausf ¨ uhrungszeit einzelner Instruktionen und somit des Grundblocks. Wie im Fall des Instruktionscaches ist die Anwen- dung der PSS-Methode sinnvoll. 438 7 Software-Verifikation Somit ist die ITA-Methode lediglich f ¨ ur sehr einfache Mikroarchitekturen anwend- bar, w ¨ ahrend die PSS-Methode f ¨ ur komplexe Architekturen anwendbar ist, solange keine datenabh ¨ angigen Ausf ¨ uhrungszeiten zu ber ¨ ucksichtigen sind. Typische Pro- zessoren kombinieren heutzutage viele dieser Architekturmerkmale, was die WCET- Analyse f ¨ ur moderne Prozessoren erschwert. 7.4.2 Echtzeitanalyse f ¨ ur Einprozessorsysteme Auf Modulebene werden mehrere Software-Prozesse auf einem einzelnen Prozessor ausgef ¨ uhrt. Um eventuelle Ressourcenkonflikte aufzul ¨ osen, muss eine Ablaufpla- nung der Prozesse vorgenommen werden. Diese Ablaufplanung kann statisch oder dynamisch erfolgen, wobei letzteres Vorgehen heutzutage ¨ uberwiegt. Dies gilt ins- besondere f ¨ ur Echtzeitsystemen. Dies sind Systeme, bei denen die Antwortzeiten durch sog. engl. Deadlines vorgegeben und garantiert werden m ¨ ussen. Die vorge- gebenen Deadlines stellen dabei nichtfunktionale Anforderungen an die Implemen- tierung dar. Die Zeitanalyse solcher Echtzeitsysteme muss also in der Lage sein, zu bewerten, ob die vorgegebenen Deadlines unter allen Bedingungen eingehalten wer- den. Im Folgenden werden Probleme und Analyseverfahren als Zusammenfassung aus [426] vorgestellt. Betrachtet wird im Folgenden das Modell eines Problemgraphen G(V,E).Die Knoten v ∈V modellieren Software-Prozesse, denen fr ¨ uheste Startzeitpunkte (Relea- sezeiten, Ankunftszeiten) und sp ¨ ateste Endzeitpunkte (Deadlines) zugewiesen wur- den. Kanten e ∈ E entsprechen Datenabh ¨ angigkeiten. Falls nicht anders bemerkt gel- te, dass allen Prozessen die Ankunftszeit 0 und die Deadline ∞ zugewiesen wurde. Ferner gilt die Ressourcenbeschr ¨ ankung mit der vereinfachten Eigenschaft, dass je- der Knoten v ∈ V auf dem einen verf ¨ ugbaren Prozessor abgearbeitet werden kann und die Ausf ¨ uhrungszeit δ i eines Knotens v i ∈ V als bekannt gilt, z. B. durch Annah- me der WCET. Im Allgemeinen ben ¨ otigt der Algorithmus zur Ablaufplanung auf einem Prozes- sor selbst Rechenzeit, um festzulegen, welcher Prozess als n ¨ achstes den Prozessor belegen soll. Diese Zeitspanne bezeichnet man im Allgemeinen als Dispatchlatenz. Definition 7.4.2 (Dispatchlatenz). Die Dispatchlatenz Λ D bezeichnet die maxima- le Zeitspanne zwischen dem Stoppen eines Prozesses v i ∈ V und dem Starten des n ¨ achsten Prozesses v j ∈ V auf dem Prozessor. Offensichtlich sollte die Dispatchlatenz so klein wie m ¨ oglich sein. Im Folgenden gelte die Annahme, dass die Dispatchlatenz null sei. F ¨ ur die Latenz eines Ablauf- plans gelte die gleiche Definition wie f ¨ ur statische Ablaufplanungsverfahren (siehe Definitionen 6.5.3 auf Seite 349 bzw. Gleichung (6.25) auf Seite 349). Folgende Kriterien bei der Bewertung von Algorithmen zur dynamischen Ab- laufplanung zeigen sich als n ¨ utzlich: Definition 7.4.3 (Ressourcenauslastung). Gegeben sei ein Problemgraph G(V,E) und ein Ablaufplan auf einem Prozessor der Latenz Λ . Sei δ i die Ausf ¨ uhrungszeit von Knoten v i ∈ V . Dann bezeichnet 7.4 Zeitanalyse 439 U := ∑ |V | i:=1 δ i Λ · 100 (7.11) die Ressourcenauslastung des Prozessors in Prozent. Offensichtlich ist man bestrebt, die Ressourcenauslastung m ¨ oglichst bei 100% zu halten. Im Falle pr ¨ aemptiver Ablaufplanung kann die Ausf ¨ uhrung eines Prozes- ses unterbrochen werden, um zu einem sp ¨ ateren Zeitpunkt wieder aufgenommen zu werden. F ¨ ur solche Verfahren ist es deshalb interessant, wie lange es dauert, bis ein Prozess endg ¨ ultig abgearbeitet ist. Definition 7.4.4 (Abarbeitungszeit). Gegeben sei ein Problemgraph G(V, E). Sei δ i die Ausf ¨ uhrungszeit von Knoten v i ∈ V, τ b (v i ) der Zeitpunkt, an dem v i zum ersten Mal den Prozessor belegt, und τ e (v i ) der Zeitpunkt, an dem v i vollst ¨ andig abgear- beitet ist (Endzeitpunkt). Dann betr ¨ agt die Abarbeitungszeit δ A (v i ) von v i ∈ V: δ A (v i ) := τ e (v i ) − τ b (v i ) (7.12) Im Weiteren definiert man die sog. Wartezeit (engl. waiting time) eines Prozesses wie folgt: Definition 7.4.5 (Wartezeit). Gegeben sei ein Problemgraph G(V, E). Sei δ i die Ausf ¨ uhrungszeit von Knoten v i ∈ V, τ r (v i ) die Releasezeit von Knoten v i und τ e (v i ) der Zeitpunkt, an dem v i vollst ¨ andig abgearbeitet ist (Endzeitpunkt). Dann bezeich- net δ W (v i ) mit δ W (v i ) := τ e (v i ) − τ r (v i ) − δ i (7.13) die Wartezeit von Prozess i. Die Wartezeit eines Prozesses ist damit die Dauer der Zeitspanne, die er ab dem Zeitpunkt seiner Ankunft (Releasezeit) den Prozessor nicht belegt hat, also sozusa- gen auf seine (weitere) Abarbeitung wartet. Ein ¨ ahnliches Maß ist die sog. Flusszeit, die Summe von Ausf ¨ uhrungszeit und Wartezeit: Definition 7.4.6 (Flusszeit/Antwortzeit). Gegeben sei ein Problemgraph G(V,E). Sei δ i die Ausf ¨ uhrungszeit von Knoten v i ∈ V, τ r (v i ) die Releasezeit von Knoten v i und τ e (v i ) der Zeitpunkt, an dem v i vollst ¨ andig abgearbeitet ist (Endzeitpunkt). Dann bezeichnet δ F (v i ) mit δ F (v i ) := τ e (v i ) − τ r (v i ) (7.14) die Flusszeit von Prozess i. In der Literatur wird die Flusszeit auch h ¨ aufig als Ant- wortzeit (engl. response time) bezeichnet. Im Zusammenhang mit Echtzeitsystemen spielt die Einhaltung von Deadlines zur Beurteilung von Ablaufplanungsverfahren eine große Rolle, da bei diesen Sys- temen die Nichteinhaltung katastrophale Folgen haben kann. Hier sind deshalb auch folgende Definitionen von Eigenschaften eines Ablaufplans von Interesse: 440 7 Software-Verifikation Definition 7.4.7 (Lateness, Tardiness). Gegeben sei ein Problemgraph G(V,E). Sei τ d (v i ) die Deadline (sp ¨ atester Endzeitpunkt) von Knoten v i ∈ V und τ e (v i ) der Zeit- punkt, an dem v i vollst ¨ andig abgearbeitet ist (Endzeitpunkt). Dann bezeichnet δ L (v i ) mit δ L (v i ) := τ e (v i ) − τ d (v i ) (7.15) die sog. engl. Lateness von Prozess i und δ T (v i ) mit δ T (v i ) := max{ τ e (v i ) − τ d (v i ),0} (7.16) die sog. engl. Tardiness von Prozess i. Aperiodische, dynamische Ablaufplanung Ein Verfahren, das die Minimierung der maximalen Lateness der Prozesse zum Ziel hat, kann im Falle nichtpr ¨ aemptiver Ablaufplanung von Prozessen ohne Da- tenabh ¨ angigkeiten auf einem Prozessor mittels der Regel von Jackson angegeben werden [243]: Theorem 7.4.1 (Jackson-Regel [243]). Gegeben sei ein Problemgraph G (V,{}). F ¨ ur die Ankunftszeiten gelte ∀i = 1, ,|V | : τ r (v i )=0. Ferner sei f ¨ ur jeden Pro- zess eine Deadline τ d (v i ) gegeben. Dann ist der Algorithmus, der die Prozesse in der Reihenfolge nicht kleiner werdender Deadlines plant, ein exaktes Verfahren zur Minimierung der maximalen Lateness. Ein Algorithmus, der gem ¨ aß der Jackson-Regel einen Ablaufplan bestimmt, heißt auch Earliest-Due-Date-Algorithmus (EDD). Man kann zeigen, dass bei von null verschiedenen Ankunftszeiten der EDD- Algorithmus nicht mehr exakt ist. Allerdings f ¨ uhrt hier ebenfalls die Erlaubnis der Pr ¨ aemption zu einer einfachen exakten Erweiterung: Zu jedem Zeitpunkt wird unter allen Prozessen, deren Ankunftszeit kleiner oder gleich der aktuellen Zeit ist, der- jenige Prozess geplant, dessen Deadline am kleinsten ist. Diese Strategie von Horn [225] ist auch bekannt als Earliest-Deadline-First-Algorithmus (EDF). Bei verbote- ner Pr ¨ aemption ist das Problem der Minimierung der maximalen Lateness im Falle ungleicher Ankunftszeiten bis auf wenige Spezialf ¨ alle NP-schwer. Ber ¨ ucksichtigung von Datenabh ¨ angigkeiten Der EDF-Algorithmus kennt keine Datenabh ¨ angigkeiten. Im nichtpr ¨ aemptiven Fall bei gleichen Ankunftszeiten gibt es jedoch folgenden Algorithmus von Lawler [292], der als Latest-Deadline-First-Algorithmus (LDF) bekannt ist. Der Algorithmus baut einen Ablaufplan, der die Datenabh ¨ angigkeiten erf ¨ ullt, wie folgt auf: Unter allen Prozessen ohne ungeplante Nachfolger selektiert der LDF-Algorithmus denjenigen Prozess zuerst, dessen Deadline am gr ¨ oßten ist. Dieser Schritt wird so lange iteriert, bis alle Prozesse selektiert wurden. Einen Ablaufplan, der die Datenabh ¨ angigkeiten erf ¨ ullt, erh ¨ alt man dann durch Ausf ¨ uhrung der Prozesse in umgekehrter Reihenfolge der Selektion, d. h. beginnend mit dem zuletzt selektierten Prozess und endend mit dem zuerst selektierten Prozess. 7.4 Zeitanalyse 441 Beispiel 7.4.2. Betrachtet wird ein Problemgraph mit sechs Prozessen v 1 ,v 2 ,v 3 ,v 4 , v 5 ,v 6 und den in Abb. 7.30a) dargestellten Datenabh ¨ angigkeiten. F ¨ ur die Ausf ¨ uh- rungszeiten gilt δ 1 = δ 2 = δ 3 = δ 4 = δ 5 = δ 6 := 1 und die Deadlines τ d (v 1 ) := 2, τ d (v 2 ) := 5, τ d (v 3 ) := 4, τ d (v 4 ) := 3, τ d (v 5 ) := 5, τ d (v 6 ) := 6. Abbildung 7.30b) zeigt einen mit der LDF-Strategie gewonnenen Ablaufplan. Unter den drei Prozessen v 4 ,v 5 und v 6 ohne ungeplante Nachfolger wird v 6 zuerst selektiert, da dessen Dead- line am gr ¨ oßten ist. Dann wird unter den drei Prozessen v 3 ,v 4 und v 5 mit gleichem Argument v 5 selektiert, usw. Zuletzt wird v 1 selektiert. Geplant wird dann in umge- kehrter Reihenfolge der Selektion. Im Beispiel erf ¨ ullen alle Prozesse ihre Deadlines. v 1 v 3 v 6 v 2 v 5 v 4 a) b) 0654321 CPU τ v 1 v 2 v 3 v 4 v 5 v 6 Abb. 7.30. Ablaufplanung mit LDF-Strategie Theorem 7.4.2 (LDF-Regel [292]). Gegeben sei ein Problemgraph G(V, E).F ¨ ur die Ankunftszeiten gelte τ r (v i )=0 ∀i = 1,···,|V |. Ferner sei f ¨ ur jeden Prozess ei- ne Deadline τ d (v i ) gegeben. Dann ist der Algorithmus, der die Prozesse nach der LDF-Regel plant, ein exaktes Verfahren zur Minimierung der maximalen Lateness. Bei ungleichen Ankunftszeiten kann das Problem der Minimierung der maxi- malen Lateness nur dann exakt polynomiell gel ¨ ost werden, wenn man Pr ¨ aemption gestattet. Chetto et al. [90] haben hierzu eine Erweiterung des EDF-Algorithmus vorgestellt. Da EDF keine Datenabh ¨ angigkeiten kennt, werden die Ankunftszeiten τ r (v i ) und die Deadlines τ d (v i ) im ersten Schritt in neue Ankunftszeiten τ ∗ r (v i ) und neue Deadlines τ ∗ d (v i ) transformiert und im n ¨ achsten Schritt die EDF-Strategie an- gewendet. Die folgende Transformation der Ankunftszeiten und Deadlines bewirkt dabei, dass kein Prozess vor Beginn all seiner Vorg ¨ anger starten und keine Nachfol- ger unterbrechen kann. Diese Modifikation heißt EDF ∗ -Algorithmus [90]. Man kann zeigen, dass ein Ablaufplan f ¨ ur das urspr ¨ ungliche Problem mit Datenabh ¨ angigkeiten genau dann existiert, wenn EDF* einen Ablaufplan f ¨ ur das transformierte Problem ohne Datenabh ¨ angigkeiten findet. Die Transformation lautet wie folgt: τ ∗ r (v j ) := max{ τ r (v j ), max (v i ,v j )∈E { τ ∗ r (v i )+ δ i }} (7.17) Offensichtlich kann Prozess v j erst nach seiner Ankunftszeit und nicht fr ¨ uher als zum fr ¨ uhestm ¨ oglichen Endzeitpunkt aller seiner direkten Vorg ¨ anger starten. 442 7 Software-Verifikation τ ∗ d (v i ) := min{ τ d (v i ), min (v i ,v j )∈E { τ ∗ d (v j ) − δ j }} (7.18) Weiterhin muss ein Prozess v i vor seiner Deadline beendet sein, darf aber auch nicht sp ¨ ater als zum sp ¨ atestm ¨ oglichen Startzeitpunkt aller s einer direkten Nachfolger en- den. Beispiel 7.4.3. Betrachtet wird die Datenabh ¨ angigkeit (v i ,v j ) in Abb. 7.31a) mit Ausf ¨ uhrungszeiten δ i := 5 und δ j := 7. Die Ankunftszeiten betragen τ r (v i ) := 2, τ r (v j ) := 0, die Deadlines τ d (v i ) := 15, τ d (v j ) := 14. F ¨ ur die transformierte An- kunftszeit von v j erh ¨ alt man τ ∗ r (v j ) := max{0,2 + 5} = 7. F ¨ ur die transformierte Deadline von v i erh ¨ alt man τ ∗ d (v i ) := min{15,14 − 7} = 7. Plant man anschließend die Prozesse nach der EDF-Regel, so erh ¨ alt man den Ablaufplan in Abb. 7.31b). Man vergewissere sich, dass eine Ablaufplanung nach EDF ohne Transformation der An- kunftszeiten und Deadlines die Datenabh ¨ angigkeiten nicht respektieren w ¨ urde. b) v j v i a) 0 CPU 246810121416 τ v j v i Abb. 7.31. Ablaufplanung mit EDF ∗ -Strategie: a) Problemgraph und b) Ablaufplan mit EDF- Strategie bei Verwendung der transformierten Zeiten Periodische, dynamische Ablaufplanung Wichtige Ergebnisse zur Theorie dieser Klasse von iterativen dynamischen Ablauf- planungsproblemen stammen von Liu und Layland [307], die im Folgenden zusam- mengefasst werden. Deren Untersuchungen beziehen sich auf ein Modell von pe- riodischen Prozessen, die sich durch einen iterativen Problemgraphen G(V,{},−), d. h. durch einen Problemgraphen ohne Datenabh ¨ angigkeiten und folglich ohne In- dexverschiebungen darstellen lassen. Den Prozessen v i ∈ V sind bekannte Ausf ¨ uh- rungszeiten δ i zugewiesen. Ferner wird angenommen, dass Pr ¨ aemption erlaubt sei. Im Gegensatz zu iterativen Ablaufplanungsproblemen mit Datenabh ¨ angigkeiten ha- ben hier einzelne Prozesse meist unterschiedliche Perioden P(v i ). Betrachtet wird damit folgendes Ablaufplanungsmodell: Definition 7.4.8 (Iteratives, dynamisches Ablaufplanungsmodell). Ein iteratives, dynamisches Ablaufplanungsmodell besteht aus • einem iterativen Problemgraphen G(V, {},−), • Ausf ¨ uhrungszeiten δ i f ¨ ur Knoten v i ∈ V, • Perioden P(v i ) f ¨ ur Knoten v i ∈ V, 7.4 Zeitanalyse 443 • periodischen Releasezeiten τ r (v i ,n) mit ∀n ≥ 0: τ r (v i ,n) := τ ∗ r (v i )+n ·P(v i ). Dies bedeutet, dass die Releasezeiten neuer Iterationen eines Knotens v i immer im Abstand des Iterationsintervalls (der Periode) P(v i ) auftreten. Die Release- zeiten τ ∗ r (v i ) werden auch als Phasen bezeichnet. Ferner gibt es • periodische Deadlines τ d (v i ,n) mit ∀n ≥ 0: τ d (v i ,n) := τ r (v i ,n)+ τ ∗ d (v i ). Dies bedeutet, dass sich die Deadlines ebenfalls im Abstand der Periode P(v i ) eines Prozesses wiederholen. Die periodische Deadline τ ∗ d (v i ) ist hier keine ab- solute Zeitbeschr ¨ ankung, sondern als Zeitspanne relativ zur Releasezeit einer Iteration definiert. Liu und Layland besch ¨ aftigten sich zun ¨ achst nur mit dem Spezialfall ∀v i ∈ V : t ∗ d (v i )=P(v i ), d. h. die Deadline einer Iteration eines Prozesses ist immer gleich der Dauer der Periode einer Iteration. Zur Erl ¨ auterung der Begriffe soll folgendes Beispiel dienen. Beispiel 7.4.4. Gegeben ist ein Problemgraph mit zwei Knoten v 1 und v 2 , den Aus- f ¨ uhrungszeiten δ 1 := 1, δ 2 := 2, 5 sowie den Perioden P(v 1 ) := 2 und P(v 2 ) := 5. F ¨ ur die Deadlines gilt τ ∗ d (v 1 )=P(v 1 ), τ ∗ d (v 2 )=P(v 2 ),f ¨ ur die Ankunftszeiten der nullten Iteration gilt τ ∗ r (v 1 )= τ ∗ r (v 2 ) := 0. Abbildung 7.32 zeigt zwei periodische Ablaufpl ¨ ane. Der Ablaufplan in Abb. 7.32a) erf ¨ ullt beide Deadlines und wiederholt sich periodisch nach zwei Iterationen von Knoten v 2 bzw. f ¨ unf Iterationen von Kno- ten v 1 . Der Ablaufplan in Abb. 7.32b) erf ¨ ullt die Deadline der nullten Iteration von Knoten v 2 nicht ( τ d (v 2 ,0)= τ r (v 2 ,0)+ τ ∗ d (v 2 )=0 +5 < 5,5). Liu und Layland betrachteten anschließend Algorithmen zur iterativen Ablauf- planung mit Echtzeitbedingungen und statischen Priorit ¨ aten. Um hinreichende Kri- terien angeben zu k ¨ onnen, wann ein Algorithmus zur Ablaufplanung f ¨ ur beliebi- ge Instanzen von Ablaufplanungsproblemen alle Deadlines erf ¨ ullen wird, muss man zeigen, dass der Algorithmus auch f ¨ ur den schlimmsten Fall angenommener Release- zeiten einen in diesem Sinn g ¨ ultigen Ablaufplan findet. So zeigten Liu und Layland, dass dieser Fall immer durch die Phasen ∀v i ∈ V : τ ∗ r (v i )=0 gegeben ist, d. h. wenn alle Prozesse gleichzeitig ankommen. Anschaulich beginnt in diesem Fall der Wett- lauf der Zeit mit den Deadlines aller Prozesse gleichzeitig, was offensichtlich nicht ung ¨ unstiger sein k ¨ onnte. Dann zeigten sie, dass ein Algorithmus zur Ablaufplanung mit statischen Priorit ¨ aten eine Probleminstanz unter Erf ¨ ullung aller Deadlines immer dann planen kann, wenn f ¨ ur die Phasen ∀v i ∈ V : τ ∗ r (v i )=0 alle Deadlines f ¨ ur die nullte Iteration erf ¨ ullt werden. Um diese Ergebnisse anschaulicher zu machen, wird nun ein bekannter Algorith- mus zur iterativen Ablaufplanung mit statischen Priorit ¨ aten vorgestellt. [...]... Prozesse beschrieben Insbesondere, wenn ausf¨ hrbare Verhaltensmodelle u zum Einsatz kommen, werden diese in zunehmenden Maße mit der Systembeschreibungssprache SystemC beschrieben C Haubelt, J Teich, Digitale Hardware/Software-Systeme, eXamen.press, DOI 10.1007/978-3-642-05356-6 8, c Springer-Verlag Berlin Heidelberg 2010 452 8 Systemverifikation Andererseits sind die Strukturmodelle auf Systemebene eine . zunehmenden Maße mit der Systembeschrei- bungssprache SystemC beschrieben. C. Haubelt, J. Teich, Digitale Hardware/Software-Systeme, eXamen.press, DOI 10.1007/978-3-642-05356-6 8, c  Springer-Verlag