Hardware/Software-Codesign mit SystemC · SystemCunterstutzt dieKapselungvonFunktionalit at...

Technische Universitat Braunschweig

Abteilung Entwurf integrierterSchaltungen (E.I.S.)

Prof. Dr. Ulrich Golze

Dipl.-Inform. Wolfgang Klingauf

Praktikum

Hardware-Software-Codesign mit

SystemC

SystemC-Einfuhrung und Rechnerubungen

Version: WS 2005/06, Revision: 6. Januar 2006

Inhaltsverzeichnis 3

Inhaltsverzeichnis

1 Einleitung 5

2 Warum SystemC? 72.1 Der SystemC-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 High-Level-Entwurf mit SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Modellierungskonzepte von SystemC . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Transaction-Level-Modeling . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Vom Transaction-Level-Model zum fertigen Produkt . . . . . . . . . . . 11

2.4 Die Zukunft von SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Grundlagen der System-Beschreibungssprache SystemC 133.1 Hallo, Braunschweig! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Ubung 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 Die sc main-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 RTL-Modellierung mit SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.4 Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.5 Ubung 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.6 Kommunikationskanale (Channels) . . . . . . . . . . . . . . . . . . . . . 24

3.4 Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.1 Hardwarenahe Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . 263.4.2 Textreprasentation von Daten . . . . . . . . . . . . . . . . . . . . . . . . 273.4.3 Weitere Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.4 Konkatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5 Ubung 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5.1 Aufgabe 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5.2 Aufgabe 3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.6 Parallelitat und Zeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.6.1 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.6.2 Events und Wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6.3 Nicht-blockende Zuweisung in SystemC . . . . . . . . . . . . . . . . . . 32

3.7 Ubung 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7.1 Aufgabe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7.2 Aufgabe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.3 Aufgabe 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Transaction-Level-Modeling 354.1 TLM mit SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2 Ubung 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.1 Aufgabe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.2 Aufgabe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Inhaltsverzeichnis

1 Einleitung 5

1 Einleitung

Die folgenden Seiten fuhren in den praktischen Systementwurf mit SystemC ein. Um Sie auf dasPraktikum im Sommersemster gut vorzubereiten, werden Sie an Hand von kleinen Beispielenschrittweise mit der Systembeschreibungssprache SystemC bekannt gemacht.

Da SystemC auf C++ basiert, konnen grundlegende C++-Kenntnisse hilfreich sein. Aber auchmit Java-Erfahrung sollten Sie sich rasch in die Sprache hineinfinden, denn SystemC baut vorallem auf den allgemeingultigen Konzepten der objektorientierten Programmierung auf undubertragt diese in die Welt des Hardware-Software-Codesigns. Naturlich werden Sie außerdemIhr in der Vorlesung erworbenes Verilog-Know-How intensiv anwenden, denn die Implementie-rung von Register-Transfer-Logik mit SystemC ist fur Sie damit kein Problem.

Grundlagen zu SystemC werden in den folgenden beiden Kapiteln 2 und 3 vermittelt. An-schließend folgen einige leichte Fingerubungen zum Transaction-Level-Modeling, der Program-miertechnik, die Sie im SystemC-Praktikum einsetzen werden. Der Text ist zur gemeinsamenLekture mit Ihren Gruppenmitgliedern direkt vor dem Rechner gedacht, denn durch kleineUbungsaufgaben werden Sie von Anfang an praktisch mit SystemC arbeiten. Alle zu bearbei-tenden Ubungen sind durch einen Balken am Seitenrand markiert.

Fur die Eingabe von SystemC-Programmen konnen Sie Ihren Lieblings-Texteditor verwendenoder auch Entwicklungsumgebungen wie Eclipse. Verschiedene Programme und eine komforta-ble Ubersetzungs-Umgebung fur SystemC-Modelle stehen fur Sie auf unseren Institutsrechnernbereit, so dass Sie sich Ihren individuellen

”Desktop“ leicht einrichten konnen. Uber eine Inter-

netverbindung konnen Sie auch von außerhalb darauf zugreifen.

Kenntnisse zum Kompilieren und Ausfuhren von SystemC-Modellen werden wahrend der Be-arbeitung der Ubungen vermittelt. Weitere Informationen und Tipps erhalten Sie naturlichjederzeit von Ihren Betreuern:

• Bjorn Liebig, [email protected],

• Fabian Mischkalla, [email protected],

• Wolfgang Klingauf, [email protected], Tel. 0531/391-3105, Raum 316

Schauen Sie außerdem gelegentlich auf unserer SystemC-Webseite vorbei, denn Sie enthaltnutzliche Links zu am Bildschirm lesbaren SystemC-Handbuchern und einer Befehlsreferenz:www.eis.cs.tu-bs.de/teaching/scprak.htm. Um sich nun aber nicht gleich in den (Un-)Tiefen derdort gebotenen Literatur zu verlieren, sollten Sie jetzt auf die ubernachste Seite blattern!

mailto:[email protected]



2 Warum SystemC? 7

2 Warum SystemC?

The Disappearing Computer ist laut Mark Weiser, dem Vordenker des”Uberall-Computing“,

der Trend, mit dem wir Informatiker und IST’ler uns in den nachsten Jahren hauptsachlich be-fassen werden. Allerdings wird der Computer tatsachlich nicht verschwinden, sondern er wirdbuchstablich uberall sein. Intelligente benutzerfreundliche Gerate vereinen schon heute zum Bei-spiel in der Home-Automation Computertechnik und Sensoren zu eingebetteten Systemen, dieuns – nahtlos mit dem Gebaude verschmolzen – zu einer komfortablen und okonomischen Woh-numgebung verhelfen [Sk1,11]1. Fortschrittliche Gerate, die z.B. mit der Erkennung von Spracheund Gestik arbeiten, werden derzeit intensiv erforscht und bilden eine naturliche Schnittstellezwischen Mensch und Maschine.

Viele Firmen arbeiten daruber hinaus daran, eingebettete Systeme unsichtbar in Alltagsge-genstande wie etwa Kleidungsstucke zu integrieren. Uber Body-Area-Networks vernetzt undstandig mit der Umgebung in (Funk-)Kontakt sollen so Systeme entstehen, die nicht nur pas-siv, sondern auch aktiv auf den Menschen reagieren.

Bild 1: System-On-Chip IBM STBx25

Der Ausflug in die nahe Zukunft lasst erahnen, mit welchen Herausforderungen die Entwicklervon innovativen eingebetteten Systemen konfrontiert werden. Standardbausteine reichen hiernicht mehr aus, stattdessen werden ein oder mehrere Prozessorkerne mit Speicher, Peripherie-schnittstellen und anwendungsspezifischer Hardware in einem einzigen System-On-Chip (SoC)vereint. Bild 1 zeigt ein SoC von IBM, das einen kompletten digitalen Fernsehempfanger (DVB)inklusive Video-on-Demand-Funktion und interaktivem Programmfuhrer auf 1cm2 Flache ent-halt.

1Wir verwenden die Notation [Skn] fur Verweise auf Kapitel n im Vorlesungsskript

8 2.1 Der SystemC-Ansatz

In den letzten Jahren hat sich gezeigt, dass die klassischen Entwurfsmethoden bei solchen De-signs an ihre Grenzen stoßen. Durch die Verwendung unterschiedlicher Programmiersprachenfur Hardware (Verilog, VHDL) und Software (C/C++, Java) gestaltet sich echtes Hardware-Software-Codesign schwierig und die taktgenaue Simulation eines kompletten SoC-Modells istbeinahe unmoglich. Oft entstehen daher Produkte, die entweder den Anforderungen nicht ge-wachsen (zu langsam, Absturze, etc.) oder uberdimensioniert sind (Hardware nicht ausgelastet,hoher Stromverbrauch, Gerat zu groß). Ein wichtiger Grund hierfur ist, dass sich die Entwicklerbeim Entwurf der Einzelkomponenten eher auf ihre Intuition und Erfahrung als auf analytischgewonnene Erkenntnisse verlassen, denn ein System wie das aus Bild 1 lasst sich in seiner Ge-samtheit als Verilog- oder VHDL-Modell nur mit sehr teurer Spezialhardware in vernunftigerZeit simulieren.

2.1 Der SystemC-Ansatz

Ein Ansatz zur Steigerung der Entwurfsproduktivitat ist die Systembeschreibungssprache Sy-stemC. Dabei handelt es sich um eine umfangreiche Erweiterung der objektorientierten Pro-grammiersprache C++. SystemC bietet vollig neue Sprachkonstrukte, mit denen typischeHardwareeigenschaften wie Parallelitat und Zeit modelliert werden konnen, so dass Register-Transfer-Logik beschrieben und auch synthetisiert werden kann. Die eigentliche Starke vonSystemC liegt aber in noch weiter gehenderen Sprachkonstrukten, mit denen Hardware- undSoftwarekomponenten sowie ihre Kommunikationsbeziehungen auch auf hoheren Abstraktions-ebenen als RTL in einer gemeinsamen Programmiersprache modelliert werden konnen.

Die Modellierungskonzepte fur Register-Transfer-Logik in SystemC sind sehr ahnlich zu denenvon Verilog. SystemC unterstutzt die Kapselung von Funktionalitat in Modulen, die hierarchischgeschachtelt werden konnen. Hierzu dient das Schlusselwort SC_MODULE.

Als Aquivalent zu den always-Blocken in Verilog bietet SystemC so genannte SC_METHODs. Siesind wie normale C++- oder Java-Methoden aufgebaut und konnen beliebigen Programmcodeenthalten. Als Besonderheit aber konnen sie wie always-Blocke auf bestimmte Ereignisse, z.B.Signalanderungen, reagieren. Der SystemC-Simulator ruft solche SC_METHODs dann immer wie-der auf, wenn das entsprechende Ereignis eingetreten ist. Weitere typische Modellierungskonzep-te von Verilog wie die hardwarenahen Datentypen mit den Werten {0,1,X,Z} und Zeitkontrollensowie Events werden ebenfalls in SystemC unterstutzt.

Da sich die Modellierungskonzepte fur Register-Transfer-Logik aber immens von der objektori-entierten Softwareentwicklung unterscheiden, fuhrte allein eine Erweiterung der Sprache C++fur die RTL-Beschreibung noch nicht dazu, dass Software-Entwickler plotzlich auch Hardwareaus dem Armel schutteln konnen. Die ursprunglich an SystemC gesetzten Erwartungen, durcheine Hardware- und Software-Modellierung

”aus einem Guss“ alle Probleme des Hardware-

Software-Codesign auf einen Schlag zu losen, haben sich mit der ersten SystemC-Version 1.0daher leider nicht erfullt (was gut fur die Job-Chancen von Chip-Designern ist).

Nichtsdestotrotz hat der SystemC-Ansatz einen wahren Sturm von neuen Forschungsaktivitatenim Bereich des Hardware-Software-Codesigns ausgelost. Im Mittelpunkt stehen neue Modellie-rungskonzepte mit SystemC, die den System-Entwurf vereinfachen sollen. Neben zahlreichenUniversitaten haben viele einflussreiche Unternehmen wie IBM, Intel, Nokia, Philips und ST Mi-croelectronics eigene Forschungsgruppen fur SystemC eingerichtet und bringen sich aktiv in dieWeiterentwicklung der Sprache ein. SystemC wurde in den letzten Jahren kontinuierlich er-

