Digitale Hardware/ Software-Systeme- P16 pptx

444 7 Software-Verifikation v 1 v 1 v 2 v 2 v 1 v 2 v 1 v 1 v 1 v 2 v 1 v 2 v 1 v 2 CPU v 2 v 2 n = 0 n = 1 n = 0 b) CPU τ ∗ d (v 1 ) a) n = 0 n = 1 n = 2 n = 3 n = 4 τ ∗ d (v 1 ) τ ∗ d (v 1 ) τ ∗ d (v 1 ) n = 0 n = 1 0123456789 10 11 0123456789 10 11 τ τ τ ∗ d (v 2 ) τ ∗ d (v 1 ) τ ∗ d (v 2 ) τ ∗ d (v 2 ) τ ∗ d (v 1 ) τ ∗ d (v 1 ) Abb. 7.32. Iterative, dynamische Ablaufpl ¨ ane: a) mit der EDF-Strategie und b) mit dem RMS- Algorithmus Ratenmonotone Ablaufplanung Unter dem Begriff ratenmonotone Ablaufplanung (engl. rate-monotonic scheduling, RMSs) haben Liu und Layland ein pr ¨ aemptives Ablaufplanungsverfahren beschrie- ben, das den Prozessen statische Priorit ¨ aten nach folgendem Prinzip zuweist: v i habe gr ¨ oßere Priorit ¨ at als v j , falls P(v i ) < P(v j ).Alsow ¨ ahlt man die Priorit ¨ at statisch bei- spielsweise proportional zur gegebenen Rate eines Prozesses (Kehrwert der Periode). Prozesse mit kleinerer Periode werden also h ¨ oher priorisiert als Prozesse mit gr ¨ oße- rer Periode. Dies gilt also unabh ¨ angig von den Ausf ¨ uhrungszeiten der Prozesse. Bei Ankunft eines Prozesses h ¨ oherer Priorit ¨ at wird der laufende Prozess unterbrochen. Beispiel 7.4.5. Abbildung 7.32b) zeigt einen mit der RMS-Strategie gewonnenen Ablaufplan f ¨ ur das in Beispiel 7.4.4 vorgestellte Problem. Liu und Layland zeigten dann, dass der RMS-Algorithmus unter allen Algorith- men mit statischen Priorit ¨ aten (f ¨ ur den von ihnen angenommen Fall τ ∗ d (v i )=P(v i )) immer einen g ¨ ultigen Ablaufplan bestimmt, falls ein solcher existiert. Beispiel 7.4.6. Aus diesem Ergebnis l ¨ asst sich schließen, dass es keinen Algorithmus mit festen Priorit ¨ aten gibt, der f ¨ ur das Problem aus Beispiel 7.4.4 alle Deadlines erf ¨ ullt, da der RMS-Algorithmus keinen solchen Ablaufplan bestimmt hat. Nun l ¨ asst sich allerdings ein einfaches, hinreichendes Kriterium angeben, wann der RMS-Algorithmus immer einen Ablaufplan findet, der alle Deadlines erf ¨ ullt: 7.4 Zeitanalyse 445 Theorem 7.4.3 (Liu und Layland). Gegeben sei ein Ablaufplanungsproblem nach Definition 7.4.8 mit der Eigenschaft ∀v i ∈ V : τ ∗ d (v i )=P(v i ). Die Menge von Prozes- sen kann unter Erf ¨ ullung aller Deadlines mit dem RMS-Algorithmus geplant werden, falls |V | ∑ i:=1 δ i P(v i ) ≤|V|·(2 1/|V | − 1) (7.19) gilt. F ¨ ur |V | = 1erh ¨ alt man als rechte Seite von Ungleichung (7.19) den Wert 1. Damit kann das RMS-Verfahren ein Problem mit einem Prozess unter der Erf ¨ ullung dessen Deadline immer planen, wenn (offensichtlich) die Ausf ¨ uhrungszeit kleiner gleich der Deadline (hier auch Periode) ist. Interessanter ist der Fall f ¨ ur |V |→∞. Dann erh ¨ alt man f ¨ ur die rechte Seite der Ungleichung (7.19) den Wert ln(2).Damitl ¨ asst sich die Aussage treffen, dass f ¨ ur alle Problemgr ¨ oßen |V | immer ein g ¨ ultiger Ab- laufplan gefunden wird, wenn ∑ |V | i:=1 δ i /P(v i ) ≤ ln(2) gilt, d. h. wenn der Prozessor weniger als 1/ln2 · 100% ≈ 69, 3% ausgelastet ist. Man beachte, dass das Kriteri- um in Theorem 7.4.3 nat ¨ urlich nur eine hinreichende Bedingung darstellt, so dass es auch Probleminstanzen geben kann, f ¨ ur die der RMS-Algorithmus auch bei h ¨ oherer Prozessorauslastung einen Ablaufplan finden kann, der alle Deadlines einh ¨ alt. Aus Ungleichung (7.19) l ¨ asst sich ¨ ubrigens auch eine notwendige Bedingung f ¨ ur die Einhaltbarkeit aller Deadlines erkennen: ∑ |V | i:=1 δ i /P(v i ) ≤ 1. Dies entspricht dem Grenzfall einer Prozessorauslastung von 100%. Falls diese Bedingung nicht erf ¨ ullt ist, kann offensichtlich auch kein Algorithmus mit dynamischen Priorit ¨ aten einen g ¨ ultigen Ablaufplan finden. Damit stellt sich aber die Frage, ob es denn einen Algorithmus gibt, der auch f ¨ ur den extremen Fall ∑ |V | i:=1 δ i /P(v i )=1 einen g ¨ ultigen Ablaufplan finden kann? Die Antwort heißt ja, und ein solcher Algorithmus ist der EDF-Algorithmus. Theorem 7.4.4 (Liu und Layland). Gegeben sei ein Ablaufplanungsproblem nach Definition 7.4.8 mit der Eigenschaft ∀v i ∈V : τ ∗ d (v i )=P(v i ). Die Menge von Prozesse kann unter Erf ¨ ullung aller Deadlines mit dem EDF-Algorithmus geplant werden, falls |V | ∑ i:=1 δ i P(v i ) ≤ 1 (7.20) gilt. Der EDF-Algorithmus ist priorit ¨ atsgesteuert mit dynamischer Priorit ¨ at, wobei die h ¨ ochste Priorit ¨ at demjenigen Prozess zugewiesen wird, dessen Deadline am kleinsten ist. Pr ¨ aemption erfolgt immer dann, wenn es einen noch nicht fertig abgearbeiteten Prozess gibt, der eine h ¨ ohere Priorit ¨ at besitzt. Beispiel 7.4.7. Abbildung 7.32a) zeigt einen mit der EDF-Strategie ermittelten Ab- laufplan, der alle Deadlines f ¨ ur das Problem aus Beispiel 7.4.4 erf ¨ ullt. Dies gilt bei einer Prozessorauslastung von 100% ( ∑ 2 i:=1 δ i P(v i ) = 1/2 +2, 5/5 = 1). In Abb. 7.32b) 446 7 Software-Verifikation ist ein Ablaufplan nach der RMS-Strategie dargestellt. EDF und RMS werden in der Praxis nahezu ausschließlich in der hier dargestellten pr ¨ aemptiven Version einge- setzt. Antwortzeitanalyse Neben den vorgestellten einfachen auf Ressourcenauslastung beruhenden Tests in Gleichung (7.19) f ¨ ur RMS-Ablaufplanung und in Gleichung (7.20) f ¨ ur EDF, wur- den Tests entwickelt, die detailliertere Informationen ¨ uber das Zeitverhalten und Priorit ¨ aten von Prozessen zur Bestimmung der Planbarkeit periodischer Prozesse ausnutzen. F ¨ ur RMS betrachten Joseph und Pandya in [249] die Antwortzeit eines Prozesses v i ∈ V im ung ¨ unstigsten Fall gleicher Ankunftszeiten aller Prozesse. Die Antworts- bzw. Flusszeit δ F (v i ) ist dann durch die Summe der eigenen Ausf ¨ uhrungs- zeit δ i und der maximalen sog. Interferenz I i gegeben. Der Interferenzterm I i be- stimmt dabei die Summe der Verz ¨ ogerungszeiten, denen v i unterliegt, wenn dieser durch h ¨ oherpriore Prozesse unterbrochen wird. Sei hp(v i ) ⊆ V die Menge h ¨ oherprio- rer Prozesse von v i und die Deadline t ∗ d (v i ) gleich der Periode P(v i ) f ¨ ur alle v i ∈ V . Dann gilt offensichtlich: δ F (v i ) := δ i + ∑ v j ∈hp(v i ) δ j  δ F (v i ) P(v j )  ≤ t ∗ d (v i )=P(v i ) (7.21) Gibt es f ¨ ur diese rekursive Gleichung eine L ¨ osung im Intervall [0, ,t ∗ d (v i )],so erf ¨ ullt der Prozess v i unter RMS-Ablaufplanung seine Deadline t ∗ d (v i ). Zeitgetriebene, dynamische Ablaufplanung Dynamische, priorit ¨ atsbasierte Ablaufplanung stellt eine effiziente Methode zur Pla- nung von Prozessen unter vielen m ¨ oglichen Umst ¨ anden dar. Dies hat allerdings h ¨ aufig zur Folge, dass das System bei dessen Ausf ¨ uhrung ein starkes dynamisches Verhalten zeigt, was die Analyse erschwert. Im Gegensatz dazu weist eine zeitge- triebene, dynamische Ablaufplanung jedem Prozess einen mehr oder weniger fest- stehenden Zeitschlitz f ¨ ur dessen Abarbeitung zu. Damit kann ein Prozess einen Pro- zessor f ¨ ur ein genau festgelegtes Zeitbudget belegen. Wenn dieses Zeitbudget aufge- braucht ist, wird dem n ¨ achsten Prozess der Prozessor zugeteilt. Im Folgenden werden zwei prominente Vertreter zeitgetriebener, dynamischer Ablaufplanung vorgestellt: Round-Robin- und TDMA-Ablaufplanung. Round-Robin-Ablaufplanung (RR) Bei der sog. Round-Robin-Ablaufplanung (RR) gibt es ein festes Zeitintervall Q, nach dessen Ablauf sp ¨ atestens ein Kontextwechsel eingeleitet wird (z. B. alle Q = 100 Zeitschritte), falls nicht ein geplanter Prozess vor Ablauf des Zeitquantums be- endet wurde. Die laufbereiten Prozesse werden in einer zirkul ¨ aren Warteschlange verwaltet und reihum f ¨ ur die maximale Zeitdauer eines Zeitquantums geplant. 7.4 Zeitanalyse 447 Beispiel 7.4.8. Betrachtet wird ein Problemgraph mit drei Prozessen v 1 ,v 2 und v 3 ohne Datenabh ¨ angigkeiten mit den Ausf ¨ uhrungszeiten δ 1 := 24, δ 2 := 3, δ 3 := 30 und den Ankunftszeiten τ r (v 1 )= τ r (v 2 )= τ r (v 3 ) := 0. Abbildung 7.33 zeigt den mit der RR-Strategie gewonnenen Ablaufplan f ¨ ur ein Zeitquantum von Q := 4 Zeitschritten. Man erkennt, dass zum Zeitpunkt τ = 4 der Knoten v 1 suspendiert wird, da das Zeitquantum abgelaufen ist. Erst zum Zeitpunkt τ = 11 wird v 1 weiter berechnet. Die mittlere Wartezeit betr ¨ agt in diesem Beispiel δ W =(47 − 24)+(7 − 3)+(57− 30)/3 = 18 Zeiteinheiten. v 2 v 3 v 1 v 3 v 3 v 3 v 3 v 3 v 1 v 1 v 1 v 1 v 1 CPU 0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 τ v 3 v 3 Abb. 7.33. Ablaufplanung mit RR-Strategie Round-Robin-Ablaufplanung wird h ¨ aufig in Mehrbenutzerbetriebssystemen an- gewendet. Als Nachteil muss man h ¨ aufig lange Wartezeiten in Kauf nehmen. Bei ei- ner Anzahl von N planbaren Prozessen und einem Zeitquantum Q kann man jedoch die Schranke (N − 1)Q als l ¨ angstes Zeitintervall, bis ein Prozess sp ¨ atestens wieder weiter abgearbeitet wird, angeben. Falls Q gegen unendlich strebt, erh ¨ alt man den bekannten FCFS-Algorithmus (engl. First Come, First Served). Falls Q gegen null strebt, verh ¨ alt sich das System (unter Vernachl ¨ assigung von Kontextwechselzeiten) wie ein System mit N Prozessoren, die allerdings jeweils nur die 1/N-fache Rechen- leistung besitzen. TDMA Neben der Round-Robin-Ablaufplanung gibt es eine weitere popul ¨ are zeitgetriebe- ne Ablaufplanungsstrategie, die als TDMA (engl. Time Division Multiple Access) bekannt ist. Hier werden jedem Prozess periodisch auf einem Prozessor Zeitslots zu- gewiesen. Im Gegensatz zur Round-Robin-Strategie erfolgt dies unabh ¨ angig davon, ob der Prozess gerade laufbereit ist oder nicht. Damit h ¨ angt das Zeitverhalten eines Prozesses nicht mehr vom Zeitverhalten anderer Prozesse ab, was die Zeitanalyse stark vereinfacht. Zum Beispiel l ¨ asst sich die Antwortzeit eines Prozesses v i mit Pe- riode P(v i ), zugewiesener Slotbreite S(v i ),Ausf ¨ uhrungszeit δ i und Zeitquantum Q wie folgt berechnen: δ F (v i )= δ i +(Q− S(v i ))  δ i S(v i )  (7.22) Der eigenen Ausf ¨ uhrungszeit δ i zuzuschlagen sind maximal  δ i S(v i )  Zeitscheiben, in denen v i die Ressource (Q − S(v i )) Zeitschritte nicht belegt. TDMA ist zwar im 448 7 Software-Verifikation Bereich der Ablaufplanung auf Prozessoren wenig bekannt, wird hingegen oft zur Planung von Kommunikationen auf Bussen genutzt. 7.5 Literaturhinweise Die formale ¨ Aquivalenzpr ¨ ufung von Assemblerprogrammen auf Basis von symbo- lischer Simulation ist in [122] beschrieben. Spezielle Eigenschaften zu Assembler- programmen f ¨ ur DSPs und VLIW-Prozessoren und deren Behandlung in der ¨ Aqui- valenzpr ¨ ufung sind in [123] bzw. [159] aufgef ¨ uhrt. Der Einsatz von Schnittpunk- ten zur strukturellen ¨ Aquivalenzpr ¨ ufung von Assemblerprogrammen ist in [160] be- schrieben. Eine Erweiterung der strukturellen ¨ Aquivalenzpr ¨ ufung zur ¨ Aquivalenz- pr ¨ ufung von C-Programmen mit Hardware-Schaltungen findet sich in [161]. Weitere Ans ¨ atze zum Vergleich von C-Programmen mit Hardware sind in [270], [264] und [229] pr ¨ asentiert. Die ¨ Aquivalenzpr ¨ ufung von C-Programmen auf Basis von symbo- lischer Simulation ist in [315] beschrieben. In [394] ist die ¨ Aquivalenzpr ¨ ufung von Schleifenprogrammen beschrieben. Weiterf ¨ uhrende Ans ¨ atze sind in [395] und [396] vorgestellt. Die Verfahren zur funktions- und strukturorientierten Testfallgenerierung wer- den ausf ¨ uhrlich in [305] diskutiert. Bei den simulativen Verifikationsmethoden ist ei- ne 100%-ige Zweig ¨ uberdeckung heutzutage das Minimalkriterium in der Software- Entwicklung. Der Standard DO-178B f ¨ ur die Software-Entwicklung in sicherheits- kritischen Bereichen fordert beispielsweise einen modifizierten Bedingungs-/Ent- scheidungs ¨ uberdeckungstest [382]. Darin werden Testf ¨ alle gefordert, die zeigen, dass jede atomare Bedingung die Evaluierung einer Entscheidung unabh ¨ angig von anderen atomaren Bedingungen beeinflussen kann. Eine vergleichende Studie zwi- schen Zweig-, Pfad- und strukturiertem Pfad ¨ uberdeckungstest findet sich in [227, 228]. Ein modifizierter strukturierter Pfad ¨ uberdeckungstest ist in [305] beschrieben. In diesem wird die Komplexit ¨ at reduziert, indem die ¨ Uberdeckung von ausf ¨ uhrba- ren Teilpfaden in Schleifen gefordert wird, nicht aber die ¨ Uberdeckung s ¨ amtlicher Kombinationen. Die datenflussorientierte Testfallgenerierung spielt in der Praxis heutzutage noch nicht die Rolle wie die kontrollflussorientierte Testfallgenerierung. Ein Vergleich der all defs-, all c-uses- und all p-uses- ¨ Uberdeckungstests findet sich in [190]. Dar ¨ uber hinausgehende Techniken sind beispielsweise der required k-tuples- ¨ Uberdeckungs- test [349, 109, 350] und der Datenkontext ¨ uberdeckungstest [290, 291, 109]. Letzterer verlangt, dass alle existierenden M ¨ oglichkeiten den in einem gegebenen Grundblock verwendeten Variablen Werte zuzuweisen, ber ¨ ucksichtigt werden. Dabei kann auch die unterschiedliche Reihenfolge der Wertzuweisung ber ¨ ucksichtigt werden. Eine gute ¨ Ubersicht ¨ uber Methoden und Werkzeuge zur formalen funktionalen Eigenschaftspr ¨ ufung von Programmen findet sich in [140]. Darin wird eine Unter- scheidung in Verfahren zur statischen Programmanalyse, zur Modellpr ¨ ufung und zur SAT-basierten Modellpr ¨ ufung vorgenommen. Die abstrakte Interpretation zur stati- schen Programmanalyse wurde erstmal 1977 vorgestellt [118]. Die notwendigen ma- thematischen Zusammenh ¨ ange zwischen konkretem und abstraktem Wertebereich, 7.5 Literaturhinweise 449 unter denen der mittels abstrakter Interpretation berechnete abstrakte Fixpunkt eine korrekte Approximation des konkreten Fixpunktes ist, werden in [119] beschrieben. An gleicher Stelle ist beschrieben, wie abstrakte Wertebereiche nach Bedarf konstru- iert werden k ¨ onnen. Bei den abstrakten Wertebereichen wird dabei zwischen relatio- nalen und nichtrelationalen abstrakten Wertebereichen unterschieden. Die relatio- nalen DBM-Wertebereiche wurden zun ¨ achst zur Analyse zeitbehafteter Petri-Netze verwendet [471]. Eine h ¨ ohere Expressivit ¨ at besitzen Oktagon- [327] und Oktaeder- Wertebereiche [96]. Polyeder-Wertebereiche wurden erstmals zur Verifikation num- merischer Eigenschaften von Programmen und des Zeitverhaltens eingebetteter Soft- ware verwendet [120, 213]. Ein weiteres großes Anwendungsgebiet statischer Pro- grammanalyse ist die Analyse von Programmen, die Zeiger verwenden. Die sog. Alias-Analyse untersucht, ob zwei Zeiger die selbe Speicherstelle adressieren. Die Ermittlung der Speicherstelle, auf die ein Zeiger zugreift, wird als engl. point to analysis bezeichnet [220]. Eine Generalisierung auf dynamisch erzeugte Datenstruk- turen erfolgt in [376, 248] und wird als engl. shape analysis bezeichnet. Die Zusammenh ¨ ange und Unterschiede zwischen statischer Programmanalyse und Modellpr ¨ ufung sind in [410, 389, 46] diskutiert. Werkzeuge zur Modellpr ¨ ufung von Software k ¨ onnen generell in explizite und symbolische Modellpr ¨ ufer unterschie- den werden. Der wohl bekannteste Vertreter expliziter Modellpr ¨ ufer ist SPIN [222]. Erste Versionen des Java Pathfinder haben auf SPIN aufgesetzt [456]. Neben SPIN und Java Pathfinder gibt es mit CMC [339], ZING [15] und VeriSoft [195] drei weite- re wichtige Vertreter expliziter Modellpr ¨ ufer. Letzterer ist zustandslos, d. h. besuchte Zust ¨ ande werden nicht gespeichert, und begegnet damit der Zustandsexplosion. Al- lerdings ist dieses Verfahren unvollst ¨ andig f ¨ ur Systeme, die Zyklen enthalten. F ¨ ur die Terminierung muss zus ¨ atzlich die Suchtiefe beschr ¨ ankt werden. Modellpr ¨ ufungsverfahren, die auf Abstraktionsverfeinerung beruhen, verwenden zur Erstellung der abstrakten Modelle heutzutage Pr ¨ adikatenabstraktion [205]. Ein iteratives Verfahren zur Pr ¨ adikatenabstraktion ist unter den Namen CEGAR (engl. counterexample-guided abstraction refinement) bekannt geworden [23, 100]. Die Entscheidungsprozeduren, die zur Bestimmung des abstrakten Modells ben ¨ otigt wer- den, basieren entweder auf Theoreml ¨ osern [24, 131] oder SAT-Solvern [103, 114]. Ein erstes Modellpr ¨ ufungsverfahren auf Basis von Pr ¨ adikatenabstraktion mit dem Namen SLAM wurde von der Firma Microsoft entwickelt [25]. SLAM besteht aus mehreren Werkzeugen wie C2BP [26] zur Pr ¨ adikatenabstraktion, dem symbolischen Modellpr ¨ ufer BEBOP [27] sowie dem Simulations- und Verfeinerungswerkzeug NEWTON [28]. W ¨ ahrend SLAM Theoreml ¨ oser zur Pr ¨ adikatenabstraktion einset- zen, verwendet SATABS einen SAT-Solver [103]. F ¨ ur die eigentliche Verifikation setzt SATABS den QBF-Solver-basierten Modellpr ¨ ufer BOPPO [115] ein. Eine der ersten Implementierungen eines SAT-basierten Modellpr ¨ ufers f ¨ ur C- Programme heißt CBMC, welches unterschiedliche Prozessor- und Speicherarchitek- turen unterst ¨ utzt [104, 102]. Der Ansatz zur Zustandsraumreduktion durch Schleifen- abwicklung geht auf Currie et al. zur ¨ uck [123]. Die grundblockbasierte SAT-basierte Modellpr ¨ ufung in [242] unterscheidet sich von BMC durch die Abstraktion vom Programmz ¨ ahler, wodurch es u. a. leichter wird, Funktionsaufrufe zu modellieren. Eine Erweiterung von CBMC auf SMT-Solver unter Verwendung von ganzzahliger 450 7 Software-Verifikation linearer Arithmetik ist in [17, 18] beschrieben. Der einzige SAT-basierte Modell- pr ¨ ufungsansatz der ein Abrollen der Zustands ¨ ubergangsrelation vornimmt ist F-Soft [241]. WCET-Analyse im Allgemeinen ist nicht entscheidbar. Sowohl Kligerman and Stoyenko [263] als auch Puschner and Koza [368] haben die Bedingungen unter- sucht, unter denen das Problem entscheidbar wird. Zu diesen Bedingungen z ¨ ahlen beschr ¨ ankte Schleifen, Abwesenheit von rekursiven Funktionsaufrufen und Abwe- senheit von dynamischen Funktionsaufrufen. Eine ILP-basierte WCET-Analyse ist in [302] vorgestellt. Eine Erweiterung um die Ber ¨ ucksichtigung eines Instruktions- caches ist in [303] beschrieben. In [428] zeigen Theiling et al., dass es m ¨ oglich ist, die Programmpfadanalyse von der Analyse der Zielarchitektur zu separieren, indem Ergebnisse der Zielarchitekturanalyse durch abstrakte Interpretation in dem ILP zur Bestimmung des l ¨ angsten Programmpfads verwendet werden. Dynamische Ablaufplanungsverfahren und Echtzeitbedingungen sind ausf ¨ uhr- lich in den B ¨ uchern [262], [308] und [79] pr ¨ asentiert. Detaillierte Informationen ¨ uber EDF enth ¨ alt das EDF-Buch [408]. In [468, 78] werden auch interessante Ver- gleiche zwischen ratenmonotoner Ablaufplanung (RMS) und EDF beschrieben. Er- weiterungen der ratenmonotonen Ablaufplanung unter dem Namen deadlinemono- tone Ablaufplanung sind von Leung und Whitehead [301] sowie Lehoczky und Sha [300] betrachtet worden, wobei die Deadlines von Prozessen nicht notwendigerwei- se gleich ihrer Perioden sind. Joseph und Pandya entwickelten einen ersten Ansatz zur Antwortzeitanalyse bei ratenmonotoner Ablaufplanung [249]. Diese Antwort- zeitanalyse erlaubt die Betrachtung beliebiger Priorit ¨ atszuweisungen. Er gilt daher insbesondere auch im Falle der deadlinemonotonen Ablaufplanung, wenn die Dead- lines kleiner gleich den Perioden der Prozesse sind. F ¨ ur den Fall, dass Deadlines gr ¨ oßer als die Perioden eines Prozesses sein d ¨ urfen, besteht das Problem, dass Instan- zen einer folgenden Iteration ankommen k ¨ onnen, bevor die Ausf ¨ uhrung von Instan- zen der aktuellen Iteration beendet ist. Im Ansatz von Lehoczky [299] werden dazu Fenster von mehreren aufeinander folgenden Iterationen zusammen analysiert und daraus eine kombinierte Antwortzeit berechnet. Von Audsley [21] und Tindell [439] stammen schließlich Erweiterungen der Antwortzeitanalyse, die auch das Ph ¨ anomen nicht exakt periodisch ankommender Prozesse, sondern sog. engl. release jitter zu- lassen sowie das Auftreten von periodischen sporadischen Prozessen, sog. engl. spo- radic bursts.F ¨ ur EDF-Ablaufplanung wird eine Antwortzeitanalyse in [406, 407] beschrieben. Bei den zeitgetriebenen, dynamischen Ablaufplanungsverfahren sind die Round- Robin- und TDMA-Ablaufplanung die prominentesten Vertreter. Kopetz gibt in sei- nem Buch [266] eine gute ¨ Ubersicht ¨ uber TDMA-Ablaufplanung und der kommerzi- ellen Anwendung im sog. engl. Time-Triggered Protocol (TTP) [443]. Andere indus- trielle Anwendungen spiegeln sich wieder im sog. FlexRay-Busstandard [165]. Im Mittel f ¨ uhrt Round-Robin-Ablaufplanung zu besseren Ergebnissen, da bei TDMA ungenutzte Zeitslots f ¨ ur andere Prozesse nicht zur Verf ¨ ugung stehen. Man kann zei- gen, dass Round-Robin-Ablaufplanung aber im schlechtesten Fall das Verhalten von TDMA besitzt. Daher kann man die TDMA-Analyse auch zur Analyse von Round- Robin-Ablaufplanung einsetzen. 8 Systemverifikation System Logik Software Hardware Implementierung Spezifikation ArchitekturModul Block Abb. 8.1. Verifikation auf der Systemebene Der technologische Fortschritt erm ¨ oglicht es, Systeme mit einer immer gr ¨ oße- ren Komplexit ¨ at zu bauen. Um dabei mit den Entwurfsmethoden Schritt zu halten, ist auch ein Schritt auf eine h ¨ ohere Abstraktionsebene notwendig, die es erlaubt, Systeme unabh ¨ angig von ihrer sp ¨ ateren Aufteilung in Hardware- und Software- Komponenten zu betrachtet. Diese Abstraktionsebene wird als Systemebene (engl. Electronic System Level) bezeichnet. Auf Systemebene wird das Systemverhalten oftmals als eine Menge kommuni- zierender Prozesse beschrieben. Insbesondere, wenn ausf ¨ uhrbare Verhaltensmodelle zum Einsatz kommen, werden diese in 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 Berlin Heidelberg 2010 452 8 Systemverifikation Andererseits sind die Strukturmodelle auf Systemebene eine Netzliste aus Kom- ponenten mit der Granularit ¨ at von Prozessoren, Hardware-Beschleunigern, Spei- chern und Bussen. Auch diese Strukturmodelle werden zunehmend mit der System- beschreibungssprache SystemC modelliert. Von besonderem Interesse ist dabei die Interaktion der einzelnen Komponenten. Diese wird typischerweise als Transaktio- nen modelliert. Die resultierenden Modelle werden als Transaktionsebenenmodelle (engl. Transaction Level Models, TLMs) bezeichnet. Transaktionsebenenmodelle spielen bei der Verifikation des Zeitverhaltens be- reits heutzutage eine zentrale Rolle. Der Grund hierf ¨ ur ist, dass TLMs aufgrund der hohen Abstraktionsebene eine schnelle Simulation erm ¨ oglichen. Dabei liefern sie bereits gute Absch ¨ atzungen f ¨ ur nichtfunktionale Eigenschaften. Neben der Ver- besserung simulativer Verfahren zur Verifikation des Zeitverhaltens, gab es in den letzten zehn Jahren enorme Fortschritte im Bereich der formalen Verifikation des Zeitverhaltens auf der Systemebene. Im Folgenden werden Ans ¨ atze zur Eigenschaftspr ¨ ufung auf der Systemebene behandelt. Dabei werden zun ¨ achst formale Modellpr ¨ ufungsverfahren f ¨ ur SystemC- Verhaltensmodelle pr ¨ asentiert. Anschließend werden formale und simulative Ver- fahren zur funktionalen Eigenschaftspr ¨ ufung von SystemC-Transaktionsebenenmo- dellen vorgestellt. Zum Abschluss werden simulative und formale Methoden zur Zeitanalyse auf Systemebene diskutiert. 8.1 Funktionale Eigenschaftspr ¨ ufung von SystemC-Modellen Im Folgenden werden Methoden zur funktionalen Eigenschaftspr ¨ ufung von Sys- temC-Modellen vorgestellt. 8.1.1 Symbolische CTL-Modellpr ¨ ufung von SysteMoC-Modellen Dieser Abschnitt ist der symbolischen CTL-Modellpr ¨ ufung von SysteMoC-Modellen (siehe Abschnitt 2.3.2) gewidmet. Die prinzipielle Vorgehensweise i st in [191] be- schrieben. Diese basiert auf Arbeiten ¨ uber symbolische Techniken f ¨ ur FunState- Modelle, wie sie in [414] zusammengefasst sind. Im Folgenden wird zun ¨ achst der Zustandsraum eines SysteMoC-Modells genauer definiert und dieser anschließend mit Hilfe von Intervall-Entscheidungsdiagrammen symbolisch repr ¨ asentiert. Die symbolische Modellpr ¨ ufung wird anschließend diskutiert. Repr ¨ asentation des Zustandsraums F ¨ ur die sp ¨ ater vorgestellte symbolische CTL-Modellpr ¨ ufung wird eine symboli- sche Darstellung von Zust ¨ anden und Zustands ¨ uberg ¨ angen von SysteMoC-Modellen ben ¨ otigt. Aufgrund der Komplexit ¨ at von SysteMoC-Modellen wird bei der Re- pr ¨ asentation der Zustandsr ¨ aume eine Abstraktion auf das zugrundeliegende FunState- Modell betrachtet. Dabei werden Datenwerte nicht ber ¨ ucksichtigt. Der (abstrakte) 8.1 Funktionale Eigenschaftspr ¨ ufung von SystemC-Modellen 453 Zustand eines SysteMoC-Modells ist dann durch die momentanen Zust ¨ ande der end- lichen Automaten der Aktoren im SysteMoC-Modell und die F ¨ ullst ¨ ande der Kan ¨ ale gegeben. Regul ¨ are Zustandsautomaten Der abstrakte Zustandsraum eines SysteMoC-Modells ist aufgrund der unbeschr ¨ ank- ten FIFO-Kan ¨ ale potentiell unendlich groß. Eine endliche Repr ¨ asentation des Zu- standsraums f ¨ ur SysteMoC-Modelle kann allerdings ¨ uber sog. Regul ¨ are Zustandsau- tomaten (engl. Regular State Machines, RSMs) [434] erreicht werden. RSMs sind daf ¨ ur geeignet, regul ¨ are Zustands ¨ anderungen von nebenl ¨ aufigen Kon- troll- und/oder Datenflussmodellen (unter anderem Petri-Netze, FunState- und Sys- teMoC-Modellen) zu beschreiben. Dabei k ¨ onnen RSMs bestimmte Klassen von un- endlichen Zustandssystemen modellieren und erweitern die Klasse der endlichen Au- tomaten. RSMs werden hier lediglich in einer eingeschr ¨ ankten Form vorgestellt und ¨ uber ihre graphischen Repr ¨ asentationen als statische und dynamische Zustands ¨ uber- gangsdiagramme eingef ¨ uhrt. Erweiterungen sind in [434] zu finden. Definition 8.1.1 (Statisches Zustandsdiagramm einer RSM). Ein statisches Zu- stands ¨ ubergangsdiagramm ist ein gerichteter Graph G =(V,E,D,P,v 0 ,I 0 ) mit • einer Menge von Knoten V , • einer Menge gerichteter Kanten E ⊆ V ×V, • einer Funktion D : E → Z m , die jeder Kante e =(v i ,v j ) ∈ E einen Distanzvektor ganzer Zahlen d(e)=d(v i ,v j ) ∈ Z m der Dimension m zuordnet, • einer Pr ¨ adikatenfunktion P : E × Z m → B, die jeder Kante e ∈ EeinPr ¨ adikat P(e,I) zuordnet und • einem Knoten v 0 ∈ V und einem Vektor I 0 ∈ Z m , die den Anfangszustand bilden. Das statische Zustands ¨ ubergangsdiagramm ist eine abk ¨ urzende Schreibweise f ¨ ur das m ¨ oglicherweise unendliche, dynamische Zustands ¨ ubergangsdiagramm einer RSM. Das dynamische Zustands ¨ ubergangsdiagramm ergibt sich, indem die Zust ¨ ande des statischen Zustands ¨ ubergangsdiagramms an jeden g ¨ ultigen Indexpunkt, der sich aus den Distanzvektoren unter Ber ¨ ucksichtigung der Pr ¨ adikate ergibt, kopiert wer- den, und anschließend die Zustands ¨ uberg ¨ ange entsprechend zwischen den Zust ¨ anden und Indexpunkten eingetragen werden. Definition 8.1.2 (Dynamisches Zustands ¨ ubergangsdiagramm einer RSM). Das dynamische Zustands ¨ ubergangsdiagramm G d =(X,T,x 0 ) eines gegebenen stati- schen Zustands ¨ ubergangsdiagramms G =(V, A,D,P,v 0 ,I 0 ) ist ein unendlicher, ge- richteter Graph, der wie folgt definiert ist: • Die Knoten x ∈ X repr ¨ asentieren (dynamische) Zust ¨ ande des dynamischen Zu- stands ¨ ubergangsdiagramms. Es gilt X = V × Z m mit der Indexmenge des dyna- mischen Zustands ¨ ubergangsdiagramms Z m . Der Knoten x =(v,I) ∈ X bezeich- net den Zustand f ¨ ur einen Knoten v ∈ V eines statischen Zustands ¨ ubergangsdia- gramms und einen Indexpunkt I ∈ Z m . [...]... SqrLoop u als IMD [191] ¨ Modellprufung von SysteMoC-Modellen ¨ Abbildung 8.8 zeigt einen Uberblick der symbolischen CTL-Modellpr¨ fung von u SysteMoC-Modellen Zun¨ chst wird aus der Spezifikation eines digitalen Systems a ¨ das SysteMoC-Verhaltensmodell mittels eines Parsers in eine RSM ubersetzt, welche als IDD/IMD symbolisch repr¨ sentiert wird Die funktionalen Anforderungen an a das System liegen... von SystemC-Modellen Der oben beschriebene IDD-basierte Ansatz zur Modellpr¨ fung von SysteMoCu Modellen pr¨ ft funktionale Eigenschaften direkt auf dem Verhaltensmodell, welches u unabh¨ ngig von der Hardware/Software-Partitionierung ist Allerdings liegen bereits a oft SystemC-Module vor, die eine Hardware- oder eine Software-Implementierung eines oder mehrerer Aktoren darstellen In [271] ist ein spezialisierter . 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