494 8 Systemverifikation Beispiel 8.2.1. Die Funktionsweise einer VPC sowie die Kopplung mit einem Syste- MoC-Aktor ist in Abb. 8.22 dargestellt. Auf der linken Seite in Abb. 8.22 sieht man die Aktivierungen des SysteMoC-Aktors a 0 . Die Laufzeit der Simulation steigt dabei nach unten an. Man beachte, dass in Abb. 8.22 zwei Zeitskalen verwendet werden: Zum einen die Laufzeit der Simulation, zum anderen die simulierte Zeit. Es wer- den nacheinander die Funktionen f 0 , f 1 , f 0 , f 3 und f 2 aktiviert. Die Berechnung der Funktionen ben ¨ otigt jeweils den grau schraffierten Bereich an Simulationszeit. Man sieht, dass nach jeder Berechnung einer Funktion die VPC DSP aufgerufen wird und w ¨ ahrenddessen die Ausf ¨ uhrung des Aktors a 0 blockiert ist. 100ns 100ns 100ns 100ns 100ns 100ns 100ns 100ns simulierte Zeit Anwendung Bindung Architektur 100 μ s 100 μ s 300 μ s 100 μ s 200 μ s 100 μ s 100 μ s FCFSa 0 DSP Laufzeit der Simulation f 0 f 1 f 0 f 3 f 2 Abb. 8.22. Kombinierte Verhaltens- und Zeitsimulation Die VPC gibt den Aufruf an einen assoziierten Scheduler mit FCFS-Algorithmus (engl. First Come, First Served) weiter. Der Scheduler kennt die gesch ¨ atzten Ausf ¨ uh- rungszeiten des Aktors und simuliert die entsprechende Zeit durch eine wait- Anweisung in SystemC. Die simulierte Zeit w ¨ achst in Abb. 8.22 ebenfalls nach unten an. Erst danach gibt der Scheduler ¨ uber die VPC die Kontrolle an den Ak- tor a 0 zur ¨ uck. Hierdurch kann der Aktor seinen neuen Zustand einnehmen und die Daten von den Eingangsports konsumieren und auf den Ausgangsports produzieren. Anschließend kann der Aktor gegebenenfalls die n ¨ achste Funktion ausf ¨ uhren. Man beachte, dass eine VPC so konfiguriert werden kann, dass jede Funktion ei- ne andere Ausf ¨ uhrungszeit erh ¨ alt. Es ist sogar m ¨ oglich, dass diese Ausf ¨ uhrungszeit abh ¨ angig von dem Berechnungspfad der Funktion dynamisch gesetzt wird. Weiterhin 8.2 Zeitanalyse auf Systemebene 495 k ¨ onnen die Verz ¨ ogungszeiten von W ¨ achterfunktionen (engl. guards), die als Bedin- gungen an Zustands ¨ uberg ¨ angen annotiert sind, ebenfalls mit Hilfe von VPCs simu- liert werden. Um die oben beschriebene Ausf ¨ uhrungssemantik aber nicht unn ¨ otig kompliziert zu machen, wird hier auf eine weitere Diskussion dieses Aspektes ver- zichtet. Modellierung dynamischer Ablaufplanungsstrategien Aufgrund der Nebenl ¨ aufigkeit von Aktoren in einem SysteMoC-Modell kann es zu Ressourcenkonflikten kommen, sobald mehr als ein Aktor an die selbe Komponen- te gebunden ist. Um diese Ressourcenkonflikte aufzul ¨ osen, wird jede VPC mit ei- ner Ablaufplanungsstrategie konfiguriert. Diese Strategien k ¨ onnen pr ¨ aemptiv oder nichtpr ¨ aemptiv sein. Die Ablaufplanungsstrategien liegen in der Bibliothek als C++- Klassen mit einheitlichem Interface vor. Als Ablaufplanungsstrategien k ¨ onnen u. a. RR, FCFS oder priorit ¨ atsbasierte Verfahren zum Einsatz kommen. Zur Realisierung pr ¨ aemptiver Ablaufplanungsstrategien definiert die VPC-Bi- bliothek ein Interface zum Scheduler. Der Scheduler implementiert die Ablaufpla- nungsstrategie und wird, wie Abb. 8.22 zeigt, von der assoziierten VPC aufgerufen. Die Schnittstelle zwischen VPC und Scheduler f ¨ ur eine pr ¨ aemptive Ablaufplanungs- strategie ist in Abb. 8.23 dargestellt. Die Ablaufplanungsstrategie ist eine pr ¨ aemptive priorit ¨ atsbasierte Ablaufplanung (PPrio). Man sieht, dass die Verz ¨ ogerung des Ak- tors a 1 durch die Unterbrechung durch den Aktor a 0 vergr ¨ oßert wird. VPCAnwendung assign return return compute(a 1 , f 1 ) compute(a 0 , f 0 ) o0[0] = f0(); f1(i0[0]); VPC::compute(a0, f0); VPC::compute(a1, f1); block block DSPa 0 a 1 PPrio f 0 f 1 ready assign resign ready assign Abb. 8.23. Pr ¨ aemptive Ablaufplanung in der VPC-Bibliothek In Abb. 8.23 wird zun ¨ achst Aktor a 1 gestartet, der die Funktion f 1 berechnet. Durch den Funktionsaufruf VPC::compute(a1, f1) erfolgt die Bindung des Ak- tors an die Komponente DSP. Die Angabe des Aktors (a1) und der ausgef ¨ uhrten 496 8 Systemverifikation Funktion (f1)erm ¨ oglicht die Ermittlung der richtigen Ausf ¨ uhrungszeit f ¨ ur die Kern- funktionalit ¨ at der Funktion f 1 auf dem digitalen Signalprozessor entsprechend der Konfiguration. Die VPC-Bibliothek k ¨ ummert sich darum, dass entsprechend der Bindung des Aktors der Aufruf an die richtige VPC weitergeleitet wird. Die VPC DSP ihrerseits benachrichtigt den Scheduler mittels des ready-Signals. Der Schedu- ler PPrio teilt daraufhin die Ressource dem Aktor a 1 zu (Signal assign). Die VPC DSP simuliert nun mittels einer SystemC-wait-Anweisung die Ausf ¨ uhrungszeit der Funktion f 1 . Die Simulation der Ausf ¨ uhrungszeit wird allerdings durch die Aktivierung des Aktors a 0 unterbrochen. Dieser f ¨ uhrt die Funktion f 0 aus und initiiert die Zeitsi- mulation mittels des Funktionsaufrufs VPC::compute(a0, f0). Die Komponente DSP informiert den Scheduler PPrio mittels des ready-Signals, dass der Aktor a 0 nun ebenfalls zu planen ist. In diesem Beispiel wird davon ausgegangen, dass der Aktor a 0 eine h ¨ ohere Priorit ¨ at als der Aktor a 1 besitzt, weshalb es zur Unterbre- chung der Zeitsimulation f ¨ ur Aktor a 1 kommt (Signal resign). Der Scheduler spei- chert dabei die noch verbleibende zu simulierende Ausf ¨ uhrungszeit des Aktors a 1 . Der Prozessor wird anschließend dem Aktor a 0 zugeteilt und die VPC DSP ¨ ubergibt den Ausf ¨ uhrungskontext mittels wait-Anweisung. Nachdem die Ausf ¨ uhrungszeit des Aktors a 0 vollst ¨ andig simuliert ist, benach- richtigt die Komponente DSP den Scheduler PPrio mittels des block-Signals. Zur selben Zeit kehrt auch der Funktionsaufruf VPC::compute(a0, f0) zum Aktor a 0 zur ¨ uck. Dieser nimmt nun die Aktualisierung des Systemzustands vor, d. h. er setzt den Folgezustand in dem endlichen Automaten des Aktors und produziert das Datum auf dem Kanal. Der Scheduler wiederum teilt dem Aktor a 1 die Komponente DSP zur weiteren Zeitsimulation zu (Signal assign). Dabei wird der VPC die verbleibende zu simulierende Ausf ¨ uhrungszeit mitgeteilt. Ist auch diese abgelaufen, wird der Schedu- ler benachrichtigt (Signal block) und der Funktionsaufruf VPC::compute(a1, f1) kehrt zum Aktor a 1 zur ¨ uck. Dieser nimmt daraufhin in seinem endlichen Automaten den Folgezustand ein und konsumiert das verarbeitete Datum vom Kanal. Neben priorit ¨ atsbasierten Ablaufplanungsstrategien k ¨ onnen ebenfalls zeitgetrie- bene Verfahren zum Einsatz kommen. Beispiel 8.2.2. Abbildung 8.24a) zeigt ein SysteMoC-Modell bestehend aus zwei Aktoren und einem Kanal. Das SysteMoC-Modell ist auf eine Architektur bestehend aus einem DSP, einem Bus und einem Speicher abgebildet. In Abb. 8.24b) sind po- tentielle Ressourcenkonflikte f ¨ ur die beiden Aktoren auf dem DSP zu sehen. Diese Konflikte werden durch einen RR-Scheduler aufgel ¨ ost. Darin bedeutet W, der Ak- tor ist ausf ¨ uhrungsbereit, die Ressource ist aber anderweitig belegt, und R bedeutet, die Ressource ist momentan dem Aktor zugeordnet. Weiterhin kann man erkennen, dass ein zus ¨ atzlicher Overhead f ¨ ur den Scheduler simuliert werden kann, der anf ¨ allt, wenn einem neuen Aktor eine Ressource zugeteilt wird. Modellierung der Kommunikationslatenzen Kommunikation zwischen SysteMoC-Aktoren ist auf dedizierte Punkt-zu-Punkt Ka- n ¨ ale mit FIFO-Semantik beschr ¨ ankt (siehe Abschnitt 2.3.2). Diese SysteMoC-Kan ¨ ale 8.2 Zeitanalyse auf Systemebene 497 b) Speicher Bus DSP a) a 0 a 1 DSP: a 0 DSP: a 1 R W W R WR RW simulierte Zeit Overhead des Schedulers c 0 Abb. 8.24. a) Allokation und Bindung eines SysteMoC-Modells und b) Ressourcenkonflikt auf dem DSP ¨ ubernehmen dabei drei Aufgaben: 1) den Datentransport sowie 2) die Datenspei- cherung und 3) die Synchronisation zwischen Aktoren. Die Implementierung eines SysteMoC-Kanals muss somit diese drei Aspekte unterst ¨ utzen. Dies resultiert in ei- ner Abbildung des Datenpuffers auf einen physikalischen Speicher sowie der De- finition von Transaktionen f ¨ ur Speicherzugriffe und der Synchronisation. In heuti- gen Mehrprozessorsystemen werden die Transaktionen typischerweise ¨ uber mehrere Ressourcen geroutet. Beispiel 8.2.3. Eine generische Implementierung eines SysteMoC-Kanals noch obi- gem Schema ist in Abb. 8.25 dargestellt. Abbildung 8.25a) zeigt ein SysteMoC- Modell bestehend aus zwei Aktoren und einem Kanal. Die beiden Aktoren werden derart verfeinert, dass f ¨ ur jeden Lese- und Schreibport eine Schnittstelle bestehend aus drei Sockets entsteht. Ein Initiator-Socket ist dann f ¨ ur die I mplementierung der Lese- bzw. Schreibtransaktionen zust ¨ andig. Der andere Initiator-Socket ¨ ubernimmt die Benachrichtigung des adjazenten Aktors ¨ uber erfolgte Lese- bzw. Schreibzugrif- fe. Der Target-Socket nimmt diese Benachrichtigungen vom anderen Aktor entge- gen. Die oben skizzierte Implementierung eines SysteMoC-Kanals gibt die Modellie- rung in der Zeitsimulation vor. Prinzipiell erfolgt die Zeitsimulation f ¨ ur die Kom- munikation identisch zur Zeitsimulation von Berechnungen auf VPCs. Allerdings k ¨ onnen bei der Kommunikation mehrere Ressourcen beteiligt sein, so dass ein compute-Aufruf f ¨ ur die Kommunikation von mehreren VPCs abgearbeitet werden muss. 498 8 Systemverifikation Speicher b) a) a 0 a 1 write read write synchronize read synchronize Target TargetInitiator Initiator Target Initiator Target Initiator a 0 c 0 a 1 Abb. 8.25. Implementierung eines SysteMoC-Kanals in einem Mehrprozessorsystem Beispiel 8.2.4. F ¨ ur das SysteMoC-Modell aus Beispiel 8.2.2 mit der Implemen- tierung des SysteMoC-Kanals aus Abb. 8.25 ergibt sich dann der Ablaufplan in Abb. 8.26. In diesem Beispiel, blockiert der DSP beim Schreiben der Daten von Aktor a 0 . Der Bus und der Speicher werden sukzessive f ¨ ur andere Zugriffe gesperrt. Da dies in diesem Fall keine Zeit verbraucht, ist die Blockierung des Aktors a 0 in Abb. 8.26 nicht zu sehen. Nachdem die Route vom DSP zum Speicher aufgebaut ist, findet die write-Transaktion statt. Ist diese erfolgreich abgeschlossen, findet die Synchronisation mit dem Aktor a 0 statt. Da die Aktoren a 0 und a 1 auf die selbe Res- source gebunden sind, treten keine externen Ereignisse auf. Anschließend folgt die read-Transaktion des Aktors a 1 .Daf ¨ ur wird wiederum zun ¨ achst die Route aufgebaut und somit der DSP, der Bus und der Speicher blockiert. Nach dem Lesen der Daten kann Aktor a 1 seine Berechnung durchf ¨ uhren. Speicher Bus DSP write simulierte Zeit read a 0 a 1 Abb. 8.26. Ablauf der Kommunikation zwischen zwei SysteMoC-Aktoren Zeitanalyse mit der VPC-Bibliothek Zur Zeitanalyse mittels der VPC-Bibliothek liegt das Verhaltensmodell als Syste- MoC-Modell vor. Die Architektur- und Bindungsinformationen werden in einer 8.2 Zeitanalyse auf Systemebene 499 Konfigurationsdatei angegeben. W ¨ ahrend der Elaborationsphase des SystemC-Mo- dells konfiguriert sich die VPC-Bibliothek mittels der gegebenen Konfigurationsda- tei, die ebenfalls die gesch ¨ atzten Ausf ¨ uhrungszeiten der Kernfunktionalit ¨ at der Akto- ren enth ¨ alt. In dieser Elaborationsphase, legt die VPC-Bibliothek f ¨ ur jede allozierte Komponente eine VPC an und instantiiert die assoziierten Scheduler. Dabei werden auch die Informationen f ¨ ur die Ablaufplanung in einer Aktordatenstruktur zusam- mengestellt. Die Aktordatenstruktur enth ¨ alt neben einer eindeutigen Identifikations- nummer, die Ausf ¨ uhrungszeiten, gegebenenfalls Priorit ¨ aten, zugewiesene Zeitschlit- ze, Zeitbudgets etc. Diese Informationen werden w ¨ ahrend der Simulation zur Zeit- bewertung verwendet. Die kombinierte Verhaltens- und Zeitsimulation l ¨ auft dann wie oben beschrie- ben ab. Das Ergebnis ist ein Ausf ¨ uhrungstrace der Simulation. Der Trace enth ¨ alt alle Start- und Endzeitpunkte von Aktorausf ¨ uhrungen. Diese k ¨ onnen anschließend analysiert werden, um somit die erzielte Latenz bzw. den Durchsatz des Systems zu bewerten. 8.2.2 Kompositionale Zeitanalyse ¨ uber Ereignisstr ¨ ome Simulative Verfahren zur Zeitanalyse k ¨ onnen aufgrund ihrer Unvollst ¨ andigkeit im Allgemeinen nicht garantieren, dass sie den schlechtesten oder den besten Fall bei der Bewertung des Zeitverhaltens simulieren. Eine ersch ¨ opfende Simulation, die dies sicherstellen k ¨ onnte, ist aufgrund der hohen Laufzeit meist nicht durchf ¨ uhrbar. For- male Methoden zur Zeitanalyse hingegen sind vollst ¨ andig und k ¨ onnen f ¨ ur das Verifi- kationsziel des Beweises eingesetzt werden, da sie garantieren, dass es keinen besse- ren oder schlechteren Fall als durch die Analyse identifizierte F ¨ alle im Zeitverhalten gibt. Im Folgenden wird eine kompositionale Zeitanalyse vorgestellt. Diese verwendet Ergebnisse aus der Echtzeitanalyse f ¨ ur Einprozessorsysteme (siehe Abschnitt 7.4.2) wieder. Hierf ¨ ur wird die Aktivierung von Prozessen auf einem Prozessor in Form ei- nes sog. Ereignisstroms beschrieben, der das zeitliche Verh ¨ altnis zwischen zwei auf- einander folgender Aktivierungen eines Prozesses beschreibt. Da viele der Echtzeit- analysemethoden f ¨ ur Einprozessorsysteme in der Lage sind, viele unterschiedliche Ereignisstr ¨ ome zu analysieren, kann f ¨ ur jeden Prozess die minimale und maximale Antwortzeit bestimmt werden. Die minimale und maximale Antwortzeit wiederum kann als Ereignisstrom dargestellt und zur Aktivierung weiterer Prozesse (auch auf anderen Ressourcen) verwendet werden. Somit ergeben sich nach und nach f ¨ ur alle Prozesse im System die Aktivierungen und Antwortzeiten, die schließlich zur Be- stimmung von Ende-zu-Ende-Latenzen herangezogen werden. Ereignisstr ¨ ome Die Kopplung der verschiedenen Methoden zur Echtzeitanalyse erfolgt ¨ uber sog. Ereignisstr ¨ ome. Diese beschreiben in welchem zeitlichen Verh ¨ altnis Ereignisse zu- einander stehen. Vier wichtige Klassen von Ereignisstr ¨ omen unter Vernachl ¨ assigung der Offsets zwischen Ereignisstr ¨ omen werden unterschieden: 500 8 Systemverifikation 1. periodisch auftretende Ereignisse: Die einfachste Form eines Ereignisstroms ist das periodische Auftreten eines Ereignisses mit einer Periode P. Unter Ver- nachl ¨ assigung des Offsets gen ¨ ugt der Parameter P, um den gesamten Ereignis- strom zu beschreiben. 2. periodisch auftretende Ereignisse mit Jitter: In der Implementierung von kom- plexen Systemen kann es immer wieder vorkommen, dass z. B. Ressourcen kurz- zeitig nicht verf ¨ ugbar sind. Hierdurch kann es zu leichten Verz ¨ ogerungen bei der Erzeugung periodischer Ereignisse kommen. Diese Verz ¨ ogerungen werden als Jitter J bezeichnet. Der Parameter J gibt an, um wie viel fr ¨ uher bzw. sp ¨ ater nach der eigentlichen Periode ein Ereignis auftreten kann. Der Ereignisstrom kann dann durch die Parameter (P,J) vollst ¨ andig beschrieben werden. 3. periodisch auftretende Ereignisse mit Bursts: Wird der Jitter gr ¨ oßer als eine Pe- riode P,sok ¨ onnen innerhalb einer Periode mehr als zwei Ereignisse auftreten. Dies wird als Burst bezeichnet. In diesem Fall kommt der minimale zeitliche Abstand (d) zweier Ereignisse ins Spiel. Der Parameter d wird auch als minima- le Ankunftszeit bezeichnet. Ein Ereignisstrom, der aus periodisch auftretenden Ereignissen mit Bursts besteht, kann mit den Parametern (P,J, d) vollst ¨ andig be- schrieben werden. Alternativ kann der Ereignisstrom auch mit den Parametern (P,d,b) beschrieben werden, wobei P die Periode, d die minimale Ankunftszeit und b die maximale Anzahl an Ereignissen in einer Periode P darstellen. 4. sporadisch auftretende Ereignisse: Bei sporadischen Ereignissen wird ledig- lich die minimale Ankunftszeit d zweier aufeinander folgender Ereignisse be- schr ¨ ankt. Diese Klassen werden auch als Ereignismodelle bezeichnet. Die Ereignismodelle mit Ausnahme der Klasse sporadischer Ereignisse sind in Abb. 8.27 dargestellt. Darin bezeichnet j 0 den zeitlichen Offset des ersten Auftreten eines Ereignisses und j i−1 den Jitter des i-ten Ereignis. ττ i τ i−1 − τ i > d ττ i J ττ i τ i+1 P PJ P τ i = τ i+1 − P − J 2 ≤ j i ≤ J 2 τ i = i · P + j i + j 0 mit τ i = i · P + j i + j 0 mit − J 2 ≤ j i ≤ J 2 , Bereich in dem Ereignisse auftreten k ¨ onnen a) periodisch: b) periodisch mit Jitter: c) periodisch mit Bursts: Abb. 8.27. Wichtige Ereignisstr ¨ ome [435] 8.2 Zeitanalyse auf Systemebene 501 Bei der Kopplung der Analysemethoden muss allerdings ber ¨ ucksichtigt werden, dass der errechnete Ausgabeereignisstrom eines Prozesses kompatibel zum erwar- teten Eingabeereignisstrom der Zeitanalysemethode zur Aktivierung eines weiteren Prozesses auf der angeschlossenen Komponenten ist. Mit anderen Worten: Die lokale Echtzeitanalyse legt fest, welches Ereignismodell f ¨ ur die Aktivierung der zu analy- sierenden Prozesse erwartet wird und gibt das Analysemodell wiederum in Form eines Ereignismodells zur ¨ uck. Dies ist in Abb. 8.28 dargestellt. Der Teil der Anwen- dung, der auf die gegebene Komponente abgebildet ist, besteht in diesem Fall aus drei Prozessen. Die Komponente selbst hat Einfluss auf die besten (engl. Best Ca- se Execution Time, BCET) und schlechtesten Ausf ¨ uhrungszeiten (engl. Worst Cas e Execution Time, WCET) der einzelnen Prozesse sowie die Strategie, mit der Ressour- cenkonflikte bei der Ausf ¨ uhrung von Prozessen gel ¨ ost werden (engl. Ressource Sha- ring STrategy, RSST). Die Echtzeitanalyse beschr ¨ ankt die Eingabeschnittstelle der Komponente indem es ein Ereignismodell f ¨ ur die Eingabeereignisstr ¨ ome definiert. Mit der Anwendung, den Eingabeereignisstr ¨ omen, den BCETs und WCETs sowie der RSST kann die Echtzeitanalyse die Ausgabeereignisstr ¨ ome bestimmen, welche ¨ uber ein Ausgabe-Interface mit anderen Komponenten ¨ uber eine entsprechende Ein- gabeschnittstelle verbunden werden. p 1 p 2 p 3 Anwendung RSST + BCETs/WCETs Eingabe-Interface Ausgabe-Interface Echtzeitanalyse analysiert berechnetbeschr ¨ ankt Abb. 8.28. Lokale komponentenbasierte Echtzeitanalyse zur kompositionalen Zeitanalyse Ereignisstromkopplung Zentral f ¨ ur die kompositionale Zeitanalyse ist somit die Kopplung von Ereigniss- tr ¨ omen. Dies ist in Abb. 8.29a) zu sehen. Die Frage ist somit, ob der Ausgabeereig- nisstrom des Prozesses p 1 kompatibel zum erwarteten Eingabeereignisstrom von p 2 ist, also die Ereignismodelle kompatibel sind. Um diese Frage zu beantworten, betrachten Richter und Ernst in [378] die vier oben eingef ¨ uhrten Ereignismodelle sowie die M ¨ oglichkeiten, die Parameter dieser 502 8 Systemverifikation p 1 RSST 1 p 1 RSST 1 a) Ausgabe Eingabe ? p 1 RSST 1 p 1 RSST 1 EMIF X→Y p 1 RSST 1 EMIF X→Y EAF X→Y p 1 Ereignismodell YEreignismodell X b) c) Ereignismodell X Ereignismodell X Ereignismodell Y Ereignismodell Y (d) RSST 1 (P,J)(P,J) (P) Abb. 8.29. a) Ereignisstromkopplung mit b) Ereignismodellschnittstelle und c) Ereignisadap- tierung Ereignismodelle ineinander umzurechnen. Dabei identifizieren sie drei Klassen von m ¨ oglichen Umrechnungen: 1. verlustfreie Umwandlung: Bei dieser Klasse von Transformationen kann ein Er- eignismodell X in ein anderes Ereignismodell Y transformiert werden, ohne dass Informationen, die in X gespeichert waren, verloren gehen. Ein Beispiel f ¨ ur eine verlustfreie Umrechnung ist von dem Ereignismodell ” periodische Ereignisse“ in das Ereignismodell ” periodische Ereignisse mit Jitter“, da bei der Umrech- nung der Jitter einfach als null angenommen werden kann. 2. verlustbehaftete Umwandlung ohne Adaptierung: Jedes periodische Ereignismo- dell kann in ein sporadisches Ereignismodell umgerechnet werden. Der Grund hierf ¨ ur liegt darin, dass die minimale Ankunftsrate aus den periodischen Ereig- nisstr ¨ omen berechnet werden kann. Allerdings kann man nach der Transforma- tion aus dem sporadischen Ereignismodell nicht mehr darauf schließen, dass es sich auch um ein periodisches Ereignismodell handelt, w ¨ ahrend solche R ¨ uck- schl ¨ usse bei den verlustfreien Umrechnungen noch m ¨ oglich sind. 3. verlustbehaftete Umwandlung mit Adaptierung: Schließlich gibt es noch Um- rechnungen, die eine Anpassung des Ereignisstrom erfordern. Ein Beispiel hier- f ¨ ur ist die Umwandlung ” periodischer Ereignisse mit Jitter“ in das Ereignismo- dell ” periodische Ereignisse“. Ist der Jitter bekannt, kann durch vor ¨ ubergehen- de Speicherung von Ereignissen wieder ein periodischer Ereignisstrom erzeugt werden. Dabei k ¨ onnen die Verz ¨ ogerung eines Ereignisses und die ben ¨ otigte Puf- 8.2 Zeitanalyse auf Systemebene 503 fergr ¨ oße aus den Parametern des Ereignismodells bestimmt werden. Diese Um- wandlung ist ebenfalls verlustbehaftet. Die Umwandlung der Ereignisstr ¨ ome kann mittels sog. Ereignismodellschnitt- stellen (EMIF) erfolgen. Abbildung 8.29b) zeigt wie ein Ausgabeereignisstrom (P,J) mit Periode P und Jitter J mittels eines EMIF in einen sporadischen Eingabeereig- nisstrom (d) mit minimaler Ankunftszeit d umgewandelt wird. Eine Umwandlung mit Ereignisadaptierung ist in Abb. 8.29c) dargestellt. Zus ¨ atzlich zu dem EMIF wird eine sog. Ereignisadaptierungsfunktion (EAF) ben ¨ otigt. Die m ¨ oglichen Umwandlun- gen von Ereignisstr ¨ omen sind noch einmal in Abb. 8.30 dargestellt. periodisch mit Jitter sporadisch periodisch mit Burstperiodisch verlustfrei mit Adaptierung ohne Adaptierung Abb. 8.30. Umwandlung von Ereignisstr ¨ omen [378] Die Bestimmung der Parameter f ¨ ur Transformationen ohne Adaptierung kann mittels der Vorschriften in Tabelle 8.1 erfolgen. Darin bezeichnet X =(P X ) einen Ereignisstrom mit periodischen Ereignissen mit Periode P X , X =(P X ,J X ) einen pe- riodischen Ereignisstrom mit Periode P X und Jitter J X , und X =(P X ,d X ,b X ) einen periodischen Ereignisstrom mit Periode P X , minimaler Ankunftszeit d X und maxi- mal b X Ereignisse in einer Periode P. Der Ereignisstrom X =(d X ) besteht nur aus sporadischen Ereignissen mit minimaler Ankunftszeit d X . Tabelle 8.1. EMIF f ¨ ur die Umwandlung von Ereignisstr ¨ omen [378] EMIF X→Y Y =(P Y ) Y =(P Y ,J Y ) Y =(P Y ,d Y ,b Y ) Y =(d Y ) X =(P X ) P Y := P X P Y := P X ,J Y := 0 P Y := P X ,d Y := P X ,b Y := 1 d Y := P X X =(P X ,J X ) – P Y := P X ,J Y := J X – d Y := P X − J X X =(P X ,d X ,b X ) – – P Y := P X ,d Y := d X ,b Y := b X d Y := d X X =(d X ) – – – d Y := d X F ¨ ur die Umwandlung mit Adaptierung sind weitere Schritte notwendig. Bei- spielsweise l ¨ asst sich ein periodischer Ereignisstrom mit Jitter nicht durch einen rein . Ermittlung der richtigen Ausf ¨ uhrungszeit f ¨ ur die Kern- funktionalit ¨ at der Funktion f 1 auf dem digitalen Signalprozessor entsprechend der Konfiguration. Die VPC-Bibliothek k ¨ ummert sich darum,