Digitale Hardware/ Software-Systeme- P3 pot

Die Kommunikationsregel eines Datenflussgraphen entspricht der onsregel desjenigen Petri-Netzes, das man erh¨alt, wenn man die Knoten als Transitio-nen modelliert und die Kanten als mit

2.2 Formale Verhaltensmodelle 51Man beachte die Additivit¨at des Zeitfortschritts, d h.

(s,v) −→ (s,vδ1  ) ∧ (s,v )−→ (s,vδ2  ) =⇒ (s,v)δ−→ (s,v1 + δ 2 )

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 DiffeDiffe-rentialgleichung ist in der Form

y + 3xy  + 3y = 0 gegeben und soll im Intervall [x0,a] mit der Schrittweite dx und Anfangswerten y(x0) = y und y  (x0) = u numerisch gel¨ost werden Dabei wird f¨ur ein Anfangswertproblem der Form y  = f (x,y(x)) mit y(x0) = y0die N¨aherungsfor-

mel y(x+dx) ≈ y(x)+dx f (x,y(x)) eingesetzt, um, beginnend mit x0, die Werte von

y(x0+i dx), i = 1,2, , sukzessiv zu bestimmen Im Beispiel lautet die 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

Differential-hier auch Ein- und Ausgangsdaten (gestrichelt) dargestellt

Die Kommunikationsregel eines Datenflussgraphen entspricht der 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 Vorbereichersetzt, Ausgangskanten von Knoten ohne Nachfolger werden durch Stellen ohneNachbereich ersetzt

Kommunikati-Markierte Graphen

Markierte Graphen [113] sind Datenflussgraphen mit speziellen Eigenschaften Ein

Beispiel eines markierten Graphen ist in Abb 2.7a) dargestellt Ein markierter Graphl¨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,M0) mit den Eigenschaften:

1 ∀p ∈ P : | • p| = |p • | = 1

2 ∀p ∈ P : K(p) = ∞

3 ∀ f ∈ F : W( f ) = 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 duktion von Daten aus Stellen in der Reihenfolge der Ankunft erfolgt Obwohl dasModell 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

Pro-Sieht man von der Markierung ab, so sind markierte Graphen dual zu 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 immarkierten Graphen entsprechen Stellen im Petri-Netz

2.2 Formale Verhaltensmodelle 53Die ¨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 somitkonfliktfrei und k¨onnen damit nur deterministisches Verhalten beschreiben

Synchrone Datenflussgraphen (SDF)

Interessant f¨ur Anwendungen im Bereich der Signalverarbeitung sind Systeme, ren Teilsysteme bestimmten Teilaufgaben gewidmet sind und diese dabei mit mehre-ren unterschiedlichen Datenraten arbeiten Zur Modellierung von Anwendungen derdigitalen Signalverarbeitung definieren Lee und Messerschmitt [296] das Modell des

de-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)

ent-spricht einem Petri-Netz G(P,T,F,K,W,M0) mit den Eigenschaften:

Die Zahlen cons und prod werden als Konsumptions- bzw Produktionsrate

be-zeichnet 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 fangsknoten einer Kante, die Gewichte cons als Zahlen am Endknoten einer Kante

An-dargestellt

Im Folgenden werden Erweiterungen des SDF-Modells betrachtet

Zyklostatischer Datenfluss

Eine Erweiterung des SDF-Modells von Engels und Bilsen [153] erlaubt, dass

je-der Knoten v i im Graphen eine Menge von P i Konsumptionsraten cons(v j ,v i)kund

Produktionsraten prod (v i ,v j)k mit k = 0, ,P i − 1 besitzen kann Die Zahlen ten f¨ur genau eine Feuerung und sind alle P i Iterationen von Aktorfeuerungen zy-klisch abwechselnd g¨ultig Durch diese Erweiterung k¨onnen z B bestimmte zu-standsabh¨angige Aktoren (siehe z B in Abb 2.9) dargestellt werden

1 1

1 1 2

a0

a1

a2

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

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 v2mit

