Digitale Hardware/ Software-Systeme- P3 pot

2.2 Formale Verhaltensmodelle 51 Man beachte die Additivit ¨ at des Zeitfortschritts, d. h. (s,v) δ 1 −→ (s,v  ) ∧ (s,v  ) δ 2 −→ (s,v  )=⇒ (s,v) δ 1 + δ 2 −→ (s,v  ) 2.2.3 Datenflussgraphen Datenflussgraphen sind gerichtete Graphen. Die Knotenmenge stellt ¨ ublicherweise eine Menge von Aktivit ¨ aten oder Aktoren dar, die Daten verarbeiten. Die Kanten repr ¨ asentieren den gerichteten Datenfluss. In einem Datenflussgraphen werden die Berechnungen allein durch die Verf ¨ ugbarkeit von Daten gesteuert. Beispiel 2.2.6. Abbildung 2.6 zeigt den Datenflussgraphen zur L ¨ osung einer Diffe- rentialgleichung nach der Euler-Methode. Die Differentialgleichung ist in der Form y  + 3xy  + 3y = 0 gegeben und soll im Intervall [x 0 ,a] mit der Schrittweite dx und Anfangswerten y(x 0 )=y und y  (x 0 )=u numerisch gel ¨ ost werden. Dabei wird f ¨ ur ein Anfangswertproblem der Form y  = f (x,y(x)) mit y(x 0 )=y 0 die N ¨ aherungsfor- mel y(x +dx) ≈ y(x)+dx f (x, y(x )) eingesetzt, um, beginnend mit x 0 ,dieWertevon y(x 0 +idx), i = 1,2, , sukzessiv zu bestimmen. Im Beispiel lautet die Differential- gleichung y  = f (x, y(x), y  (x)) = −3xy  (x) − 3y(x). Die zweifache Anwendung der Euler-Methode liefert hier die L ¨ osung: y  (x + dx)=y  (x)+dx (−3xy  (x) − 3y(x)) und y(x + dx)=y(x)+dx y  (x). Neben dem eigentlichen Datenflussgraphen sind hier auch Ein- und Ausgangsdaten (gestrichelt) dargestellt. Die Kommunikationsregel eines Datenflussgraphen entspricht der Kommunikati- onsregel desjenigen Petri-Netzes, das man erh ¨ alt, wenn man die Knoten als Transitio- nen modelliert und die Kanten als mit den Transitionen verbundene Stellen auffasst. Eingangskanten von Knoten ohne Vorg ¨ anger werden durch Stellen ohne Vorbereich ersetzt, Ausgangskanten von Knoten ohne Nachfolger werden durch Stellen ohne Nachbereich ersetzt. Markierte Graphen Markierte Graphen [113] sind Datenflussgraphen mit speziellen Eigenschaften. Ein Beispiel eines markierten Graphen ist in Abb. 2.7a) dargestellt. Ein markierter Graph l ¨ asst sich ebenfalls als Petri-Netz beschreiben, in dem jede Stelle genau eine Transi- tion im Vorbereich und genau eine Transition im Nachbereich hat. Definition 2.2.16 (Markierter Graph). Ein markierter Graph entspricht einem Pe- tri-Netz G(P,T, F,K,W,M 0 ) mit den Eigenschaften: 1. ∀p ∈ P : |•p| = |p •|= 1 2. ∀p ∈ P : K(p)=∞ 3. ∀ f ∈ F : W( f )=1 52 2 Spezifikation digitaler Systeme 33uxdxyudxxdx x 1 adx y y 1 c u u 1 Abb. 2.6. Datenflussgraph zur L ¨ osung einer Differentialgleichung nach der Euler-Methode Diese Definition ist nur korrekt unter der Annahme, dass die Konsumption und Pro- duktion von Daten aus Stellen in der Reihenfolge der Ankunft erfolgt. Obwohl das Modell des Petri-Netzes keine Information ¨ uber Ankunftsreihenfolge oder Ankunfts- zeitpunkte der Marken besitzt, wird bei allen im Folgenden vorgestellten Datenfluss- graphen implizit von dieser Annahme Gebrauch gemacht. Sieht man von der Markierung ab, so sind markierte Graphen dual zu Zustands- automaten. Dies wird z. B. an dem in Abb. 2.7 dargestellten Beispiel deutlich. Kno- ten im markierten Graphen entsprechen Transitionen im Petri-Netz und Kanten im markierten Graphen entsprechen Stellen im Petri-Netz. a 1 a 0 a 2 a) b) Abb. 2.7. a) Modell eines markierten Graphen und b) Darstellung als Petri-Netz 2.2 Formale Verhaltensmodelle 53 Die ¨ ubliche Interpretation dieser Klasse von Netzen ist die Assoziation von Akti- vit ¨ aten (z. B. Prozesse, Operationen) mit Transitionen und die Assoziation von Stel- len mit einem Datenpuffer mit der Semantik eines FIFO-Speichers (engl. First In, First Out). Markierte Graphen besitzen eine geringere Ausdruckskraft als allgemei- ne Petri-Netze: So k ¨ onnen Verzweigungen nicht dargestellt werden. Sie sind somit konfliktfrei und k ¨ onnen damit nur deterministisches Verhalten beschreiben. Synchrone Datenflussgraphen (SDF) Interessant f ¨ ur Anwendungen im Bereich der Signalverarbeitung sind Systeme, de- ren Teilsysteme bestimmten Teilaufgaben gewidmet sind und diese dabei mit mehre- ren unterschiedlichen Datenraten arbeiten. Zur Modellierung von Anwendungen der digitalen Signalverarbeitung definieren Lee und Messerschmitt [296] das Modell des synchronen Datenflussgraphen, im Folgenden SDF-Modell (engl. Synchonous Data Flow) genannt. Ein SDF-Graph ist ein um die Eigenschaft, dass die Gewichte von eins verschieden sein k ¨ onnen, erweiterter markierter Graph. SDF-Graphen sind bzgl. des Kommunikationsmodells auch ¨ aquivalent zu einer Teilklasse von Petri-Netzen: Definition 2.2.17 (SDF-Graph). Ein SDF-Graph (synchroner Datenflussgraph) entspricht einem Petri-Netz G(P,T,F,K,W,M 0 ) mit den Eigenschaften: 1. ∀p ∈ P : |•p| = |p •|= 1 2. ∀p ∈ P : K(p)=∞ 3. Jeder Eingangsstelle p einer Transition t ist eine Zahl cons(p,t) := W(p,t) ∈ N zugewiesen 4. Jeder Ausgangsstelle p einer Transition ist eine Zahl prod(t, p) := W(t, p) ∈ N zugewiesen Die Zahlen cons und prod werden als Konsumptions- bzw. Produktionsrate bezeichnet und werden in SDF-Graphen mit den Kanten assoziiert. Abbildung 2.8 zeigt ein Beispiel eines SDF-Graphen. Die Gewichte prod werden als Zahlen am An- fangsknoten einer Kante, die Gewichte cons als Zahlen am Endknoten einer Kante dargestellt. Im Folgenden werden Erweiterungen des SDF-Modells betrachtet. Zyklostatischer Datenfluss Eine Erweiterung des SDF-Modells von Engels und Bilsen [153] erlaubt, dass jeder Knoten v i im Graphen eine Menge von P i Konsumptionsraten cons(v j ,v i ) k und Produktionsraten prod(v i ,v j ) k mit k = 0, ,P i − 1 besitzen kann. Die Zahlen gel- ten f ¨ ur genau eine Feuerung und sind alle P i Iterationen von Aktorfeuerungen zyklisch abwechselnd g ¨ ultig. Durch diese Erweiterung k ¨ onnen z. B. bestimmte zu- standsabh ¨ angige Aktoren (siehe z. B. in Abb. 2.9) dargestellt werden. 54 2 Spezifikation digitaler Systeme 1 1 1 1 1 2 a 0 a 1 a 2 Abb. 2.8. Ein SDF-Graph. Marken sind durch schwarze Punkte dargestellt. Beispiel 2.2.7. Gegeben ist die Struktur eines Multiplexers gem ¨ aß Abb. 2.9a), der die Eing ¨ ange a und b besitzt und die Funktion erf ¨ ullen soll, abwechselnd Daten von Ein- gang a bzw. Eingang b an den Ausgang c zu kopieren. In der funktionalen Beschrei- bung erreicht man dies beispielsweise durch ein Zustandsbit s, das sich zyklisch von 0 auf 1 ¨ andert, um den n ¨ achsten zu selektierenden Eingang zu w ¨ ahlen. v 0 v 1 [1,0] [1,1] [0,1] v 3 v 2 s=1; c = value(a); if (s == 0) { } else { s=0; c = value(b); } b) Zyklostatischer Aktora) Multiplexer c a b Abb. 2.9. Darstellung eines Multiplexers mit zwei Eing ¨ angen a) als Pseudocode und b) als zyklostatisches Datenflussmodell Abbildung 2.9b) zeigt eine Darstellung mit einem zyklostatischen Aktor v 2 mit Periodizit ¨ at P 2 = 2. Der Knoten besitzt damit zwei Zust ¨ ande. Im Zustand s = 0ist der Knoten feuerbereit, wenn an dem Eingang a mindestens ein Datum anliegt. Beim Feuern wird nun nur vom Eingang a ein Datum konsumiert und an den Ausgang kopiert. Dann wechselt der Knoten in den Zustand s = 1. Nun ist der Knoten feuerbereit, wenn mindestens ein Datum an Eingang b liegt. Diese beiden Zust ¨ ande des Aktors wiederholen sich zyklisch. Die Konsumptions- und Produktionsraten f ¨ ur Ak- tor v 2 sind in folgender Tabelle zusammengefasst: k cons(v 0 ,v 2 ) cons(v 1 ,v 2 ) prod(v 2 ,v 3 ) 0 101 1 011 2.2 Formale Verhaltensmodelle 55 Engels et al. zeigten [153], wie sich die f ¨ ur SDF-Graphen interessanten Eigen- schaften, insbesondere Existenz von Verklemmungen, periodische Planbarkeit und Beschr ¨ anktheit, auch auf zyklostatischen Datenflussgraphen (engl. Cyclo-Static Da- ta Flow, CSDF) ermitteln lassen. Dynamische Datenflussmodelle Die wesentlichen Einschr ¨ ankungen bisher vorgestellter Datenflussmodelle sind, dass sich keine allgemeinen Kontrollstrukturen, beispielsweise datenabh ¨ angige Schleifen oder IF-THEN-ELSE-Konstrukte, darstellen lassen. Es k ¨ onnen hier nicht alle be- kannten, wichtigen Datenflussmodelle behandelt werden. Statt dessen wird gezeigt, dass bereits geringf ¨ ugige Modellerweiterungen der bisher vorgestellten Modelle zu einer M ¨ achtigkeitserweiterung auf Turing- ¨ Aquivalenz f ¨ uhren. Das hat zur Folge, dass die Analyse von Eigenschaften wie Beschr ¨ anktheit unentscheidbar wird. Betrachtet wird die folgende Erweiterung des SDF-Modells von Buck [70]: Buck nennt alle Knoten, die eine konstante (bekannte) Anzahl von Daten konsumieren und produzieren, regul ¨ are Aktoren, und Datenflussgraphen, die nur regul ¨ are Aktoren besitzen, regul ¨ are Datenflussgraphen. Dazu geh ¨ oren markierte Graphen und SDF- Graphen. Bei dynamischen Aktoren muss nun die Anzahl von Daten, die entlang einer Kante konsumiert bzw. produziert werden, nicht mehr konstant sein. In der Regel h ¨ angen diese Zahlen von den Werten der Eingangsdaten ab. Besitzt ein Modell solche Aktoren, so handelt es sich um einen dynamischen Datenflussgraphen. Buck [70] erweiterte das SDF-Modell um zwei dynamische Aktoren SWITCH und SELECT, und nennt die Klasse von Datenflussgraphen, die aus einer beliebigen Kombination von SDF-Knoten und SWITCH- und SELECT-Knoten bestehen, BDF (engl. Boolean-controlled Data Flow). Gegen ¨ uber regul ¨ aren Aktoren kann bei den SWITCH- und SELECT-Aktoren die Anzahl der konsumierten bzw. produzierten Daten eine zweiwertige Funktion des Wertes, einer sog. Steuerungsmarke (engl. control token), sein. Das Verhalten wird durch einen Steuereingang bestimmt, der in jeder Ausf ¨ uhrung genau ein Datum, die Steuerungsmarke, konsumiert. Buck zeig- te, dass das um diese Aktoren erweiterte SDF-Modell Turing- ¨ aquivalent (berech- nungsuniversell) ist. Jedoch l ¨ asst sich zeigen, dass sich gewisse Teilgraphen eines BDF-Graphen durch Clustering zusammenfassen lassen und dadurch zumindest auf Teilgraphen statische Analyseverfahren wie auf SDF-Graphen angewendet werden k ¨ onnen. Alle hier betrachteten Datenflussmodelle besitzen die Eigenschaft, determinis- tisch zu sein, d. h., dass bei beliebigen Ausf ¨ uhrungsreihenfolgen der Knoten die Se- quenz der produzierten Daten jeweils die gleiche ist. Dies ist darin begr ¨ undet, dass alle hier vorgestellten Modelle Spezialf ¨ alle sog. Kahn-Prozessnetzwerke [250] sind, f ¨ ur die Kahn Determinismus bewiesen hat. In einem Kahn-Prozessnetzwerk (KPN) sind Lesezugriffe auf Kommunikationskan ¨ ale, die ebenfalls eine FIFO-Semantik besitzen, blockierend. Schreibzugriffe sind aufgrund der unbegrenzt großen Kan ¨ ale immer nichtblockierend. Diesen Sachverhalt stellt Lee in [295] dar, wo er die Zu- sammenh ¨ ange von Datenflussgraphen zu Prozesskalk ¨ ulen und Datenflusssprachen 56 2 Spezifikation digitaler Systeme (engl. auch stream oriented languages)erl ¨ autert. Zu letzteren z ¨ ahlen beispielsweise die Sprachen ESTEREL [44], LUSTRE [212], Lucid [19] und SIGNAL [38]. 2.2.4 Heterogene Modelle Die bisher vorgestellten Modelle haben den Vorteil, dass sie eine bestimmte Eigen- schaft bzw. Sichtweise eines Systems gut beschreiben. W ¨ ahrend solche spezifischen Modelle zwar leichter zu analysieren sind, leiden sie unter ihrer eingeschr ¨ ankten Ausdruckskraft. Um ein komplexes System zu beschreiben, benutzt man also im All- gemeinen heterogene Modelle. Die Natur der Anwendungsgebiete von Hardware/Software-Systemen fordert, dass sowohl Kontrollfluss als auch Datenfluss in einem Modell dargestellt werden k ¨ onnen. Die bisher vorgestellten Modelle eignen sich entweder zur Modellierung von datenflussdominanten oder zur Modellierung von kontrollflussdominanten Sys- temen. Heterogene Graphenmodelle, die beides kombiniert darstellen k ¨ onnen, sind beispielsweise sog. Kontroll-Datenflussgraphen (engl. Control/Data Flow Graphs, CDFGs). Da es unterschiedliche M ¨ oglichkeiten der Definition und zahlreiche Variationen von CDFGs gibt, werden an dieser Stelle nur die wesentlichen Prinzipien nichtformal vorgestellt. Kontroll-Datenflussgraphen (CDFGs) Offensichtlich kann ein Datenflussgraph keine Kontrollstrukturen wie z. B. Verzwei- gungen und Iterationen (z. B. Schleifenkonstrukte) modellieren. Dazu dienen sog. Kontrollflussgraphen (engl. Control Flow Graphs, CFGs). Ein Kontrollflussgraph ist ein gerichteter Graph, in dem den Knoten Berechnungen entsprechen und Kanten Nachfolgerrelationen in einem (sequentiellen) Kontrollfluss ausdr ¨ ucken, nicht aber Datenabh ¨ angigkeiten. Besitzt ein Knoten mehrere Nachfolger, so handelt es sich um einen Verzweigungsknoten. Der von einem Verzweigungsknoten ausgehende Kon- trollfluss ist alternativ, d. h. es wird exakt ein Nachfolgerzweig durchlaufen. Die Auswahl eines Zweigs ist abh ¨ angig von Booleschen Ausdr ¨ ucken, die man ¨ ublicherweise an die Ausgangskanten eines Verzweigungsknotens schreibt. Beispiel 2.2.8. Abbildung 2.10a) zeigt einen Ausschnitt eines C-Programms. Die Aufgabe des Programms sei an dieser Stelle vernachl ¨ assigt. Der zugeh ¨ orige Kon- trollflussgraph ist in Abb. 2.10b) dargestellt: ¨ Ublicherweise assoziiert man mit jedem Knoten eine C-Anweisung (durch Zeilennummern gekennzeichnet). Bei Knoten, die mehr als eine Ausgangskante besitzen (Verzweigungsknoten), ist der Kontrollfluss alternativ. Entsprechende Verzweigungsbedingungen werden an die Ausgangskan- ten geschrieben. Ein Schleifenkonstrukt l ¨ asst sich als eine Verzweigung mit Test auf die Abbruchbedingung der Iteration modellieren. Ein Kontrollflussgraph kann offensichtlich nicht die Datenabh ¨ angigkeiten der Berechnungen darstellen. Das Modell von Kontroll-Datenflussgraphen ist ein he- 2.2 Formale Verhaltensmodelle 57 NOP NOP j=0; ok=true; 1 2 3 if (ok) else { j++; j=0; ok=true; } k++; } r=j; 4 5 6 7 8 9 10 11 b) CDFG: CFG ok = T ok = F 911 7 4 3 6 2 1 NOP NOP +DFGs s=k; s=k; a) C-Programm while (k<10) { k < 10 k ≥ 10 Abb. 2.10. a) Ausschnitt eines C-Programms und b) CDFG. Der CFG bildet mit den Daten- flussgraphen (DFGs) einen CDFG. terogenes Modell, das eine Aufteilung des Verhaltensmodells in kontrollflussdominante und datenflussdominante Anteile vornimmt und damit beide Aspekte in einem Modell vereinigen kann. Beispiel 2.2.9. Gegeben ist der Ausschnitt aus einem C-Programm in Abb. 2.10a). Nun kann man z. B. mit jeder Anweisung einen Datenflussgraphen assoziieren (siehe Abb. 2.10b), der die Berechnung der entsprechenden Anweisung modelliert. Die gestrichelten Knoten (NOP-Operationen) modellieren einen einheitlichen Eintritts- bzw. Austrittspunkt eines Datenflussgraphen (DFGs). Schließlich zeigt Abb. 2.10b) einen weiteren relevanten Aspekt der Definition eines CDFG-Modells: In dem Modell in Abb. 2.10a) besteht kein Grund, die beiden Anweisungen in Zeile 6 und 7 sequentiell auszuf ¨ uhren. Bei der Analyse wird daher ein DFG pro Grundblock (engl. basic block) erzeugt. Ein Grundblock ist eine Folge fortlaufender Anweisungen, in die der Kontrollfluss am Anfang eintritt und die er am Ende verl ¨ asst, ohne dass er, außer am Ende, verzweigt. Im CFG gibt es dann pro Grundblock nur einen Knoten. Die Datenflussgraphen bestimmt man durch Datenflussanalyse (siehe z. B. [4, 343]). 58 2 Spezifikation digitaler Systeme FunState FunState [433, 417] ist ein Akronym f ¨ ur engl. Functions driven by State machines, also Funktionen, die durch Zustandsmaschinen (endliche Automaten) gesteuert bzw. aktiviert werden. Ein nichthierarchisches FunState-Modell besteht dabei aus einem transformativen und einem reaktiven Teil. Der transformative Teil wird durch ein Netzwerk ¨ ahnlich einem Petri-Netz modelliert, der reaktive Teil durch einen endlichen Automaten. Definition 2.2.18 (FunState-Modell [433]). Ein FunState-Modell besteht aus einem Netzwerk N und einem endlichen Automaten M. Das Netzwerk N =(F,S,E) besteht aus einer Menge an Speicherelementen s ∈ S, einer Menge von Funktionen f ∈ F und einer Menge an gerichteten Kanten e ∈ E ⊆ (F × S) ∪ (S × F). Im Gegensatz zu Transitionen in Petri-Netzen erfolgt die Aktivierung der Funk- tionen f ∈ F im FunState-Modell nicht eigenst ¨ andig durch das Vorhandensein von Marken auf den Speicherpl ¨ atzen, sondern durch Zustands ¨ uberg ¨ ange im endlichen Automaten M. Hierbei k ¨ onnen die Bedingungen an den Zustands ¨ uberg ¨ angen von M die Anzahl der Marken in einem Speicherelement oder aber den mit einer Marke assoziierten Wert ber ¨ ucksichtigen. Die Speicherelemente in einem FunState-Modell k ¨ onnen FIFO-Semantik besitzen bzw. Register sein. Im Folgenden wird davon aus- gegangen, dass alle Speicherelemente FIFO-Semantik besitzen. Beispiel 2.2.10. Ein Beispiel eines FunState-Modells ist in Abb. 2.11 zu sehen. Der obere Teil stellt das Netzwerk N dar, welches aus drei Funktionen und zwei Spei- cherelementen besteht. Die Anzahl der Marken in einem Speicherelement s wird mit s# ∈ Z ≥0 bezeichnet. Die Anzahl der anf ¨ anglichen Marken wird mit s# 0 bezeichnet. In Abb. 2.11 ist die Anzahl der anf ¨ anglichen Marken s 0 # 0 = s 1 # 0 = 1. Die Menge der Funktionen F ist gegeben durch F = { f 0 , f 1 , f 2 }. Der untere Teil zeigt den Automa- ten M, welcher zwei Zust ¨ ande besitzt. Die Zustands ¨ uberg ¨ ange sind mit Bedingungen und Aktionen beschriftet. Zum Beispiel kann der ¨ Ubergang von z 1 nach z 0 erfolgen, sofern das Speicherelement s 1 mindestens eine Marke enth ¨ alt. In diesem Fall wird die Funktion f 0 als Aktion ausgef ¨ uhrt. Die Funktionen f ∈ F in einem FunState-Modell sind eindeutig benannt und verarbeiten bei ihrer Ausf ¨ uhrung Marken. Allen Ein- und Ausg ¨ angen von Funktionen sind Werte c i ∈ Z ≥0 bzw. p i ∈ Z ≥0 zugeordnet, die der Anzahl der konsumierten bzw. produzierten Marken nach Ausf ¨ uhrung der Funktion entsprechen. Die Ausf ¨ uhrungssemantik des FunState-Modells ist in f ¨ unf Phasen aufgeteilt: 1. Initialisierung: Der aktuelle Zustand des endlichen Automaten M wird auf den Anfangszustand gesetzt und die Speicherelemente s ∈ S im Netzwerk werden mit den anf ¨ anglichen Marken vorbelegt. 2. Pr ¨ adikatenevaluierung: Alle Pr ¨ adikate von aus dem aktuellen Zustand ausgehen- den Transitionen des endlichen Automaten M werden evaluiert. 3. Fortschrittspr ¨ ufung: Ist kein Pr ¨ adikat erf ¨ ullt, wird die Ausf ¨ uhrung gestoppt. 2.3 Ausf ¨ uhrbare Verhaltensmodelle 59 z 0 z 1 f 2 f 1 s 0 s 1 f 0 / f 1 s 1 # ≥ 1/ f 0 s 0 # ≥ 1/ f 2 Abb. 2.11. FunState-Modell 4. Transitionsausf ¨ uhrung: Ein Zustands ¨ ubergang aus dem aktuellen Zustand, dessen Pr ¨ adikat erf ¨ ullt ist, wird nichtdeterministisch ausgew ¨ ahlt, und die annotierte Funktion aktiviert. 5. Funktionsfeuerung: Die aktivierte Funktion f wird ausgef ¨ uhrt. Hierbei konsumiert bzw. produziert f entsprechend der mit den Ein- und Ausg ¨ angen assoziierten Werte c i und p i Marken von/auf den verbundenen Speicherelementen. Die Ausf ¨ uhrung wird mit Schritt 2. fortgesetzt. Die Besonderheit des FunState-Modells liegt darin begr ¨ undet, dass es allein durch Einschr ¨ ankung des endlichen Automaten viele der zuvor eingef ¨ uhrten Modelle ab- bilden kann. 2.3 Ausf ¨ uhrbare Verhaltensmodelle Ausf ¨ uhrbare Spezifikationen basieren auf einem ausf ¨ uhrbaren Verhaltensmodell. Diese k ¨ onnen mit Hilfe von Programmiersprachen erstellt werden. Programmier- sprachen bieten den Vorteil, dass diese h ¨ aufig mehrere Aspekte, wie z. B. datenfluss- und kontrollflussdominante Modelle, gleichzeitig darstellen k ¨ onnen. Grunds ¨ atzlich unterscheidet man zwei Arten von Programmiersprachen: imperative und deklarative. Imperative Programmiersprachen, wie beispielsweise C und Pascal, besitzen ein Ausf ¨ uhrungsmodell, in dem Anweisungen in der Reihenfolge ausgef ¨ uhrt werden, in der sie im Programmtext erscheinen (control-driven). LISP und PROLOG hingegen sind deklarative Sprachen. F ¨ ur diese Sprachen ist charakteristisch, dass sie keine explizite Ausf ¨ uhrungsreihenfolge spezifizieren. Statt dessen wird das Ziel der Berechnung durch eine Menge von Funktionen oder logische Regeln ausgedr ¨ uckt (demand-driven). 60 2 Spezifikation digitaler Systeme Basierend auf C/C++ sind in den letzten Jahren sog. Systembeschreibungsspra- chen entwickelt worden. Diese erweitern imperative Programmiersprachen um die Konzepte von Nebenl ¨ aufigkeit, Kommunikation und Synchronisation. Im Folgenden wird SystemC als wichtiger Vertreter von Systembeschreibungssprachen zur Erstel- lung ausf ¨ uhrbarer Spezifikationen f ¨ ur Hardware/Software-Systeme vorgestellt. Im Anschluss wird eine Erweiterung von SystemC mit dem Namen SysteMoC pr ¨ asen- tiert. SysteMoC erm ¨ oglicht die Modellierung von FunState-Modellen in SystemC und bietet vielseitige Synthese- und Analysem ¨ oglichkeiten. 2.3.1 SystemC SystemC ist eine Systembeschreibungssprache und ein Defacto-Standard zur Mo- dellierung von Hardware/Software-Systemen [207]. SystemC unterst ¨ utzt dabei ver- schiedene Abstraktionsebenen in der Modellierung. Technisch gesehen ist SystemC eine C++-Klassenbibliothek und erweitert C++ um die Aspekte • Nebenl ¨ aufigkeit, Kommunikation und Synchronisation, • ereignisgesteuerte Simulation, • Zeitannotationen sowie • spezielle Datentypen f ¨ ur die Hardware-Modellierung. Der SystemC-Sprachumfang ist im Dokument IEEE Std 1666 standardisiert [236]. Eine Referenzimplementierung von SystemC wird von der Open SystemC Initiative (OSCI) unter www.systemc.org angeboten. Modellierung mit SystemC Im Folgenden werden einige wichtige Modellierungskonzepte vorgestellt. SystemC-Module ¨ Ahnlich wie in Hardware-Beschreibungssprachen stellt SystemC Sprachkonstrukte zur Deklaration von Modulen zur Verf ¨ ugung. Ein SystemC-Modul kapselt somit die Verhaltensbeschreibung in einer Hardware- oder einer Software-Komponente. Jedes SystemC-Modul muss von der Basisklasse sc module abgeleitet werden. SystemC- Module sollen Daten lediglich ¨ uber Kan ¨ ale austauschen. Der Zugriff auf einen an- geschlossenen Kanal erfolgt ¨ uber sog. Ports. Das Verhalten des Moduls wird entweder durch Komposition aus anderen Modulen oder durch nebenl ¨ aufige Prozesse beschrieben. Beispiel 2.3.1. Das folgende SystemC-Modul implementiert eine einfache Kompo- nente, welche verifiziert werden soll (engl. System Under Verification, SUV). Es liest lediglich Daten von einem Eingangsport und kopiert diese unver ¨ andert auf den Aus- gangsport. [...]... fifo out bei der Instantiierung des Moduls verwendet Diese k¨ nnen mit SystemC-FIFO-Kan¨ len verbuno a den werden Neben diesen Porttypen stellt SystemC weitere vordefinierte Porttypen 62 2 Spezifikation digitaler Systeme zur Verf¨ gung Im Bereich der Hardware-Modellierung besitzen insbesondere Ports u f¨ r Signale eine besondere Bedeutung Dabei wird zwischen Eingangs-, Ausgangsu und Ein-/Ausgangsports... TestBench(sc_module_name name, int count) : sc_module(name), generator("generator", count), suv("suv"), monitor("monitor"), f1(2), f2(2) { generator.out(f1); suv.in(f1); suv.out(f2); monitor.in(f2); } }; 64 2 Spezifikation digitaler Systeme Die Verifikationsumgebung enth¨ lt neben dem Modul SUV, welches verifiziert a werden soll, noch die Module Generator und Monitor Das Generator-Modul ist daf¨ r verantwortlich, Stimuli f¨... Ereignisse in der Simulation vor, wird die Simulation beendet Die Ausgabe bei der Simulation sieht dann wie folgt aus: generator: generator: suv: suv: generator: generator: 1 2 1 2 3 4 66 2 Spezifikation digitaler Systeme monitor: monitor: suv: suv: generator: monitor: monitor: suv: monitor: 1 2 3 4 5 3 4 5 5 Man sieht, dass der ereignisgesteuerte Simulator der SystemC-Referenzimplementierung versucht,... bis 6 wird schließlich festa gelegt, welche Daten im Trace aufgezeichnet werden Das Ergebnis der Simulation ist in Abb 2.12 zu sehen Abb 2.12 Signalverl¨ ufe der SystemC-Simulation a 68 2 Spezifikation digitaler Systeme 2.3.2 SysteMoC In heutigen Entwurfsumgebungen im industriellen Umfeld ist es w¨ nschenswert, zu u Beginn des Entwurfes ein ausf¨ hrbares Modell des zu entwickelnden Systems zu u haben... der Klasse smoc graph abgeleitet Die einzelnen Aktoren werden bei der Konstruktion des Netzgraphen initialisiert und verbunden Die Verbindungen werden hierbei mit Hilfe der Funktion 70 2 Spezifikation digitaler Systeme produce() o0 # ≥ 1/produce() o0 start src approximate() c0 i0 i2# ≥ 1&i3# ≥ 1&o3# ≥ 1 /approximate() copyStore() c1 copyInput() o1 copyApprox() i1 i5 check() i0# ≥ 1&o1# ≥ 1 /copyStore()... o1[0] = tmp_i0; } void copyInput() { o1[0] = tmp_i0; } void copyApprox() { o2[0] = i3[0]; } bool check() const { return fabs(tmp_i0 - i3[0]*i3[0]) < 0.0001; } smoc_firing_state start; 72 2 Spezifikation digitaler Systeme 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 smoc_firing_state loop; public: SqrLoop(sc_module_name name) : smoc_actor( name, start ) { start = i0(1) o1(1) CALL(SqrLoop::copyStore)... sehen Man beachte, dass die durch die temporale Struktur repr¨ sentierten Sequenzen unendlich lang sind, weshalb nur ein Ausschnitt aus dem a Berechnungsbaum gezeichnet werden kann 74 2 Spezifikation digitaler Systeme a) b) s0 ab ab bc s2 bc c c s1 ab bc c c c c c Abb 2.14 a) Temporale Struktur und b) Berechnungsbaum [272] Pfade in einer temporalen Struktur beschreiben Sequenzen Ein Pfad in einer temporalen... Annahme eines linearen Zeitmodells verworfen Somit k¨ nnen Sequenzen verzweigen“ (siehe o ” Abb 2.14b)) In diesem Fall spricht man von einem verzweigenden Zeitmodell (engl branching time) 76 2 Spezifikation digitaler Systeme LTL-Formeln werden mittels atomarer Aussagen (aussagenlogische Variablen), logischen Operatoren und temporalen Operatoren gebildet Zwei grundlegende temporale Operatoren existieren hierbei:... existiert, auf u dem die Formel erf¨ llt Im Fall einer Formel, der der Operator A voransteht, muss u die folgende Formel auf allen Pfaden g¨ ltig werden Aus diesem Grund werden die u 78 2 Spezifikation digitaler Systeme modallogischen Operatoren auch als Pfadquantoren bezeichnet Der Pfadquantor E wird als existenzieller Pfadquantor (auch Existenzquantor) bezeichnet, da dieser die Existenz mindestens... s0 |= EG ϕ : ϕ ϕ s0 s0 |= AG ϕ : ϕ ϕ s0 ϕ s0 ϕ ϕ s0 |= A ϕ U ψ : ϕ ψ ϕ ϕ ϕ s0 |= E ϕ U ψ : ϕ ϕ ψ ϕ ϕ ϕ s0 ψ ψ Abb 2.17 Semantik der acht temporallogischen Operatoren in CTL [272] 79 80 2 Spezifikation digitaler Systeme Eine CTL-Formel ist in Normalform, wenn die Negation nur f¨ r aussagenlogiu sche Formeln verwendet wird Entsprechend ist ¬AX ϕ nicht in Normalform, da die Negation vor AX steht Hingegen . Eigenschaften: 1. ∀p ∈ P : |•p| = |p •|= 1 2. ∀p ∈ P : K(p)=∞ 3. ∀ f ∈ F : W( f )=1 52 2 Spezifikation digitaler Systeme 33uxdxyudxxdx x 1 adx y y 1 c u u 1 Abb. 2.6. Datenflussgraph zur L ¨ osung einer. dabei mit mehre- ren unterschiedlichen Datenraten arbeiten. Zur Modellierung von Anwendungen der digitalen Signalverarbeitung definieren Lee und Messerschmitt [296] das Modell des synchronen Datenflussgraphen,. zu- standsabh ¨ angige Aktoren (siehe z. B. in Abb. 2.9) dargestellt werden. 54 2 Spezifikation digitaler Systeme 1 1 1 1 1 2 a 0 a 1 a 2 Abb. 2.8. Ein SDF-Graph. Marken sind durch schwarze Punkte