Digitale Hardware/ Software-Systeme- P26 pps

Man beachte, dass eine VPC so konfiguriert werden kann, dass jede Funktion ei-ne andere Ausf¨uhrungszeit erh¨alt.. Modellierung dynamischer Ablaufplanungsstrategien Aufgrund der Nebenl¨a

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 a0 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 f0, f1, f0, f3und f2aktiviert 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 a0blockiert 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

FCFS

Laufzeit der Simulation

f0

f1

f0

f3

f2

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 a0zur¨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

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 RessourcenkonflikKomponen-te 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 AblaufplanungsAblaufplanungs-strategie ist eine pr¨aemptive priorit¨atsbasierte Ablaufplanung (PPrio) Man sieht, dass die Verz¨ogerung des

Ak-tors a1durch die Unterbrechung durch den Aktor a0vergr¨oßert wird

VPC Anwendung

assign return

return

compute(a1, f1 )

compute(a0, f0 )

o0[0] = f0();

f1(i0[0]);

VPC::compute(a0, f0);

VPC::compute(a1, f1);

block block

DSP

f0

f1

ready

assign resign ready assign

Abb 8.23 Pr¨aemptive Ablaufplanung in der VPC-Bibliothek

In Abb 8.23 wird zun¨achst Aktor a1 gestartet, der die Funktion f1 berechnet Durch den Funktionsaufruf VPC::compute(a1, f1) erfolgt die Bindung des Ak-tors an die Komponente DSP Die Angabe des AkAk-tors (a1) und der ausgef¨uhrten

Funktion (f1) erm¨oglicht die Ermittlung der richtigen Ausf¨uhrungszeit f¨ur die

Kern-funktionalit¨at der Funktion f1auf 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 a1zu (Signal assign) Die VPC DSP simuliert nun mittels einer SystemC-wait-Anweisung die Ausf¨uhrungszeit der

Funktion f1

Die Simulation der Ausf¨uhrungszeit wird allerdings durch die Aktivierung des

Aktors a0 unterbrochen Dieser f¨uhrt die Funktion f0aus 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 a0 nun ebenfalls zu planen ist In diesem Beispiel wird davon ausgegangen, dass der

Aktor a0 eine h¨ohere Priorit¨at als der Aktor a1 besitzt, weshalb es zur

Unterbre-chung der Zeitsimulation f¨ur Aktor a1kommt (Signal resign) Der Scheduler

spei-chert dabei die noch verbleibende zu simulierende Ausf¨uhrungszeit des Aktors a1

Der Prozessor wird anschließend dem Aktor a0zugeteilt und die VPC DSP ¨ubergibt den Ausf¨uhrungskontext mittels wait-Anweisung

Nachdem die Ausf¨uhrungszeit des Aktors a0 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 a0 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 a1die 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 a1zur¨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-KaKa-n¨ale

Speicher

Bus

DSP a)

DSP: a0

DSP: a1

R

W

W R

W R

R W

simulierte Zeit Overhead des Schedulers

c0

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 Implementierung 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

Speicher b)

a)

write synchronize read synchronize

Target Target Initiator

Initiator Target

Initiator Target Initiator

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 a0 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 a0in 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 a0statt Da die Aktoren a0und a1auf die selbe Res-source gebunden sind, treten keine externen Ereignisse auf Anschließend folgt die

read-Transaktion des Aktors a1 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 a1seine Berechnung durchf¨uhren

Speicher

Bus

DSP

write

simulierte Zeit

read

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

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 schlechtebesse-ren 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:

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, so k¨onnen innerhalb einer PePe-riode 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 j0den 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

P J

P

τi= τi+1− P

− J

2≤ j i ≤ J

2

τi = i · P + j i + j0mit

τi = i · P + j i + j0mit

− 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]

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 CaCa-se 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

p1

p2

p3 Anwendung

RSST + BCETs/WCETs

Echtzeitanalyse

analysiert

berechnet beschr¨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 p1kompatibel zum erwarteten Eingabeereignisstrom von p2 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

RSST1

p1

RSST1 a)

?

p1

RSST1

p1

RSST1

EMIF X → Y

p1

RSST1

EMIF X → Y

EAF X → Y

p1

Ereignismodell Y Ereignismodell X

b)

c)

Ereignismodell X

Ereignismodell X

Ereignismodell Y

Ereignismodell Y

RSST1

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 ErEr-eignismodell 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 EreignismoEreignismo-dell 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 wievor¨ubergehen-der ein periodischer Ereignisstrom erzeugt werden Dabei k¨onnen die Verz¨ogerung eines Ereignisses und die ben¨otigte

Puf-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 Burst periodisch

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

F¨ur die Umwandlung mit Adaptierung sind weitere Schritte notwendig Bei-spielsweise l¨asst sich ein periodischer Ereignisstrom mit Jitter nicht durch einen rein