Periodizit¨at P2= 2 Der Knoten besitzt damit zwei Zust¨ande Im Zustand s = 0 ist 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 feuer-

bereit, 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 v2sind in folgender Tabelle zusammengefasst:

k cons(v0,v2) cons(v1,v2) prod(v2,v3)

2.2 Formale Verhaltensmodelle 55Engels 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, dasssich keine allgemeinen Kontrollstrukturen, beispielsweise datenabh¨angige Schleifenoder 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]: Bucknennt 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 derRegel 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 SWITCHund SELECT, und nennt die Klasse von Datenflussgraphen, die aus einer beliebi-gen 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

produzier-ten Daproduzier-ten 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 nungsuniversell) ist Jedoch l¨asst sich zeigen, dass sich gewisse Teilgraphen eines

(berech-BDF-Graphen durch Clustering zusammenfassen lassen und dadurch zumindest auf

Teilgraphen statische Analyseverfahren wie auf SDF-Graphen angewendet werdenk¨onnen

Alle hier betrachteten Datenflussmodelle besitzen die Eigenschaft, tisch zu sein, d h., dass bei beliebigen Ausf¨uhrungsreihenfolgen der Knoten die Se-

determinis-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 be-sitzen, blockierend Schreibzugriffe sind aufgrund der unbegrenzt großen Kan¨aleimmer nichtblockierend Diesen Sachverhalt stellt Lee in [295] dar, wo er die Zu-sammenh¨ange von Datenflussgraphen zu Prozesskalk¨ulen und Datenflusssprachen

(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 schaft bzw Sichtweise eines Systems gut beschreiben W¨ahrend solche spezifischenModelle zwar leichter zu analysieren sind, leiden sie unter ihrer eingeschr¨ankten

Eigen-Ausdruckskraft Um ein komplexes System zu beschreiben, benutzt man also im gemeinen heterogene Modelle.

All-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 Modellierungvon 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 Variationenvon CDFGs gibt, werden an dieser Stelle nur die wesentlichen Prinzipien nichtformalvorgestellt

Kontroll-Datenflussgraphen (CDFGs)

Offensichtlich kann ein Datenflussgraph keine Kontrollstrukturen wie z B gungen und Iterationen (z B Schleifenkonstrukte) modellieren Dazu dienen sog Kontrollflussgraphen (engl Control Flow Graphs, CFGs) Ein Kontrollflussgraph ist

Verzwei-ein gerichteter Graph, in dem den Knoten Berechnungen entsprechen und KantenNachfolgerrelationen in einem (sequentiellen) Kontrollfluss ausdr¨ucken, nicht aberDatenabh¨angigkeiten Besitzt ein Knoten mehrere Nachfolger, so handelt es sich um

einen Verzweigungsknoten Der von einem Verzweigungsknoten ausgehende trollfluss ist alternativ, d h es wird exakt ein Nachfolgerzweig durchlaufen Die

Kon-Auswahl eines Zweigs ist abh¨angig von Booleschen Ausdr¨ucken, die man weise an die Ausgangskanten eines Verzweigungsknotens schreibt

¨ublicher-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 trollflussgraph ist in Abb 2.10b) dargestellt: ¨Ublicherweise assoziiert man mit jedemKnoten eine C-Anweisung (durch Zeilennummern gekennzeichnet) Bei Knoten, diemehr als eine Ausgangskante besitzen (Verzweigungsknoten), ist der Kontrollfluss

Kon-alternativ Entsprechende Verzweigungsbedingungen werden an die

Ausgangskan-ten geschrieben Ein Schleifenkonstrukt l¨asst sich als eine Verzweigung mit Test aufdie Abbruchbedingung der Iteration modellieren

Ein Kontrollflussgraph kann offensichtlich nicht die Datenabh¨angigkeiten der

Berechnungen darstellen Das Modell von Kontroll-Datenflussgraphen ist ein

7 4

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

(sie-he Abb 2.10b), der die Berechnung der entsprec(sie-henden Anweisung modelliert Diegestrichelten Knoten (NOP-Operationen) modellieren einen einheitlichen Eintritts-bzw Austrittspunkt eines Datenflussgraphen (DFGs)

Schließlich zeigt Abb 2.10b) einen weiteren relevanten Aspekt der Definitioneines CDFG-Modells: In dem Modell in Abb 2.10a) besteht kein Grund, die bei-den 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 unddie er am Ende verl¨asst, ohne dass er, außer am Ende, verzweigt Im CFG gibt esdann pro Grundblock nur einen Knoten Die Datenflussgraphen bestimmt man durch