2 Warum SystemC? 9

weitert und unterstutzt mit der aktuellen Version 2.1 eine breite Palette sehr moderner undinnovativer Konzepte zum High-Level-Entwurf von Hardware-Software-Systemen.

Dass SystemC beim Hardware-Software-Codesign schon heute einen festen Platz eingenom-men hat, spiegelt sich auch in der immer hoheren Prasenz von SystemC auf den jahrlichenKonferenzen zum Thema

”Electronic Design Automation“ wider. Die Beitrage zum letzten in-

ternationalen”Forum on Design Languages“ (FDL’05) etwa drehten sich fast ausschließlich um

Anwendungen und Erweiterungen von SystemC.

2.2 High-Level-Entwurf mit SystemC

SystemC erlaubt die Modellierung von Hardware und Software auf verschiedensten Abstrakti-onsebenen, vom abstrakten funktionalen Modell uber verschiedene Verhaltensmodelle bis hin-unter zur taktgenauen RTL-Ebene [Sk1]. Damit wird es moglich, Hardware und Software ineiner gemeinsamen hoheren Programmiersprache zu spezifizieren und in einem systematischenEntwurfsfluss wie in Bild 2 schrittweise bis zur endgultig synthetisierbaren Modellierung zuverfeinern (vgl. auch Bild 11.3 in [Sk11]).

Bild 2: Hardware-Software-Codesign mit SystemC

Mit Hilfe des frei verfugbaren SystemC-Simulators konnen SystemC-Modelle auf allen un-terstutzten Abstraktionsebenen, vom funktionalen Softwaremodell bis zur Hardware-RTL-Implementierung, gemeinsam mixed-mode simuliert werden [Sk2]. Mit steigender Abstraktions-ebene nimmt die Simulationsgeschwindigkeit dabei dramatisch zu, so dass Software-Entwicklerabstrakte Hardwaremodelle verwenden konnen, um ihre Software-Implementierung mehr als1.000-fach schneller zu verifizieren als mit einer herkommlichen Verilog/VHDL-Simulation. Na-turlich wird dieser Performance-Gewinn durch Vernachlassigen von Hardware-Details wie takt-genauer Logiksimulation erkauft, die Ergebnisse sind aber aus Sicht des Software-Entwicklersaussagekraftig genug.

10 2.3 Modellierungskonzepte von SystemC

2.3 Modellierungskonzepte von SystemC

SystemC-2.1 unterstutzt Modellierungskonzepte, die sich an Techniken aus dem modernenSoftware-Engineering anlehnen. Diese ermoglichen die High-Level-Beschreibung von System-komponenten auf sehr viel hoheren Abstraktionsebenen als dies mit einer HDL wie Verilogmoglich ist. Dabei unterstutzt SystemC verschiedene

”Models-of-Computation“ (MoC). Der

Begriff MoC wurde im Zusammenhang mit der formalen Definition von Spracheigenschaftengepragt und umfasst die Ausfuhrungssemantik einer Sprache, das verwendete Zeitmodell, dieunterstutzten Kommunikationsmethoden zwischen parallelen Prozessen und die Regeln zur Ak-tivierung von Prozessen. Ein Ihnen bereits gut bekanntes MoC ist das Modell der Zustands-automaten, genannt Final State Machine oder kurz FSM. Weitere MoCs sind Kahn-Process-Networks (KPN) und Synchronous-Data-Flow (SDF), die besonders fur die Beschreibung vonSignalverarbeitungsprozessoren verwendet werden.

Die”traditionellen“ Entwurfssprachen wie VHDL, Verilog und SDL konnen als

”Ein-MoC“-

Sprachen angesehen werden. SystemC bietet in diesem Sinne zwar auch nur ein Basis-MoC,dieses ist aber so universell, dass anwendungsspezifische MoCs daraus maßgeschneidert werdenkonnen. Per Definition beschreibt der Begriff MoC nicht eine Modellierungstechnik, sondern dieder Modellierungstechnik zu Grunde liegende Sprach- und Ausfuhrungssemantik. Wegen ihrerengen Verzahnung wollen wir die beiden Begriffe im Folgenden aber gleichbedeutend verwenden.

2.3.1 Transaction-Level-Modeling

Das MoC, was sich in den letzten Jahren als besonders gut geeignet fur die Entwicklung vonHardware-Software-Systemen auf der Basis von wiederverwendbaren Bausteinen herausgestellthat, ist das so genannte Transaction-Level-Modeling (TLM). TLM kann auf hoher und aufniedriger Abstraktionsebene eingesetzt werden und ermoglicht einen sehr zielstrebigen Ent-wurfsprozess fur Hardware- und Softwarekomponenten, wobei einzelne Entwurfsschritte auchautomatisch durchgefuhrt werden konnen.

Beim Transaction-Level-Modeling wird eine entscheidende Trennung vorgenommen, fur die Sy-stemC pradestiniert ist:

• Module enthalten ausschließlich Methoden und Threads, die die Funktionalitat der Sy-stemkomponenten beschreiben.

• Kanale, in SystemC Channels genannt, beschreiben die Kommunikation zwischen deneinzelnen Systemkomponenten.

Durch diese Orthogonalisierung konnen nun Systemkomponenten, die eine bestimmte Funktio-nalitat erfullen (JPEG-Encoder), jederzeit uber unterschiedliche Kommunikationsarchitekturenverbunden werden (PCI-Bus, Bluetooth-Netzwerk, etc.). Hierzu muss lediglich der Channel aus-getauscht werden.

Ein typisches TLM-High-Level-Modell zeigt Bild 3. Es macht die Grundelemente desTransaction-Level-Modeling, Module, Ports und Channels, deutlich. Das obere Modul in Bild 3implementiert einen JPEG-Encoder. Daten werden von einem Bildsensor entgegen genommen,mit dem JPEG-Verfahren komprimiert und uber einen abstrakten Kommunikations-Port als

2 Warum SystemC? 11

Bild 3: Einfaches TLM-Modell einer Digitalkamera

JPEG-Bild zur Verfugung gestellt. Ein Channel ist an diesen Port angeschlossen und uber-tragt die Ausgabe des JPEG-Encoders zum Kommunikations-Port des Moduls CompactFlash-Card-Writer. Letzteres nimmt die JPEG-Daten uber seinen Kommunikations-Port entgegenund schreibt sie auf eine CompactFlash-Karte.

Dieses TLM-Modell ist sehr abstrakt. Zum Beispiel wurde noch nicht festgelegt, ob der JPEG-Encoder spater in Hardware oder in Software realisiert werden soll. Auch wurde nicht ent-schieden, welches Kommunikationsprotokoll zwischen den beiden Modulen verwendet werdensoll und wie die physikalische Schnittstelle aussieht. Dennoch kann die Funktionalitat des Ge-samtsystems mit diesem Modell schon sehr gut im SystemC-Simulator untersucht und aufKorrektheit uberpruft werden.

2.3.2 Vom Transaction-Level-Model zum fertigen Produkt

In den folgenden Entwurfsschritten konnen die beiden abstrakten Module aus unserem Beispiel,JPEG-Encoder und CompactFlash-Card-Writer, in verfeinerte Submodule zerlegt werden, diewiederum uber TLM-Channels miteinander verbunden werden. Auf diese Weise nahert mansich bei Hardwaremodulen systematisch an ein synthetisierbares RTL-Modell an.

Die TLM-Channels selbst konnen bis zum Schluss abstrakt bleiben und werden dann erst imletzten Entwurfsschritt durch eine tatsachliche Kommunikationsarchitektur (z.B. PCI-Bus) er-setzt. Sie konnen aber auch zuerst oder gleichzeitig mit den funktionalen Beschreibungen desSystems verfeinert werden (Co-Verfeinerung). So bleibt der Entwurfsprozess in allen Entwurfs-phasen flexibel. Fehlentscheidungen konnen leicht durch Ruckkehr zum vorherigen Entwurfs-schritt revidiert werden, und die in harter Arbeit entwickelten SystemC-Module konnen inanderen Projekten leicht wieder verwendet werden.

Daruber hinaus ermoglicht Transaction-Level-Modeling eine fruhe Entwicklung der Softwarefur eingebettete Systeme. Dazu wird sie zunachst gemeinsam mit den High-Level-Modellender Hardware in SystemC modelliert und simuliert. Anschließend werden die SystemC-Softwaremodule mit einem speziellen

”Cross-Compiler“ fur den Zielprozessor kompiliert.

Schließlich mussen die TLM-Channels zwischen Software- und Hardwaremodulen durch”echte“

Hardware-Software-Schnittstellen ersetzt. Dieser Vorgang ist leider nicht so einfach, wie es auf

12 2.4 Die Zukunft von SystemC

den ersten Blick scheint, und muss heute noch komplett von Hand erledigt werden. AktuelleForschungsprojekte beschaftigen sich mit diesem Thema.

2.4 Die Zukunft von SystemC

SystemC ist Open Source. Um die Entwicklung der Sprache organisiert voranzutreiben, wur-de 1999 die

”Open SystemC Initiative“ OSCI gegrundet. Besonders in der letzten Zeit sind

dieser Organisation viele namhafte Firmen und Institutionen beigetreten. Erste professionelleEntwicklungsumgebungen fur den SoC-Entwurf mit SystemC werden von Cadence, CoWareund Synopsys angeboten. Ferner erweitern Celoxica, Mentor und andere Hersteller von CAD-Werkzeugen derzeit ihre bestehenden Produkte um SystemC-Unterstutzung.

Neben dem breiten Interesse durch Industrie und Forschung ist SystemC insbesondere wegen derEigenschaft hervorzuheben, dass die Sprache selbst beliebig erweitert werden kann. Vorschlagefur Spracherweiterungen konnen an eine der Working-Groups der OSCI eingereicht und zurDiskussion gestellt werden.

Eine Standardisierung der Sprache ist extrem wichtig, um den reibungslosen Austausch vonSystemC-Modellen zwischen verschiedenen Entwicklern zu ermoglichen und eine deterministi-sche Ausfuhrung von SystemC-Quelltext durch SystemC-Simulatoren verschiedener Herstellerzu gewahrleisten. Wahrend der Kern der Sprache im Dezember 2005 von der internationalenIngenieurs-Vereinigung IEEE standardisiert (IEEE 1666) wurde, existiert noch keine Einigkeituber die

”richtige“ Vorgehensweise beim Transaction-Level-Modelling. In 2005 wurde hierzu

die GreenSocs-Initiative gegrundet mit dem Ziel, in enger Kooperation mit der Industrie einenTLM-Standard fur die Kommunikationsmodellierung mit SystemC auszuarbeiten. Die Abtei-lung E.I.S. wurde mit der wissenschaftlichen Leitung dieses Projekts beauftragt.

3 Grundlagen der System-Beschreibungssprache SystemC 13

3 Grundlagen der System-Beschreibungssprache SystemC

Hardware-Beschreibungssprachen (HDL) sind seit Jahren das Standardwerkzeug zumHardware-Entwurf. Mit der Verilog HDL haben Sie sich in der Vorlesung und den Ubungenbereits ausgiebig vertraut gemacht. Der Wunsch nach neuen, noch machtigeren Modellierungs-konzepten hat zu der Entwicklung von System-Beschreibungssprachen (System-Level Descrip-tion Language, SDL) gefuhrt. Die SystemC SDL bietet viele Vorteile und Moglichkeiten einerHDL wie Verilog (wenn auch nicht immer so kompakt), ermoglicht daruber hinaus aber auchganz neue Modellierungskonzepte wie das Transaction-Level-Modeling.

SystemC basiert auf C++. Diese Sprache wurde aus mehreren Grunden als Basis gewahlt. Er-stens konnen Hardware und Software mit SystemC in einer gemeinsamen Programmiersprachebeschrieben werden, denn alles, was mit C++ in der Software-Entwicklung moglich ist, ist auchmit SystemC moglich. Zweitens kann C++ durch seine fortgeschrittenen Sprachkonzepte wieTemplates, Mehrfachvererbung und Typedefs leicht um syntaktisch und semantisch vollig neueSprachelemente erweitert werden. Und drittens existieren fur C++ freie Open-Source-Compilerfur alle Betriebssysteme, so dass zur Simulation von SystemC-Modellen keine teuren Spezial-Tools gekauft werden mussen. Zum Gluck ist jedoch SystemC in erster Naherung eine eigeneSprache, eben eine SDL mit eigener Semantik, die trotzdem Vorteile von C++ integrieren kann.

Bei der Entwicklung von SystemC wurde großer Wert darauf gelegt, dass Hardware-Entwicklerbei Anwendung der Sprache nicht mit Fehler provozierenden und oft ungeliebten C/C++-Elementen wie Pointer in Beruhrung kommen. Dennoch kann SystemC seine Herkunft nichtimmer verbergen, so dass einige einfache Grundkenntnisse zu C++ helfen konnen, die Spracheauch fur fortgeschrittene Modellierungsaufgaben effektiv einzusetzen und die Fehlermeldungendes Compilers besser zu verstehen. Hierzu sei auf in den Ubungsraumen (und im Internet)ausliegende C++-Einfuhrungen und die Erfahrung Ihrer Betreuer verwiesen.

Um Ihnen den Einstieg leicht zu machen, behandeln die folgenden Abschnitte zunachst dieBeschreibung von Register-Transfer-Logik mit SystemC. Sie werden hierbei viele Ahnlichkeitenzu Verilog entdecken und in einfachen Ubungen ganz nebenbei die Grundlagen von SystemCerlernen.

Anschließend mochten wir Sie dann mit den SystemC-Konzepten zum Transaction-Level-Modeling bekannt machen. Diese moderne Entwurfstechnik fur komplexe Hardware-Software-Systeme werden Sie ebenfalls zunachst an kleinen Beispielen trainieren und anschließend ineiner eigenstandig zu losenden Aufgabe anwenden.

3.1 Hallo, Braunschweig!

Wie in Verilog sind auch in SystemC Module die fundamentalen Bausteine fur die Beschreibungvon Systemkomponenten. Sie brechen ein komplexes System in kleinere, besser beherrschbareTeile auf, verbergen interne Variablen und Algorithmen vor anderen Modulen und lassen sichhierarchisch schachteln.

Das Modul MeinModul in Listing 1 ist ein sehr einfaches Modul, denn es gibt lediglich einefreundliche Mitteilung aus und besitzt keine Schnittstelle nach außen. Ebenso enthalt es keineMethoden und Prozesse.

Der Quelltext des Moduls beginnt nach dem Modulkopf SC_MODULE(MeinModul) und ist durcheine offnende und eine schließende geschweifte Klammer begrenzt. Mit geschweiften Klammern

14 3.1 Hallo, Braunschweig!

werden in SystemC {wie in C++ und Java} Befehle gruppiert. Der Modulname MeinModul

wird im Modulkopf festgelegt.

Jedes Modul muss einen Konstruktor enthalten. Dieser wird immer dann aufgerufen, wenn dasModul instanziert wird (von einem Modul konnen beliebig viele Instanzen gebildet werden).Der Konstruktor wird mit SC_CTOR(MeinModul) gebildet und muss ebenfalls den Modulnamenenthalten. Der Konstruktor in Listing 1 enthalt nur einen einzigen Befehl, der die Meldung

”Hallo, Braunschweig!“ ausgiebt.

1 #include <systemc.h>

2

3 SC_MODULE(MeinModul)

4 {

5 SC_CTOR(MeinModul)

6 {

7 // Eine Info-Meldung ausgeben

8 cout << "Hallo , Braunschweig!" << endl;

9 }

10 };

Listing 1: Ein einfaches Modul (ex1.h)

In SystemC wird die Deklaration von Modulen von der Implementierung ihrer Funktionalitatstreng getrennt. Moduldeklarationen mit Konstruktor und Schnittstellenbeschreibung werdenin Header-Dateien mit der Endung .h abgelegt, z.B. ex1.h. Die Implementierung der Funktio-nalitat, d.h. der Methoden und Prozesse eines Moduls, erfolgt in einer .cpp-Datei, z.B. ex1.cpp.Da das Modul aus Listing 1 jedoch keine Funktionalitat besitzt, muss in diesem Beispiel auchkeine .cpp-Datei geschrieben werden.

cout reprasentiert in SystemC die Standardausgabe. Diese ist im Normalfall die Textkonsole,in der Sie die SystemC-Simulation starten. Sie kann aber auch in eine Datei umgelenkt werden.Um Zeichen auf die Standardausgabe cout auszugeben, genugt es, sie einfach mit dem Shift-Operator << in die Standardausgabe hineinzuschieben. Zum Beispiel gibt der Befehl

cout << "Simulationszeit ist " << sc_time_stamp() << " Sekunden." << endl;

die aktuelle Simulationszeit aus. Mit endl wird ubrigens ein Zeilenvorschub erzeugt.

1 #include "ex1.h" // Header-Datei ex1.h einbinden

2

3 int sc_main(int argc , char *argv[])

4 {

5 MeinModul m("EinModul");

6 sc_start();

7 }

Listing 2: Eine Testbench fur MeinModul (ex1 test.cpp)

Um das Modul MeinModul zu testen, wird eine Testbench benotigt. In ihr muss das Modulinstanziert und die SystemC-Simulation gestartet werden. Dies geschieht grundsatzlich in derMethode sc_main, die nur einmal in einem SystemC-Projekt enthalten sein darf. Sie ist der Ein-sprungpunkt fur den SystemC-Simulator. Listing 2 zeigt eine sc_main-Methode, die zunachstdas Modul MeinModul instanziert, dem Modul dabei den Instanznamen EinModul gibt undanschließend die SystemC-Simulation mit dem Befehl sc_start startet. Damit der Testbench


das Modul bekannt ist, muss der Modulkopf mit dem Befehl #include "ex1.h" am Beginn derTestbench eingebunden werden.

1 OBJS = ex1_test.o

2 MODULES = ex1_test

3

4 include /home/klingauf/sc_common.mk

Listing 3: Ein einfaches Makefile

Bevor die SystemC-Simulation ausgefuhrt werden kann, mussen Modul und Testbench miteinem C++-Compiler ubersetzt werden. Hierzu verwenden wir ein Makefile, dass alle notigenEinstellungen fur den Kompiler vornimmt, so dass der Kompiliervorgang sehr komfortabeluber das Kommando make gesteuert werden kann. Listing 3 zeigt das Makefile fur unserBeispielmodul.

Dieses Makefile in etwas universellerer Form finden Sie auch in Ihrem SystemC-Verzeichnis,so dass Sie es fur Ihre eigenen Projekte anpassen konnen. Dazu muss lediglich die mit OBJS

beginnende Zeile fur jede .cpp-Datei Ihres Projekts mit einem Eintrag vom Typ dateiname.o

erganzt werden. Die Endung .cpp wird dabei mit der Endung .o fur kompilierte Objektdateienersetzt. In die mit MODULES beginnende Zeile setzen Sie den Namen Ihrer Testbench ohneDateiendung ein.

3.2 Ubung 1

Offnen Sie Ihren Lieblings-Editor und legen Sie die Dateien ex1.h, ex1_test.cpp und Makefile

mit oben gezeigtem Inhalt an. Speichern Sie die Dateien in einem neuen, leeren Verzeich-nis. Wechseln Sie auf der Kommandozeile in dieses Verzeichnis und kompilieren Sie Ihr erstesSystemC-Projekt durch Eingabe des Befehls make. Wenn Sie keinen Tippfehler gemacht haben,sollte der Kompiliervorgang fehlerfrei durchlaufen. Starten Sie nun das soeben frisch erzeugteSimulationsmodell durch Eingabe des Befehls ./ex1_test.x. Betrachten Sie die Ausgabe Ihrerersten SystemC-Simulation. Sie sollte Listing 4 entsprechen.

1 klingauf@sauron ~/mydev/sc_prak/uebungen/src/examples $ make

2 /usr/bin/g++ -g -Wall -Wno -deprecated -I. \

3 -I/opt/cad/systemc -2.1/include -c ex1_test.cpp

4 /usr/bin/g++ -g -Wall -Wno -deprecated -I. \

5 -I/opt/cad/systemc -2.1/include -L. -L/opt/cad/systemc -2.1/lib -linux \

6 -o ex1_test.x ex1_test.o -lsystemc -lpthread -lm 2 >&1 | c++filt

7

8 klingauf@sauron ~/mydev/sc_prak/uebungen/src/examples $ ./ex1_test.x

9

10 SystemC 2.1_oct_12_04.beta --- Feb 1 2005 11:41:53

11 Copyright (c) 1996-2004 by all Contributors

12 ALL RIGHTS RESERVED

13

14 Info: MeinModul: Hallo , Braunschweig!

Listing 4: Ubersetzen und Ausfuhren eines SystemC-Modells

16 3.3 RTL-Modellierung mit SystemC

3.2.1 Die sc main-Methode

In dieser Ubung haben Sie Bekanntschaft mit der sc_main-Methode gemacht. Sie ist der Start-punkt jeder SystemC-Simulation, muss in einer .cpp-Datei stehen und darf nur genau einmalin Ihrem Design vorkommen. Der Methodenkopf

int sc_main(int argc, char *argv[])

ist ein Relikt der C++-Standardfunktion main und erhalt als Parameter die vom Benutzer ange-gebenen Kommandozeilenparameter (char *argv[]) sowie ihre Anzahl (int argc). In fortge-schrittenen Testbenches konnen diese Parameter verwendet werden, um verschiedene Testmodiauf der Kommandozeile auszuwahlen. In Ihren Designs konnen Sie sie komplett links liegenlassen.

3.3 RTL-Modellierung mit SystemC

Die Klassenbibliothek von SystemC deckt ein breites Spektrum von Modellierungskonzeptenab und wird kontinuierlich weiterentwickelt. Fur die Beschreibung von Register-Transfer-Logikmit SystemC wird nur eine Untermenge der SystemC-Elemente benotigt. Soll ein in SystemCbeschriebenes RTL-Modell durch einen Synthese-Compiler in ein Hardware-Gattermodell uber-fuhrt werden, mussen daruber hinaus bestimmte Entwurfsregeln beachtet werden. Diese sindmit den Synthese-Richtlinien bei Verilog vergleichbar [Sk6]

Bild 4: SystemC-Spracharchitektur

Bild 4 zeigt die Basisarchitektur von SystemC. Alle SystemC-Klassen setzen auf der C++-Standardbibliothek auf, sind durch Vererbung hierarchisch strukturiert und konnen grob in diefolgenden Sprachelement-Gruppen gegliedert werden:

• Kernelemente zur Beschreibung von Modulen, die Prozesse und Submodule enthalten unduber Kommunikationsschnittstellen (Ports, Interfaces) kommunizieren.


• Datentypen zur Reprasentation von Hardware-Registern (4-wertige Logik und Bitvekto-ren) und abstrakteren Daten (Integer, Fixpunkt- und Fließkommazahlen, zusammenge-setzte Typen).

• Kommunikationskanale (Channels) zur Verbindung von Ports uber verschiedene Kommu-nikationsmethoden, von einfachen Signalleitungen bis zu komplexen Networks-on-Chip.

3.3.1 Module

Funktionalitat wird in SystemC in Modulen gekapselt. Module bestehen aus dem Modulkopf(Modul-Deklaration) in einer .h-Datei und der Modul-Implementierung in einer oder mehreren.cpp-Dateien. Der Modulkopf wird mit SC_MODULE(Modulname) eingeleitet und enthalt Infor-mationen uber die folgenden Modulbestandteile:

• Ports, uber die das Modul mit anderen Modulen kommuniziert,

• Prozesse, die die Funktionalitat des Moduls beschreiben, und

• interne Variablen und Kanale zum Speichern von Zustandsinformationen.

Listing 5 zeigt den Modulkopf des Zero-Counters aus der Verilog-Ubungsaufgabe B.11 in Sy-stemC. Bild 5 zeigt eine grafische Darstellung dieses Quelltextes.

Bild 5: Modul ZeroCount mit Ports und einem Prozess


2

3 SC_MODULE(ZeroCount)

4 {

5 // Ports

6 sc_in_clk clock;

7 sc_in <bool > input;

8 sc_in <bool > nReset;

9 sc_out<sc_uint <4> > count;

10 sc_out<bool > overflow;

11

12 // Konstruktor

13 SC_CTOR(ZeroCount)

14 {

15 // Den einzigen Prozess im Konstruktor registrieren

16 SC_METHOD(main_action);

17 sensitive_pos << clock;

18 sensitive_neg << nReset;

19 dont_initialize();


20

21 // Ports initialisieren

22 count.initialize(0);

23 overflow.initialize(false);

24 }

25

26 // Prozesse beim Compiler bekannt machen

27 void main_action();

28

29 sc_uint <5> int_count; // interner Nullen-Zaehler

30 };

Listing 5: ZeroCount-Modulkopf mit Ports, einem Prozess und einer Variable (zerocount.h)

3.3.2 Ports

Die Schnittstelle von Modulen wird uber Ports gebildet. Bei der RTL-Modellierung mit Sy-stemC konnen Ports mit den input- und output-Deklarationen in Verilog verglichen werden.2

Das ZeroCounter-Modul aus Listing 5 besitzt funf Ports fur die Kommunikation mit anderenModulen, drei Eingabe- und zwei Ausgabe-Ports. Die Port-Typen zur RTL-Modellierung mitSystemC zeigt Tabelle 1.

Port Typ

sc_port Unkonfigurierter Portsc_in Eingabeportsc_out Ausgabeportsc_inout Bidirektionaler Portsc_in_clk Clock-Port

Tabelle 1: Ports fur die RTL-Modellierung

Fur jeden Port muss angegeben werden, welcher Datentyp daruber ubertragen werden soll. Diesgeschieht in < spitzen Klammern > zwischen dem Port-Typ und dem Portnamen. Zum Beispieldeklariert

sc_in<sc_logic> a;

einen Eingabeport mit Namen a, der Daten vom Typ sc_logic akzeptiert, also die Werte{0,1,x,z}. Mit

sc_inout<sc_lv<64> > b;

wird ein bidirektionaler Ein-/Ausgabe-Port erzeugt, der einen ganzen sc_logic-Vektor mit64-Bit Breite ubertragt. Beachten Sie in diesem Beispiel die Kaskadierung der so genanntenTemplate-Parameter (erkennbar an den spitzen Klammern), die in SystemC haufig verwendetwerden, um universelle Sprachelemente fur einen Anwendungsfall zu spezialisieren. So gibt derTemplate-Parameter einmal die Breite des Logikvektors sc_lv an und spezifiziert im ande-ren Fall den zu ubertragenden Datentyp beim sc_inout-Port. Zwischen aufeinander folgendenspitzen Klammern muss ein Leerzeichen eingefugt werden.

2Wir werden spater sehen, dass Ports aber ein viel machtigeres Schnittstellenkonzept darstellen.


Ports haben normalerweise einen undefinierten Zustand (’X’), bis zum ersten Mal darauf ge-schrieben wurde. Bei manchen Designs kann dies zu unerwunschtem Verhalten fuhren. Mit derinitialize-Anweisung kann dem vorgebeugt werden (siehe Listing 5 Zeilen 22, 23).

Ein spezieller Port ist sc_in_clk. An ihn konnen nur Taktsignale vom Typ sc_clock ange-schlossen werden.

3.3.3 Interfaces

Ein sc_port allein ermoglicht noch nicht die Ubertragung von Daten uber diesen Port. Er stelltlediglich eine Offnung in der sonst geschlossenen Modulgrenze dar, die man sich wie ein Lochin der Wand vorstellen kann, in das noch keine Steckdose eingesetzt wurde.

Um einen Port mit einer Schnittstelle zur Datenubertragung auszustatten, also in unseremBeispiel eine Euro-Steckdose in die Wand einzusetzen, muss der Port an ein Interface gebunden

werden.

Bei den spezialisierten Ports sc_in, sc_out, sc_inout und sc_in_clk ist dies bereits gesche-hen, sie sind an die Standard-Interfaces sc_signal_in_if und sc_signal_inout_if gebunden.Diese Interfaces stellen die Port-Zugriffsmethoden read() und write() zur Verfugung (sog. In-

terface Method Calls, IMC). Auf die IMCs eines Ports wird uber den Operator -> zugegriffen.

Der Eingabeport

sc_in<sc_lv<64> > a;

wird also folgendermaßen ausgelesen:

sc_lv<64> in;

in = a->read(); .

Der Befehl

b->write(42);

schreibt den Wert 42 auf den Ausgabeport

sc_out<int> b; .

Fur die RTL-Modellierung mit SystemC werden nur die spezialisierten Ports sc_in, sc_outund sc_inout benotigt, die bereits an ein Interface gebunden sind. Das Binden kann aber auchmanuell durchgefuhrt werden, so dass sich fur obigen Eingabeport a die folgende Schreibweiseergibt:

sc_port<sc_signal_in_if<sc_lv<64> > > a; .

Um nun die Verwirrung perfekt zu machen (bzw. positiv gesprochen Verwirrung zu vermeiden),sei noch auf eine weitere Besonderheit der Ports sc_in, sc_out und sc_inout hingewiesen: aufsie kann auch direkt, also ohne Einsatz der write- und read-Methoden zugegriffen werden:

if (a == 0)

b = 42;

ist aquivalent zu der Schreibweise

if (a.read() == 0)

b.write(42); .


3.3.4 Prozesse

Der Zugriff auf die Ports eines Moduls findet ausschließlich in Prozessen statt. SystemC bietetmehrere Arten von Prozessen an, fur die einfache RTL-Modellierung wird aber am besten dieSC_METHOD verwendet.

Alle Prozesse eines Moduls mussen im Konstruktor deklariert werden. Fur den Prozessmain_action des Zero-Counters aus Listing 5 geschieht dies uber

SC_METHOD(main_action);

sensitive_pos << clock;

sensitive_neg << nReset;

dont_initialize();

Mit der ersten Zeile wird der Prozess main_action als SC_METHOD im SystemC-Kernel regi-striert.

Die beiden Befehle sensitive_pos und sensitive_neg geben an, dass der Prozess immer dannaufgerufen werden soll, wenn an dem Port clock eine positive Flanke oder an dem Port nReseteine negative Flanke auftritt. Dies ist der Fall, wenn sich ein an den Port angeschlossenes Signalandert (z.B. von ’0’ auf ’1’).

Neben sensitive_pos und sensitive_neg fur die Modellierung flankengesteuerter Logik gibtes noch den Befehl sensitive, der auf jedes Ereignis an einem Port reagiert. Die sensitive-Befehle konnen mit der Aktivierungsliste von always-Blocken in Verilog verglichen werden(@posedge A, @A).

Normalerweise wird jeder Prozess bei der Modul-Instanzierung automatisch einmal ausgefuhrt.Dies kann fur die Initialisierung von Variablen und State-Machines verwendet werden, machtaber im Falle des Zero-Counters keinen Sinn und kann sogar zu Fehlern fuhren (falscher Wertam Ausgabeport). Daher wird die Initialisierung durch dont_initialize() fur den Prozessmain_action deaktiviert. Der Prozess wird erst ausgefuhrt, wenn ein Ereignis in der durchsensitive_pos und sensitive_neg beschriebenen Aktivierungsliste stattfindet.

Durch SC_METHOD(Prozessname)werden Prozesse im Modulkonstruktor registriert. Diese mus-sen dem SystemC-Compiler allerdings bereits bekannt gemacht worden sein, was durch denMethodenrumpf außerhalb des Konstruktors erreicht wird:

void main_action();

Fur jede SC_METHOD eines Moduls muss ein derartiger Methodenrumpf angegeben werden.

Die Implementierung von Prozessen wird in der .cpp-Datei vorgenommen. Listing 6 zeigt dieSC_METHOD(main_action) des Zero-Counters.

1 #include "zerocount.h"

2

3 void ZeroCount::main_action()

4 {

5 if (nReset == 0) // asynchroner Reset

6 {

7 int_count = 0;

8 overflow = 0;

9 }

10 else // positive Taktflanke

11 {


12 if (!input && ! int_count[4])

13 {

14 int_count++; // Nullen zaehlen

15 }

16 else if (input) // wenn 1 kommt , Ausgaenge zuruecksetzen

17 {

18 int_count = 0;

19 overflow = 0;

20 }

21 }

22

23 // Internen Zaehler auf Ausgaenge ausgeben

24 count = int_count.range(3,0);

25 overflow = int_count[4];

26 }

Listing 6: zerocount.cpp

In der ersten Zeile wird durch #include "zerocount.h" der Modulkopf eingebunden. Anschlie-ßend folgt der Quelltext fur den Prozess main_action. Dieser beginnt mit dem Methodenrumpf

void ZeroCount::main_action() { ,

wobei hier – im Gegensatz zur Deklaration im Modulkopf – der Modulname ZeroCount gefolgtvon zwei Doppelpunkten vor den Prozessnamen gesetzt werden muss. Diese Schreibweise istnotwendig, damit der Compiler in der Lage ist, Deklaration und Implementierung zuzuordnen.

Da es sich bei dem Prozess um eine SC_METHOD handelt, wird der Prozess jedesmal aufgerufen,wenn ein Ereignis in seiner Sensitivitatsliste auftritt. Dies ist bei jeder positiven Flanke desSignals clock der Fall sowie bei jeder negativen Flanke des Signals nReset.

Beachten Sie, dass die Variable int_count keine lokale Variable des Prozesses main_action,sondern eine Instanzvariable des Moduls ist. Das ist wichtig, denn ware sie lokal deklariert,wurde die Variable bei jeder Prozessaktivierung neu initialisiert.

Das Lesen und Schreiben der Eingabe- und Ausgabe-Ports des ZeroCounter-Moduls erfolgtin dieser Implementierung mit dem vereinfachten Zugriffsschema. Dabei werden die Port-Zugriffsmethoden read und write nicht explizit aufgerufen, dies geschieht automatisch.

3.3.5 Ubung 2

In dieser Ubung soll der Zero-Counter aus obigem Beispiel implementiert und mit Hilfe einerTestbench auf korrekte Funktion getestet werden. Erzeugen Sie dazu die Dateien zerocount.h

und zerocount.cpp mit dem in den Listings 5 und 6 abgedruckten Inhalt.

Um den Zero-Counter mit Testdaten zu versorgen, wird ein weiteres ModulZeroCount_Stimulus benotigt. Dieses soll synchron zum Systemtakt Testvektoren furdie Eingange des Zero-Counters erzeugen. Eine typische Implementierung ist in den Listings 7und 8 gegeben.


2

3 SC_MODULE(ZeroCount_Stimulus)

4 {


5 // Ports

6 sc_in <bool > clock;

7 sc_out<bool > output;

8 sc_out<bool > nReset;

9

10 // Konstruktor

11 SC_CTOR(ZeroCount_Stimulus)

12 : pos(-10) // Variable pos auf Wartezeit bis

13 // zum Ausloesen des nReset initialisieren

14 {

15 SC_METHOD(main_action);

16 sensitive_pos << clock;

17 }

18

19 protected:

20 // Prozess

21 void main_action();

22

23 // Membervariablen

24 int pos;

25 };

26

27 // Testvektor

28 static const char stimdata[] = {

29 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,

30 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

31 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0,

32 1, 1, 0, 0, 0, 1, 0, 1, 0, 1, 1, 0, 0, 0, 1

33 };

34 // Laenge des Testvektors

35 #define STIMDATA_LENGTH 60

Listing 7: Modulkopf des Stimulus-Moduls (zerocount stimulus.h)

1 #include "zerocount_stimulus.h"

2

3 void ZeroCount_Stimulus::main_action()

4 {

5 if (pos < 0)

6 {

7 nReset = 0;

8 output = 1;

9 pos++;

10 }

11 else if (pos < STIMDATA_LENGTH)

12 {

13 nReset = 1;

14 output = stimdata[pos++];

15 }

16 }

Listing 8: Implementierung des Stimulus-Moduls (zerocount stimulus.cpp)


Um die Module ZeroCount und ZeroCount_Stimulus zu instanzieren und die Ausgangs-Portsdes Stimulus-Moduls mit den Eingangs-Ports des Zero-Counters zu verbinden, wird eine Test-bench benotigt. Listing 9 zeigt eine entsprechende Implementierung.


2 #include "zerocount.h"

3 #include "zerocount_stimulus.h"

4


6 {

7 // Signale zum Verbinden der Modul -Ports

8 sc_signal <bool > zc_input , zc_nReset , zc_overflow;

9 sc_signal <sc_uint <4> > zc_count;

10

11 // Takt erzeugen

12 sc_clock zc_clk("Clk_10MHz" , 100, SC_NS);

13

14 // Modul ZeroCount instanzieren

15 ZeroCount zc("Zero_Counter");

16

17 // Ports des Zero-Counters mit Signalen verbinden

18 zc.clock(zc_clk);

19 zc.input(zc_input);

20 zc.nReset(zc_nReset);

21 zc.count(zc_count);

22 zc.overflow(zc_overflow);

23

24 // Modul ZeroCount_Stimulus instanzieren

25 ZeroCount_Stimulus zc_s("Stimulus");

26

27 // Ports des Stimulus -Moduls mit Signalen verbinden

28 zc_s.clock(zc_clk);

29 zc_s.output(zc_input);

30 zc_s.nReset(zc_nReset);

31

32 // Simulation starten

33 sc_start(10, SC_MS); // simuliere 10ms

34

35 return 0;

36 }

Listing 9: zerocount testbench.cpp

Schließlich fehlt noch ein letztes Puzzlestuck zur Vervollstandigung der Testumgebung fur denZero-Counter: Ein ZeroCount_Monitor-Modul muss mit den Ausgangen des Zero-Countersverbunden werden und bei jeder Signalanderung eine entsprechende Information ausgeben.

Entwerfen und implementieren Sie selbstandig ein passendes ZeroCount_Monitor-Modul, dascout-Anweisungen benutzt, um den Signalverlauf der Ausgange des Zero-Counters auf derKommandozeile darzustellen.

Verwenden Sie das Makefile aus Ubung 1, um Ihr Gesamtmodell zu kompilieren. Andern Siedieses dafur wie in Listing 10 gezeigt.

1 OBJS = zerocount.o zerocount_stimulus.o zerocount_monitor.o \


2 zerocount_testbench.o

3 MODULES = zerocount_testbench


Listing 10: Makefile fur den Zero-Counter

Fuhren Sie Ihre Testumgebung aus und kontrollieren Sie die Signalverlaufe. Arbeitet der Zero-Counter spezifikationsgemaß?

3.3.6 Kommunikationskanale (Channels)

Verbindungen zwischen den Ein- und Ausgabe-Ports von Modulen werden in SystemC uberKommunikationskanale, die so genannten Channels, hergestellt. Zur Verbindung der drei Mo-dule ZeroCount, ZeroCount_Stimulus und ZeroCount_Monitor in Ubung 2 haben Sie Chan-nels schon eingesetzt, namlich in Form des sc_signal-Kommunikationskanals. Gemeinsam mitModulen, Prozessen und Ports stellen Channels die Grundkomponenten der Systembeschrei-bungssprache SystemC dar. Bild 6 macht dies anhand einer moglichen Losung fur die Zero-Counter-Testbench aus Ubung 2 nochmal deutlich.

Bild 6: Channels am Beispiel der Zero-Counter-Testumgebung

Channels konnen beliebig kompliziert aufgebaut sein und komplette Kommunikationsprotokollewie z.B. TCP/IP simulieren. Im einfachen Fall stellen sie aber simple Signalleitungen dar, diemit den Wires in Verilog verglichen werden konnen. Hierfur bietet SystemC den Channeltypsc_signal:

sc_signal<bool> clock;

sc_signal<sc_lv<64> > databus;

sc_signal-Channels transportieren beliebige Standard-SystemC-Datentypen von einemAusgabe-Port zu einem Eingabe-Port. Sie nehmen dabei keine Modifikationen an den trans-portierten Daten vor und verzogern auch nicht ihre Auslieferung. Fur die RTL-Modellierungvon Verbindungsleitungen zwischen Modulen ist der sc_signal-Channel das Mittel der Wahl.


Bei der Deklaration eines Channels muss stets auch der zu transportierende Datentyp spe-zifiziert werden. Auf diese Weise sind Channels universell einsetzbar und konnen neben denStandard-Datentypen auch benutzerdefinerte Typen transportieren. Diese Eigenschaft wird beider RTL-Modellierung aber nicht benotigt, wir werden Sie beim Transaction-Level-Modelingwieder aufgreifen.

In der Testbench aus Ubung 2 werden drei Channels mit dem Datentyp bool und ein Channelmit dem Datentyp sc_uint<4> instanziert (Listing 9, Zeilen 7,8). Die Instanzierung findetautomatisch durch die Deklaration des Channels statt, hierbei muss nicht – wie bei Modulen –ein Name als Parameter ubergeben werden.

Daruber hinaus wird ein Taktsignal mit dem speziellen Channel sc_clock generiert. DieserChanneltyp kann nur mit Clock-Ports vom Typ sc_in_clk verbunden werden. Bei der Dekla-ration wird ein Name und die Dauer eines Taktzyklus angegeben. Dabei konnen Piko-, Nano,Mikro- und Millisekunden sowie Sekunden spezifiziert werden (SC_PS, SC_NS, SC_US, SC_MS,SC_SEC):

sc_clock clk1("Clk_27MHz", 36, SC_NS);

sc_clock clk2("Clk_4KHz", 250, SC_US);

Die Verbindung zwischen Ports und Channel kann in SystemC auf zwei Arten hergestellt wer-den. Beim Named Mapping wird jeder Port eines Moduls explizit an Hand seines Namens miteinem Channel verbunden:

sc_clock clk("Clk_100MHz", 10, SC_NS);

sc_signal<bool> data, reset;

ZeroCount zc("My_ZeroCount");

zc.clock(clk);

zc.input(data);

zc.reset(reset);

Eine kurzere Schreibweise ermoglicht das Positional Mapping. Hierbei wird vorausgesetzt, dassSie die Reihenfolge der Portdeklarationen in dem instanzierten Modul kennen:

sc_clock clk("Clk_100MHz", 10, SC_NS);

sc_signal<bool> data, reset;

ZeroCount zc("My_ZeroCount");

zc(clk, data, reset);

Bevor Sie die Simulation Ihres SystemC-Modells durch Aufruf der Methode sc_start starten,muss jeder Port in Ihrem System mit einem Channel verbunden worden sein. Ansonsten er-wartet Sie eine Fehlermeldung. Demgegenuber muss aber nicht jeder Channel mit einem Portverbunden sein. Channels konnen auch als modulinterne Signale verwendet werden, um Datenzwischen nebenlaufigen Prozessen auszutauschen oder einfach nur zwischenzuspeichern.

3.4 Datentypen

SystemC bietet eine breite Palette von Datentypen, mit denen viele Standardaufgaben fur dieSpeicherung, Ubertragung und Manipulation von Daten in Hardware-Software-Systemen kom-fortabel gelost werden konnen. Alle SystemC-Datentypen bieten die gleiche Schnittstelle zumZugriff auf die gespeicherten Informationen und Daten konnen leicht zwischen verschiedenenDatentypen ausgetauscht werden.

26 3.4 Datentypen

3.4.1 Hardwarenahe Datentypen

Wie Verilog bietet SystemC spezielle Datentypen, mit denen die Eigenschaften typischerHardware-Signale modelliert werden konnen (Tabelle 2).

Datentyp Beschreibung

sc_bit 2-wertiges Bit, stellt die Symbole ’0’ und ’1’ darsc_logic 4-wertiges Bit, stellt die Symbole ’0’, ’1’, ’X’ und ’Z’ darsc_bv Vektor von 2-wertigen Bits (

”Bitvektor“)

sc_lv Vektor von 4-wertigen Bits (”Logikvektor“)

Tabelle 2: Hardwarenahe Datentypen

Wahrend sc_bit und sc_logic genau ein Bit speichern, konnen die Vektoren sc_bv und sc_lv

beliebig breit sein:

sc_bv<32> address_32bit;

sc_lv<11> opcode_11bit;

Da die 4-wertigen Datentypen einen hoheren Simulationsaufwand erfordern, sollten sie nurverwendet werden, wenn der hochohmige Zustand ’Z’ auch benotigt wird (z.B. bei Tristate-Bussen).

Operator Beschreibung

~L Bitweise NegationL & 1 Bitweises ANDL &= 1 Bitweises AND zuweisen (L nimmt den neuen Wert an)L | 1 Bitweises ORL |= 1 Bitweises OR zuweisen (L nimmt den neuen Wert an)L ^ 1 Bitweises XORL ^= 1 Bitweises XOR zuweisen (L nimmt den neuen Wert an)L == 1 Auf Gleichheit prufenL != 1 Auf Ungleichheit prufenL << i Shiften um i Bits nach linksL <<= i Shiften um i Bits nach links und zuweisenL >> i Shiften um i Bits nach rechtsL >>= i Shiften um i Bits nach rechts und zuweisen

Tabelle 3: Bit-Operationen fur SystemC-Datentypen

Auf den in Tabelle 2 gelisteteten Datentypen konnen die in Tabelle 3 gezeigten Operationenausgefuhrt werden.

Daruber hinaus konnen Daten zwischen verschiedenen Datentypen ausgetauscht werden, wennsie kompatibel sind:

bool a;

sc_logic b;

a = 1;

b = a;


Einzelne Bits eines breiteren Datentyps konnen mit dem []-Operator abgegriffen werden. Indem folgenden Beispiel wird zunachst das vierte Bit des Bitvektors bus auf ’0’ gesetzt undanschließend das dreizehnte Bit ausgelesen.

sc_bv<32> bus;

bus[4] = 0;

sc_bit i = bus[13];

Bitbereiche (Range) eines breiteren Datentyps konnen mit dem ()-Operator adressiert werden:

sc_bv<32> data;

data(31,16) = "0b0111001111110011";

data(15,0) = 4293; // val = 0b1000011000101

sc_bv<16> val = data(31,16); // val = 0b0111001111110011

Auf diese Weise konnen auch Bereiche innerhalb eines Bitvektors kopiert werden,

data(5,3) = data(10,8); // data(5,3) = 0b011

und durch Andern der Zugriffsreihenfolge werden Bitsequenzen umgedreht:

data(4,3) = data(3,4); // data(4,3) = 0b01

3.4.2 Textreprasentation von Daten

Wie die verschiedenen Beispiele gezeigt haben, konnen Daten in den unterschiedlichsten Forma-ten reprasentiert und zwischen verschiedenen Datentypen ausgetauscht werden. Stringliteralebieten die Moglichkeit, Daten in menschenlesbarer Form bzgl. verschiedener Basen darzustellen.Tabelle 4 zeigt die wichtigsten Stringliterale von SystemC.

Stringliteral Format Numrep Beispiel

0d Dezimal SC_DEC 0d420b Binar SC_BIN 0b0111010o Oktal SC_OCT 0o7200x Hexadezimal SC_HEX 0xc0ffee

Tabelle 4: Stringliterale

Mit der Methode to_string() kann jeder SystemC-Datentyp in einen String konvertiert wer-den, um seinen Inhalt in leserlicher Form auszugeben. Dabei kann das Ausgabeformat uberden Parameter sc_numrep beeinflusst werden, indem einer der Werte aus der Numrep-Spaltein Tabelle 4 eingesetzt wird. Folgender Quelltext

sc_bv<16> b = "0xaffe";

cout << b.to_string(SC_BIN);

ergibt die Ausgabe 0b1010111111111110 auf der Kommandozeile.3

3Anmerkung:”cout << String“ ist die einfachste Moglichkeit in C++, Text auf der Kommandozeile auszu-

geben. cout stellt dabei einen Stream dar, in den der auszugebende Text mit dem Shift-Operator hineinge-schoben wird.

28 3.5 Ubung 3

3.4.3 Weitere Datentypen

Die hardwarenahen Datentypen aus Abschnitt 3.4.1 sollten immer dann verwendet werden,wenn Bit-Operationen wie AND und OR auf Hardwaresignale angewendet werden sollen. Furdie Ausfuhrung von Berechnungen sind sie dagegen (anders als in Verilog) ungeeignet. Hierfurstehen die in Tabelle 5 gezeigten weiteren Datentypen zur Verfugung, mit denen genau soaddiert, subtrahiert, multipliziert, etc. werden kann wie mit den aus der Softwareentwicklungbekannten Standardtypen byte, int und long. Daruber hinaus konnen Sie in der Bitbreite freikonfiguriert werden, so dass sogar Berechnungen mit beliebig breiten Zahlen moglich werden.Es werden die gleichen Zugriffsmethoden wie auf die hardwarenahen Datentypen – auch aufeinzelne Bits und Bitbereiche – unterstutzt, und sie sind ebenfalls in Hardware synthetisierbar.

Datentyp Beschreibung

sc_int Integer mit definierbarer Bitbreite bis zu 64 Bitsc_bigint Integer mit unbegrenzter Bitbreite uber 64 Bitsc_uint Vorzeichenloser Integer mit definierbarer Bitbreite bis zu 64 Bitsc_biguint Vorzeichenloser Integer mit unbegrenzter Bitbreite uber 64 Bit

Tabelle 5: Weitere Datentypen

3.4.4 Konkatenation

Integer-Datentypen und Vektoren konnen mit Hilfe des ( Klammer-Operators ) konkateniertwerden, um sie zu neuen Bitfolgen zusammenzufugen. Die folgenden Beispiele zeigen gultigeKonkatenationen:

sc_uint<8> u1 = 2; // "0b00000010"

sc_uint<2> u2 = 1; // "0b01"

sc_uint<8> u3 = (1, u1(3,0), u2, u2[0]); // u3 = "0b10010011"

sc_uint<4> u4 = (u2(0,1),u2); // u4 = "0b1001"

3.5 Ubung 3

In dieser Ubung soll das Hantieren mit Modulen, Prozessen, Ports, Channels und Datentypentrainiert werden. Betrachten Sie dazu den 4-Bit-Addierer aus Beispiel 2.11 in [Sk2].

3.5.1 Aufgabe 3.1

Implementieren Sie zunachst das dort gezeigte Verilog-Modul one_bit_adder in SystemC,wobei Sie den Datentyp sc_logic fur die Ein- und Ausgabeports des Addierers verwenden.Da sc_logic keine arithmetischen Operationen unterstutzt, mussen Sie die Berechnung derAusgange SUM und CARRY_OUT mit Hilfe von AND-, OR-, XOR- und SHIFT-Operationen im-plementieren. Legen Sie hierzu eine Wahrheitstabelle an und uberlegen Sie die notwendigenLogikoperationen.

Modellieren Sie anschließend den four_bit_adder aus dem Vorlesungsbeispiel 2.11 ebenfalls inSystemC, indem sie vier one_bit_adder-Module instanzieren und mit sc_signal<sc_logic>-Channels verdrahten.


Betten Sie das four_bit_adder-Modul in eine Testumgebung wie in Ubung 2 ein und prufenSie die korrekte Funktionsweise Ihres Addierers mit Hilfe von Teststimuli und Ausgaben aufder Kommandozeile.

3.5.2 Aufgabe 3.2

Sie werden festgestellt haben, dass der Zugriff auf den sc_logic-Datentyp gewohnungsbedurf-tig ist. Insbesondere konnen damit keine Standard-Rechenoperationen wie { c = a + b; }

ausgefuhrt werden, was die Modellierung des Addierers nicht gerade erleichtert.

Wenn der hochohmige Zustand ’Z’ nicht benotigt wird, ist es daher einfacher, den Datentypsc_uint einzusetzen. Andern Sie den one_bit_adder entsprechend und fassen Sie dabei auchdie Ausgange SUM und CARRY_OUT zu einem 2-Bit breiten sc_uint zusammen. Nun konnen Siedie Addition genau so wie in Verilog implementieren, unter Anwendung der Rechenoperation’+’ und der Konkatenation.

3.6 Parallelitat und Zeit

Wie bei Verilog geschieht die Ausfuhrung von SystemC-Modellen durch einen Simulator. Dieserwird in der sc_main-Methode durch Aufruf des Befehls sc_start gestartet.

In Hardware arbeiten alle Teile gleichzeitig und parallel zu allen anderen. Erst die Einfuhrungeines Taktsignals clk kann Ordnung in das Chaos bringen, und die Aufteilung von Datenpfadenin Blocke aus kombinatorischer Logik, die zwischen taktgesteurte Register plaziert werden,ermoglicht ein vorhersehbares Verhalten der Schaltung (Register-Transfer-Logik).

Um diese Eigenschaften von Parallelitat und Zeit zu beschreiben, bietet SystemC sehr ahnlicheModellierungskonzepte wie Verilog. Der Simulator selbst arbeitet genau wie Verilog-Simulatorenmit Simulationszeitpunkten, fur die einzelne Ereignisse berechnet werden (ereignisgesteuerteSimulation in [Sk3]).

Folgende SystemC-Konstrukte zur Modellierung von Parallelitat und Zeit stehen zur Verfugung:

• Prozesse arbeiten grundsatzlich parallel: SC_METHOD, SC_THREAD.

• Ereignisse und Sensitivitatslisten synchronisieren und halten nebenlaufige Prozesse an:sc_event, sensitive, sensitive_pos, sensitive_neg.

• wait-Anweisungen synchronisieren und halten die Ausfuhrung von SC_THREAD-Prozessenan, bis ein Ereignis eingetreten oder eine Zeitspanne abgelaufen ist.

3.6.1 Threads

Bisher haben Sie SC_METHOD-Prozesse verwendet, um Register-Transfer-Logik zu modellieren.Prinzipiell konnen damit beliebige Programme realisiert werden, SC_METHOD-Prozesse konntenalso auch fur das Hardware-Software-Codesign eingesetzt werden. Bei mehreren nebenlaufigenProgrammfaden (Software-Entwicklung) kann der Quelltext aber sehr unubersichtlich werden,da SC_METHOD-Prozesse grundsatzlich nur durch Signalanderungen und Ereignisse ausgefuhrtwerden, was nicht der verwohnten Denkweise von Software-Entwicklern entspricht.

30 3.6 Parallelitat und Zeit

Mit dem zweiten Prozess-Typ SC_THREAD bietet SystemC eine komfortable Moglichkeit, neben-laufige Programmfaden zu beschreiben. Der wichtigste Unterschied von SC_THREAD-Prozessengegenuber SC_METHOD-Prozessen ist, dass ihre Ausfuhrung durch wait-Anweisungen unterbro-chen werden kann. Dadurch konnen SC_THREAD-Prozesse eine Endlosschleife enthalten undblockieren dennoch nicht endlos alle anderen Prozesse, denn spatestens beim nachsten wait

wird die Kontrolle abgegeben.

SC_THREAD-Prozesse mussen wie SC_METHOD-Prozesse im Modulkonstruktor deklariert und imModulkopf definiert werden:


2

3 SC_MODULE(Hugo)

4 {

5 SC_CTOR(Hugo)

6 {

7 SC_THREAD(rechne); // Deklaration

8 }

9

10 void rechne(); // Definition

11 };

Listing 11: SC THREAD-Deklaration und -Definition

Auch SC_THREAD-Prozesse konnen mit einer Sensitivitatsliste ausgestattet werden. Dies machtaber in den meisten Fallen wenig Sinn, da SC_THREAD-Prozesse grundsatzlich als Endlosschleifeangelegt werden sollten. Stattdessen kann aber innerhalb des SC_THREAD an jeder Stelle dyna-

misch auf ein Ereignis wie eine Signalanderung gewartet werden. Naheres dazu wird in denfolgenden Abschnitten erlautert.

3.6.2 Events und Wait

Events werden in SystemC uberall dort eingesetzt, wo lokale Ereignisse Reaktionen an andererStelle nach sich ziehen. So lost zum Beispiel jede Wertanderung eines sc_signal ein Event aus,das an alle mit diesem Signal verbundenen Systemkomponenten gemeldet wird: Ports, Channelsund Prozesse, die

”sensitive“ auf dieses Signal sind.

Events konnen implizit im Hintergrund entstehen, wenn z.B. ein Wert auf einen Port geschrie-ben wird. Explizit modelliert werden konnen sie mit dem Datentyp sc_event:

sc_event e;

Auf das Auslosen eines sc_event kann innerhalb von SC_THREAD-Prozessen mit Hilfe der wait-Anweisung gewartet werden:

wait(e);

Mit Hilfe des notify-Befehls kann ein Event ausgelost werden:

e.notify(); // sofort auslosen

e.notify(20, SC_MS); // auslosen in 20ms

Werden mehrere notify-Anweisungen nacheinander auf demselben Event ausgefuhrt,”gewinnt“

dasjenige mit der kurzesten angegebenen Zeitspanne:


e.notify(100, SC_NS); // auslosen in 100ns

e.notify(200, SC_NS); // wirkungslos, vorheriges ist fruher

e.notify(20, SC_NS); // umandern auf 20ns

Ist die geplante Auslosung eines sc_event noch nicht geschehen, kann sie mittels cancel ver-hindert werden:

e.cancel(); // doch nicht auslosen

Listing 12 zeigt eine typische Anwendung von Events. Zwei Prozesse fuhren nebenlaufig Berech-nungen aus und sollen an einer bestimmten Stelle miteinander zeitlich synchronisiert werden,z.B. um auf ein Rechenergebnis des anderen Programmfadens zu warten. Wurden an dieser Stel-le auch Daten zwischen den Prozessen ausgetauscht, ware ein sc_signal das Mittel der Wahl.Hier kommt es aber nur auf die zeitliche Synchronisation an, was mit einem Event schnellerledigt ist.

1 void a()

2 {

3 wait(e); // auf Prozess b warten

4 rechnen();

5 }

6

7 void b()

8 {

9 rechnen();

10 e.notify(); // Prozess a benachrichtigen

11 mehr_rechnen();

12 }

Listing 12: Prozess-Synchronisation mit Event

In Listing 12 wird die wait-Anweisung zum Warten auf ein Event eingesetzt:

wait(e); // warte auf Event e

Durch Angabe einer Liste von Events konnen auch mehrere Events gleichzeitig abgehort werden:

wait(e1 e2 e3); // warte auf eines der Events e1, e2, e3

wait(e1 & e2 & e3); // warte bis alle Events ausgelost wurden

Daruber hinaus kann mit wait auch eine bestimmte Zeitspanne gewartet werden:

wait(20, SC_MS); // warte 20ms

wait(500, SC_SEC); // warte 500s

wait(1.5, SC_NS); // warte 1,5ns

Schließlich konnen diese beiden Moglichkeiten zu einem Timeout fur das Warten auf ein Ereigniskombiniert werden:

wait(100, SC_MS, e1 & e2); // warte maximal 100ms auf e1 und e2

wait-Anweisungen durfen grundsatzlich nur in SC_THREAD-Prozessen stehen. SC_METHOD-Prozesse dagegen sind zeitlos; ihre Ausfuhrung geschieht in einer einzigen Simulator-Zeitscheibeund kann nicht unterbrochen werden.

32 3.7 Ubung 4

3.6.3 Nicht-blockende Zuweisung in SystemC

Aus Verilog kennen Sie die nicht-blockende Zuweisung, mit der Parallelitat auch innerhalbeines always-Blocks beschrieben werden kann. [Sk2,3] setzt sich intensiv mit diesem Themaauseinander, das grundlegende Bedeutung fur die Logiksynthese hat.

Ein direkt vergleichbares Konstrukt bietet SystemC nicht. sc_signal-Datentypen legen aberexakt das selbe Verhalten an den Tag wie reg-Register in Verilog, die mit der nicht-blockendenZuweisung beschrieben werden. Zuweisungen an sc_signal-Datentypen werden zunachst in ei-nem temporaren Zwischenregister vorgemerkt und dann erst am Ende des Simulationszeitpunkts

findet die tatsachliche Zuweisung statt.

3.7 Ubung 4

3.7.1 Aufgabe 1

In dieser Ubung soll die nicht-blockende Zuweisung bei sc_signal-Datentypen im SystemC-Simulator untersucht werden. Geben Sie dazu den Quelltext aus Listing 13 in eine Dateinonblock.cpp ein und kompilieren Sie das Modell mit einem angepassten Makefile. Versu-chen Sie, die Ausgaben des Modells vorherzusagen und vergleichen Sie Ihre Vermutung mitdem Ergebnis.


2

3 SC_MODULE(NonBlock)

4 {

5 sc_in_clk clk;

6

7 SC_CTOR(NonBlock)

8 : s1(1), s2(2)

9 {

10 SC_METHOD(a);

11 sensitive_pos << clk;

12 dont_initialize();

13 }

14

15 sc_signal <int > s1 , s2, sen;

16

17 void a()

18 {

19 s1 = s2;

20 s2 = s1;

21 cout << s1 << ", " << s2 << endl;

22 }

23 };

24

25

26 int sc_main(int argc , char *argv[]) {

27 NonBlock nb("NB");

28 sc_clock clk("Clock_100MHz" , 10, SC_NS);

29 nb.clk(clk);

30 sc_start(100, SC_NS);


31 return 0;

32 }

Listing 13: Nicht-blockende Zuweisung in SystemC

3.7.2 Aufgabe 2

Fugen Sie Ihrem Design aus Aufgabe 1 den SC_THREAD aus Listing 14 hinzu:

1 void b()

2 {

3 while (true)

4 {

5 wait(s1.value_changed_event());

6 s2 = s1*2;

7 }

8 }

Listing 14: Erweiterung fur Aufgabe 2

Registrieren Sie den SC_THREAD im Modulkonstruktor und kompilieren Sie das Modell erneut.Versuchen Sie vorauszusagen, wie sich die Ausgabe andert.

3.7.3 Aufgabe 3

Andern Sie die wait-Anweisung aus Listing 14 in

wait(clk.posedge_event());

und erklaren Sie das neue Ergebnis.

34 3.7 Ubung 4

4 Transaction-Level-Modeling 35

4 Transaction-Level-Modeling

Das Transaction-Level-Modeling, oder kurz TLM, bezeichnet eine Entwurfsmethodik, bei derdas Verhalten (Funktionen, Prozesse) und die Kommunikation (Busse, Netzwerke, Speicher-schnittstellen) eines Hardware-Software-Systems streng voneinander getrennt werden. Manspricht in diesem Zusammenhang auch von Orthogonalisierung.

Bild 7: Sehr einfaches TLM-Modell eines MP3-Players

Bild 7 verdeutlicht am Beispiel eines sehr einfachen MP3-Player-Modells nochmals die wich-tigsten Elemente des Transaction-Level-Modeling. Damit mochte man die folgenden Vorteileerreichen:

• Einmal implementierte Funktionsblocke (Video-Decoder) konnen in anderen Systemenwieder verwendet werden, auch wenn dann eine vollig andere Kommunikationsarchitek-tur zum Einsatz kommt. Dies konnte z.B. einem Hersteller erleichtern, seinen digitalenFernsehempfanger als PCI-Karte, USB-Stick und Set-Top-Box anzubieten.

• Die Schnittstelle zwischen einzelnen Hardware- und Softwareblocken ist nicht mehr mit ih-rer Implementierung verschmolzen, sondern kann unabhangig entwickelt werden. Dadurchkonnen verschiedene Simulationsmodelle von Bussen und Netzwerken an die Systemkom-ponenten angeschlossen werden, ohne den Quelltext der Komponenten andern zu mussen.In der Simulation kann so zunachst untersucht werden, welches Bussystem oder Netzwerkfur ein System am Besten geeignet ist.

• Fur die Generierung von Hardware und Software aus einem TLM-Modell kann eine Midd-leware eingesetzt werden, die auf verschiedenen Hardware-Architekturen die gleichenstandardisierten Kommunikations-Schnittstellen zur Verfugung stellt. Lauffahige Syste-me konnen aus einem TLM-Modell auf diese Weise schneller erstellt werden, als wenn furjede Zielarchitektur eine individuelle Implementierung durchgefuhrt wird.

Das Transaction-Level-Modeling folgt allgemein dem Trend, Methoden aus der Softwaretech-nik (objektorientiertes Programmieren, standardisierte Schnittstellen, Plattformunabhangig-keit) auf das Hardware-Software-Codesign zu ubertragen. Zu seinem Namen ist es insbesonderedurch die Abstraktion von taktgenauen Kommunikationsprotokollen zu transaktionsbasierterKommunikation gekommen. Komplizierte Handshake-Mechanismen wie in Bild 8, die sich oft

36 4.1 TLM mit SystemC

Bild 8: Bus-Transaktion

uber mehrere hundert Takte erstrecken, werden dabei zu einer einzigen Transaktion zusam-mengefasst. Das Ergebnis ist ein Simulationsmodell, dass sich nach außen hin genau so verhaltwie sein taktzyklen-genaues Pendant. Die Simulationsdauer ist aber um das 100- bis 1000-facheverkurzt.

4.1 TLM mit SystemC

Wahrend Transaction-Level-Modeling mit Verilog oder VHDL nur durch umstandliche Kunst-griffe zu erreichen ist, liefert SystemC die dafur notwendigen Werkzeuge Ports, Interfaces undChannels bereits mit. In Verbindung mit der Fahigkeit, auch Software-Entwicklung und ver-schiedene Abstraktionsebenen zu unterstutzen, ist SystemC fur einen TLM-basierten Hardware-Software-Entwurfsprozess gut geeignet.

Der System-Entwurf beginnt dabei auf einer hohen Abstraktionsebene, in der die Modellierungder Funktionalitat des Systems im Vordergrund steht. Systemfunktionen werden in Modulengekapselt und als SC_THREAD- oder SC_METHOD-Prozesse implementiert. Die Kommunikation zwi-schen den einzelnen Prozessen wird mit abstrakten Channels modelliert, die nicht nur einzelneWerte, sondern komplette Datenobjekte transportieren.

Listing 15 zeigt so ein TLM-Modell fur den MP3-Player aus Bild 7. Das Modell befindet sichauf der hochsten denkbaren Abstraktionsebene, denn ein komplexer MP3-Dekoder wird hiermit gerade mal zwei Modulen modelliert. Im weiteren Entwurfsverlauf wird man diese Modulein weitere Submodule zerlegen.


2

3 #include "mp3decoder.h"

4 #include "mp3memory.h"

5

6 // Zugriff auf TLM -Bibliothek

7 #include "tlm.h"

8 using namespace tlm;

9



11 {

12 // Module instanzieren

13 MP3Decoder decoder("Decoder");

14 MP3Memory memory("Memory");

15

16 // TLM -Channel zum Transport von MP3Objects instanzieren

17 tlm_fifo <MP3Object > channel("Channel");

18

19 // TLM -Channel mit Modulen verbinden

20 memory.outPort(channel);

21 decoder.inPort(channel);

22

23 // Simulation starten

24 sc_start();

25 }

Listing 15: Einfaches TLM-Modell eines MP3-Players (mp3player.cpp)

MP3-komprimierte Musikstucke werden uber einen TLM-Channel aus dem Speicher angefordertund anschließend dekodiert. Dabei werden nicht einzelne Bits, sondern komplette Musikstuckeubertragen. Hierfur wird der abstrakte Datentyp MP3Object aus Listing 16 eingesetzt. Dies istein wesentlicher Unterschied vom Transaction-Level-Modeling zur RTL-Modellierung. Der ab-strakte Datentyp MP3Object ist, im Gegensatz zu RTL-Datentypen, nicht direkt in Hardwaresynthetisierbar. Das ist hier aber auch nicht das Ziel, stattdessen soll ein schnelles Simulations-modell des MP3-Players entwickelt werden.

Um das Beispiel einfach zu halten, enthalt das MP3Object lediglich Informationen uber Kunstler,Album und Titel des Musikstucks. In einer vollstandigen Implementierung mussten naturlichauch die MP3-Daten selbst enthalten sein, dies wurde aber dieses Skript nur unnotig aufblahen.Die Praprozessor-Anweisungen mit vorgestelltem # in Listing 16 sind notig, damit die Header-Datei vom Compiler nur einmal bearbeitet wird, obwohl sie im Projekt mehrmals inkludiert ist(#include "mp3object.h").

1 #ifndef _MP3OBJECT_H_

2 #define _MP3OBJECT_H_

3


5

6 using namespace std;

7

8 class MP3Object

9 {

10 public:

11 // Standard -Konstruktor

12 MP3Object() {};

13 // Konstruktor mit Initialisierungs-Parametern

14 MP3Object(string artist, string album , string title)

15 : artist(artist), album(album), title(title) {}

16

17 // Variablen

18 string artist;

19 string album;

20 string title;

38 4.1 TLM mit SystemC

21 };

22

23 #endif

Listing 16: Abstrakter Datentyp MP3Object (mp3object.h)

Listing 17 zeigt den Modulkopf des MP3Memory-Moduls. Dieses Modul modelliert einen Speicher,in dem MP3-Dateien abgelegt sind (z.B. CompactFlash). Es enthalt einen SC_THREAD, derkontinuierlich MP3-Musikstucke aus dem Speicher ausliest und uber einen sc_port vom Typtlm_blocking_put_if als MP3Object versendet. Dabei enthalt jedes gesendete Objekt einekomplette MP3-Datei (zumindest denken wir uns dies an dieser Stelle).


2 #include "mp3object.h"

3


5 #include "tlm.h"


7

8 SC_MODULE(MP3Memory)

9 {

10 // TLM Ausgabeport

11 sc_port<tlm_blocking_put_if <MP3Object > > outPort;

12

13 // Konstruktor

14 SC_CTOR(MP3Memory)

15 : song(0) // Songnummer auf 0 initialisieren

16 {

17 // SC_THREAD sendet MP3 -uStcke an MP3 -Dekoder

18 SC_THREAD(sendMP3s);

19 }

20

21 // Methodenrumpf ufr SC_THREAD

22 void sendMP3s();

23 // naechstes MP3 aus dem Speicher holen

24 MP3Object getNextMP3();

25 // aktuelle Songnummer

26 int song;

27 };

28

29

30 // MP3 -Speicher

31 static const MP3Object mp3List[] =

32 {

33 MP3Object("U Gee", "Eiscubes Vol. 1", "SystemC on the rocks"),

34 MP3Object("The Wolf Gang", "High -Level Hotel",

35 "Without channels I’m nothing"),

36 MP3Object("Roberto Gunzales", "Master of Desaster",

37 "I wear green socks")

38 };

39 // Anzahl MP3s im Speicher

40 #define MP3LIST_SIZE 3

Listing 17: Modulkopf des MP3-Speichers (mp3memory.h)


Die Implementierung des MP3Memory-Moduls zeigt Listing 18. Der SC_THREAD sendMP3s() be-steht aus einer Endlosschleife, die zunachst die nachste MP3-Datei aus dem Speicher anfordertund sie anschließend als MP3Object an den TLM-Ausgabeport sendet.

Hier zeigt sich ein wichtiger Unterschied zu den bisher in der RTL-Modellierung eingesetztensc_signal-Channels. Statt dem Ausgabeport direkt einen Wert zuzuweisen, wird jetzt dieFunktion put verwendet. Sie wird von dem verwendeten tlm_fifo-Channel (Listing 15, Zeile 17)zur Verfugung gestellt, um ein beliebiges Datenobjekt in den Channel hineinzuschieben.

1 #include "mp3memory.h"

2

3 // SC_THREAD sendet MP3s

4 void MP3Memory::sendMP3s()

5 {

6 while(true)

7 {

8 MP3Object mp3 = getNextMP3();

9 outPort->put(mp3);

10 }

11 }

12

13 // Naechstes MP3 aus dem Speicher holen

14 MP3Object MP3Memory::getNextMP3()

15 {

16 if (song == MP3LIST_SIZE)

17 song = 0;

18 return mp3List[song++];

19 }

Listing 18: Implementierung des MP3-Speichers (mp3memory.cpp)

Am anderen Ende des Channels, beim MP3-Dekoder, muss das MP3Object wieder aus demChannel herausgenommen werden. Dies geschieht mit Hilfe der Methode get.

Beide Module, MP3Memory und MP3Decoder, benutzen so genannte blockende TLM-Ports. Dieswird durch die Interfaces tlm_blocking_put_if und tlm_blocking_get_if bewirkt. Als Er-gebnis halt die put-Methode den SC_THREAD des MP3Memory-Moduls so lange an (blockieren),bis das MP3Object auf der anderen Seite des TLM-Channels vom MP3Decoder-Modul mit derget-Methode entgegen genommen wurde.

Blockende Kommunikation ist ein Grundkonzept von Transaction-Level-Modeling, denn sieerlaubt die Synchronisation von Prozessen auf Basis ihrer Kommunikation. Ein Taktsignalwird darum auf dieser hohen Abstraktionsebene nicht benotigt.

Um das TLM-Beispiel des MP3-Players zu vervollstandigen, fehlt noch der Quelltext fur dasMP3Decoder-Modul. Diesen zeigen die Listings 19 und 20.


2 #include "mp3object.h"

3


5 #include "tlm.h"


7

8

40 4.2 Ubung 5

9 SC_MODULE(MP3Decoder)

10 {

11 sc_port<tlm_blocking_get_if <MP3Object > > inPort;

12

13 // Konstruktor

14 SC_CTOR(MP3Decoder)

15 {

16 // Methode decode() als SC_THREAD deklarieren

17 SC_THREAD(decode);

18 }

19

20 // Methodenrumpf fuer SC_THREAD decode()

21 void decode();

22 // Methodenrumpf fuer Hilfsfunktion printInfo()

23 void printInfo(MP3Object mp3);

24 };

Listing 19: Modulkopf des MP3-Dekoders (mp3decoder.h)

1 #include "mp3decoder.h"

2

3 void MP3Decoder::decode()

4 {

5 MP3Object mp3; // ein leeres MP3Object

6

7 while (true)

8 {

9 // MP3Object aus TLM -Channel holen

10 inPort->get(mp3);

11 // Informationen ausgeben

12 printInfo(mp3);

13 // MP3 dekodieren

14 // playMP3(mp3); // leider noch nicht implementiert

15 }

16 }

17

18 void MP3Decoder::printInfo(MP3Object mp3)

19 {

20 cout << "Decoding MP3 " << endl;

21 cout << " Artist: " << mp3.artist << endl;

22 cout << " Album: " << mp3.album << endl;

23 cout << " Title: " << mp3.title << endl << endl;

24 }

Listing 20: Implementierung des MP3-Dekoders (mp3decoder.cpp)

4.2 Ubung 5

In dieser Ubung soll das Transaction-Level-Modeling mit SystemC praktisch ausprobiert wer-den.


4.2.1 Aufgabe 1

Erstellen Sie alle Dateien des MP3-Player-Beispiels aus dem vorigen Abschnitt am Rechnerund verwenden Sie das Makefile aus Listing 21, um das gesamte Modell zu kompilieren. StartenSie die Simulation und beobachten Sie die Ausgaben. Mit Strg-C kann die endlos laufendeSimulation abgebrochen werden.

1 OBJS = mp3memory.o mp3decoder.o mp3player.o

2 MODULES = mp3player


Listing 21: Makefile fur den MP3-Player

4.2.2 Aufgabe 2

Der MP3-Player soll um eine Funktion erweitert werden, den nachsten zu spielenden Titelauswahlen zu konnen. Dies soll an Hand der Titelnummer moglich sein. Erweitern Sie dasMP3Memory-Modul hierzu um einen zweiten TLM-Port

sc_port<tlm_blocking_get_if> titleSelectPort;

und schreiben Sie ein neues Modul MP3Selector, welches einen Ausgabeport

sc_port<tlm_blocking_put_if> titleSelectPort;

besitzt. Das MP3Selector-Modul soll uber einen SC_THREAD Titelnummern auf seinen TLM-Ausgabeport schreiben, die uber einen tlm_fifo-Channel an das MP3Memory-Modul ubertra-gen werden. Die Titelnummern sollen mit dem in Listing 22 gezeigten abstrakten DatentypMP3Title durch den TLM-Channel gesendet werden. Dieser enthalt zwar zunachst nur eineint-Variable, kann aber spater um weitere Variablen erweitert werden, um einen MP3-Songauch an Hand seines Namens oder Kunstlers auszuwahlen. Bild 9 zeigt ein Blockdiagramm deszu entwickelnden Systems.

Bild 9: MP3-Player mit Titelselektor

42 4.2 Ubung 5

1 #ifndef _MP3TITLE_H_

2 #define _MP3TITLE_H_

3


5

6 using namespace std;

7

8 class MP3Title

9 {

10 public:

11 // Standard -Konstruktor

12 MP3Title() {};

13 // Konstruktor mit Initialisierungs -Parametern

14 MP3Title(int number)

15 : songnumber(number) {}

16

17 // Variablen

18 int songnumber;

19 };

20

21 #endif

Listing 22: Abstrakter Datentyp MP3Title (mp3title.h)

Implementieren Sie selbstandig ein geeignetes MP3Selector-Modul, das eine Liste von Titel-nummern enthalt und an das MP3Memory-Modul sendet. Erweitern Sie das MP3Memory-Modul so,dass es MP3-Musikstucke nur dann an das MP3Decoder-Modul verschickt, wenn vorher ein Titelausgewahlt wurde. Dabei soll naturlich der ausgewahlte MP3-Titel versendet werden. Falls eineTitelnummer eingegeben wird, die nicht im Speicher verfugbar ist, soll eine Warnmeldung mitder falschen Titelnummer ausgegeben werden.

Verbinden Sie Ihr neues MP3Selector-Modul uber einen TLM-Channel mit dem restlichenSystem und testen Sie Ihre Implementierung.

Hardware/Software-Codesign mit SystemC · SystemCunterstutzt dieKapselungvonFunktionalit at...

Documents

Transcript of Hardware/Software-Codesign mit SystemC · SystemCunterstutzt dieKapselungvonFunktionalit at...