Datenflussanalyse (siehe z B [4, 343]).

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 chen Automaten

endli-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 Markeassoziierten Wert ber¨ucksichtigen Die Speicherelemente in einem FunState-Modellk¨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 ≥0bezeichnet Die Anzahl der anf¨anglichen Marken wird mit s#0bezeichnet

In Abb 2.11 ist die Anzahl der anf¨anglichen Marken s0#0= s1#0= 1 Die Menge der

Funktionen F ist gegeben durch F = { f0, f1, f2} Der untere Teil zeigt den ten M, welcher zwei Zust¨ande besitzt Die Zustands¨uberg¨ange sind mit Bedingungen

Automa-und Aktionen beschriftet Zum Beispiel kann der ¨Ubergang von z1nach z0erfolgen,

sofern das Speicherelement s1mindestens eine Marke enth¨alt In diesem Fall wird

die Funktion f0als 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≥0bzw p i ∈ Z≥0zugeordnet, 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 werausgehen-den evaluiert.

3 Fortschrittspr¨ufung: Ist kein Pr¨adikat erf¨ullt, wird die Ausf¨uhrung gestoppt

des-5 Funktionsfeuerung: Die aktivierte Funktion f wird ausgef¨uhrt Hierbei miert bzw produziert f entsprechend der mit den Ein- und Ausg¨angen assozi- ierten Werte c i und p iMarken von/auf den verbundenen Speicherelementen DieAusf¨uhrung wird mit Schritt 2 fortgesetzt.

konsu-Die Besonderheit des FunState-Modells liegt darin begr¨undet, dass es allein durchEinschr¨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 tive Imperative Programmiersprachen, wie beispielsweise C und Pascal, besitzen

deklara-ein Ausf¨uhrungsmodell, in dem Anweisungen in der Reihenfolge ausgef¨uhrt

wer-den, in der sie im Programmtext erscheinen (control-driven) LISP und PROLOG

hingegen sind deklarative Sprachen F¨ur diese Sprachen ist charakteristisch, dass siekeine explizite Ausf¨uhrungsreihenfolge spezifizieren Statt dessen wird das Ziel derBerechnung durch eine Menge von Funktionen oder logische Regeln ausgedr¨uckt

(demand-driven).

Basierend auf C/C++ sind in den letzten Jahren sog chen entwickelt worden Diese erweitern imperative Programmiersprachen um die

Systembeschreibungsspra-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 SystemCund bietet vielseitige Synthese- und Analysem¨oglichkeiten

2.3.1 SystemC

SystemC ist eine Systembeschreibungssprache und ein Defacto-Standard zur dellierung von Hardware/Software-Systemen [207] SystemC unterst¨utzt dabei ver-schiedene Abstraktionsebenen in der Modellierung Technisch gesehen ist SystemCeine C++-Klassenbibliothek und erweitert C++ um die Aspekte

Mo-• 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 JedesSystemC-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

ent-weder durch Komposition aus anderen Modulen oder durch nebenl¨aufige Prozessebeschrieben

Beispiel 2.3.1 Das folgende SystemC-Modul implementiert eine einfache nente, welche verifiziert werden soll (engl System Under Verification, SUV) Es liest

Kompo-lediglich Daten von einem Eingangsport und kopiert diese unver¨andert auf den gangsport

In Zeile 1 wird das SystemC-Modul SUV deklariert, welches von der Basisklasse

sc module abgeleitet ist In den Zeilen 3-5 erfolgt die Deklaration von Ports undVariablen Die Eingangs- und Ausgangsports in und out werden sp¨ater bei der In-stantiierung des Moduls mit FIFO-Kan¨alen verbunden Das eigentliche Verhalten derKomponente ist in Zeile 8-14 in der Methode pass definiert Hier wird ein Datumvom Eingangsport in gelesen, auf der Standardausgabe f¨ur Debugzwecke ausgege-ben und anschließend unver¨andert auf den Ausgangsport out geschrieben

Dass es sich bei dem Modul SUV nicht um eine rein strukturelle Beschreibunghandelt, sondern das Verhalten in Form eines Prozesses implementiert ist, wird durchdas Makro in Zeile 17 angezeigt Um welchen Prozess es sich dabei handelt wird imKonstruktor in Zeile 20 durch das Makro SC THREAD bezeichnet Dieses zeigt auch

an, dass es sich um einen Thread handelt (siehe unten) Bei der Definition des struktors wird erwartet, dass der Konstruktor der Basisklasse mit einem Argument,das den Namen des Moduls als Zeichenkette repr¨asentiert, aufgerufen wird

Kon-Ports und Interfaces

Wie in Beispiel 2.3.1 zu sehen ist, werden Ports als Objekte in einem sc module

definiert Durch die Verwendung des C++-Schl¨usselworts public k¨onnen Ports vonanderen Objekten außerhalb der Klasse verwendet werden In dem Beispiel wur-den dabei vordefinierte Porttypen sc fifo in und sc fifo out bei der Instanti-

ierung des Moduls verwendet Diese k¨onnen mit SystemC-FIFO-Kan¨alen

verbun-den werverbun-den Neben diesen Porttypen stellt SystemC weitere vordefinierte Porttypen

zur Verf¨ugung Im Bereich der Hardware-Modellierung besitzen insbesondere Ports

f¨ur Signale eine besondere Bedeutung Dabei wird zwischen Eingangs-,

Ausgangs-und Ein-/Ausgangsports unterschieden Die entsprechenden Klassen lauten sc in,

sc out und sc inout Alle Porttypen sind als Template-Klassen implementiert, bei der Template-Parameter den zu transportierenden Datentyp festlegt Dieser kannein beliebiger Standard-C++-, SystemC- oder benutzerdefinierter Datentyp sein Indem Beispiel 2.3.1 wurde als Datentyp double verwendet

wo-Neben der Verwendung vordefinierter Porttypen ist es ebenfalls m¨oglich, eigenePorttypen zu definieren Dies erfolgt durch Ableitung von der Basisklasse sc port.Diese Klasse ist wiederum eine Template-Klasse, die als Template-Parameter einInterface vom Typ sc interface erh¨alt Dieses Interface deklariert lediglich dieMethoden zum Kanalzugriff (z B read() und write()) Die eigentliche Imple-

mentierung dieser Methoden erfolgt im Kanal.

Beispiel 2.3.2 Die folgende Port-Definition ist ¨aquivalent zu sc in:

sc port< sc signal in if < bool > >

Hierbei ist sc signal in if eine vordefiniertes Interface, das von sc interfaceabgeleitet ist

neben-Im Gegensatz dazu werden SystemC-Threads vom Typ SC THREAD in der Regelnicht beendet Im Beispiel 2.3.1 wird deshalb eine while(true)-Schleife verwen-det Damit andere Prozesse nicht verhungern, muss jeder Prozess irgendwann dieKontrolle an den Simulator zur¨uckgeben Hierzu blockiert sich ein Thread an Ereig-nissen, wie z B einem Taktsignal oder wie im Beispiel 2.3.1 an den Lesezugriffen

an einem FIFO-Kanal Ist dieser FIFO-Kanal leer, wird der Thread solange blockiert,bis ein neues Datum in den Kanal geschrieben wurde

SystemC-Methoden werden oft zur Modellierung von Hardware-Komponentenverwenden Bei der Modellierung auf Systemebene, auf der Hardware- und Software-Komponenten interagieren, werden, obwohl ihres Geschwindigkeitsnachteils, h¨aufigSystemC-Threads bevorzugt

2.3 Ausf¨uhrbare Verhaltensmodelle 63

Kan¨ale

Kan¨ale werden f¨ur die Kommunikation zwischen Modulen verwendet Sie k¨onnen

dabei so primitiv wie ein Signal oder so komplex wie ein ganzer Bus oder ein sog

engl Network on Chip (NoC) sein SystemC stellt vordefinierte Kanaltypen f¨ur

Si-gnale (sc signal), FIFO-Kan¨ale (sc fifo), Semaphore (sc semaphore) etc zurVerf¨ugung Daneben erlaubt SystemC die Definition eigener Kanaltypen Hierf¨urmuss der Kanal von sc interface abgeleitete Lese- und Schreib-Interfaces imple-mentieren

Die M¨oglichkeit zur Definition eigener Kan¨ale erlaubt es, in SystemC schiedliche Abstraktionsebenen zu unterst¨utzen Dies unterscheidet SystemC deut-lich von Hardware-Beschreibungssprachen wie VHDL

unter-Komposition

Neben der Definition eines SystemC-Moduls durch nebenl¨aufige Prozesse, kann einModul auch strukturell durch Komposition anderer SystemC-Module definiert wer-den Dies sei an einem Beispiel f¨ur eine simulative Verifikationsumgebung verdeut-licht

Beispiel 2.3.3 Die Verifikationsumgebung ist durch das Modul TestBench

Die Verifikationsumgebung enth¨alt neben dem Modul SUV, welches verifiziertwerden soll, noch die Module Generator und Monitor Das Generator-Modul istdaf¨ur verantwortlich, Stimuli f¨ur die Simulation zur Verf¨ugung zu stellen, w¨ahrenddas Monitor-Modul die Ausgaben des SUV erfasst und gegebenenfalls auswertet.Die Instantiierung der drei Module erfolgt in den Zeilen 13-15 Neben diesen dreiModulen enth¨alt die Verifikationsumgebung noch zwei FIFO-Kan¨ale, um die Datenzwischen den Modulen zu transportieren (Zeilen 8 und 9).

Die Initialisierung der Kan¨ale erfolgt im Konstruktor der bung (Zeilen 16 und 17) Jedes Modul wird mit einem Namen initialisiert DasGenerator-Modul erh¨alt dar¨uber hinaus noch die Anzahl der zu erzeugenden Sti-muli als Konstruktorparameter Die FIFO-Kan¨ale erhalten als Konstruktorparameterdie Gr¨oße des Kanals, d h jeder FIFO-Kanal f1 und f2 kann zwei Daten vomTyp double speichern Weiterhin werden im Konstruktor der Verifikationsumge-bung die Module und Kan¨ale miteinander verbunden So schreibt beispielsweise dasGenerator-Modul ¨uber seinen Port out auf den Kanal f1 (Zeile 18) Aus dem sel-ben Kanal liest das SUV-Modul ¨uber den Eingangsport in

Verifikationsumge-Simulation von SystemC-Modellen

Zur Simulation muss das SystemC-Modell mit einem C++-Compiler compiliert den und ausgef¨uhrt werden F¨ur die Simulation der Verifikationsumgebung aus Bei-spiel 2.3.3 m¨ussen zun¨achst noch die Module Generator und Monitor implemen-tiert werden Der folgende Quelltext zeigt die beiden Implementierungen:

wer-1 class Generator: public sc_module {

2.3 Ausf¨uhrbare Verhaltensmodelle 65Das Generator-Modul erzeugt insgesamt max Stimuli, die es auf den Ausgabeportout schreibt Um die Beschreibung m¨oglichst einfach zu halten, wurde hierbei einefor-Schleife verwendet.

1 class Monitor: public sc_module {

9 std::cout << "monitor: " << data << std::endl;

Die Ausgabe bei der Simulation sieht dann wie folgt aus: