SystemC ist eineModellierungs- undSimulationssprache insbesondere für die Entwicklung von komplexen elektronischen Systemen, die sowohl Hardware- als auch Softwarekomponenten umfassen.
Im Gegensatz zu reinenHardwarebeschreibungssprachen, wieVHDL undVerilog-HDL, handelt es sich bei SystemC um keine eigene Programmiersprache, sondern um eineC++-Klassenbibliothek. Sie ist in dem aktuellenIEEE-Standard 1666-2011 definiert. Außerdem steht einequelloffene Implementierung des Standards, unter derApache 2.0 Lizenz zur Verfügung[1]. Als Klassenbibliothek erweitert SystemC C++ um Sprachelemente, die der Hardware-Modellierung dienen. Gleichzeitig verfügt die Bibliothek über einen Simulatorkern, sodass sich mit SystemC beschriebene Modelle ausführen und testen lassen[2].
SystemC wird vorrangig zur Modellierung auf höheren Abstraktionsebenen, z. B. fürTransaction Level Modeling (TLM) eingesetzt. Damit eignet sich SystemC insbesondere fürElectronic System Level Designs, wo die frühzeitige Bereitstellung eines Virtuellen Prototypen zur Evaluation von Entwurfsalternativen von hoher Bedeutung ist. KlassischeRTL-Entwürfe wären hier zu komplex und unflexibel.
Ein weiterer Vorteil von SystemC ist nicht nur die schnelle Entwicklung von Prototypen, sondern auch die auf höheren Abstraktionsebenen deutlich verbesserte Simulationsleistung. In SystemC entworfene Modelle auf Transanktionsebene, können eine um ein rund tausendfaches schnellere Simulationsleistung aufweisen alsRTL-Modelle[3]. Somit können auch komplexere Programme mitsimuliert werden und Entwurfsalternativen bezüglich der Partitionierung von Hard- und Software-Komponenten abgewägt werden. Aber auch die Modellierung von synthetisierbaren Schaltungen aufRegistertransferebene sind mit SystemC als Substitut für VHDL oder Verilog möglich.
Da es sich bei SystemC um keine eigenständige Sprache, sondern eine reine (Klassen-)Bibliothek für C++ handelt, müssen alle typischen Sprachelemente herkömmlicher Hardwarebeschreibungssprachen auf einfache C++-Sprachkonstrukte abgebildet werden. Dies bringt SystemC den Nachteil eines syntaktischen Overheads ein, den herkömmliche Hardwarebeschreibungssprachen nicht haben. Die Bereitstellung einer Vielzahl vonPräprozessor-Makros hilft dabei, diesen Effekt etwas einzudämmen. Dafür ist der Entwickler deutlich freier im Ausdruck, was jedoch in der Regel mit derSynthetisierbarkeit des Hardware-Modells im Konflikt steht.
SystemC eignet sich, wie z. B. auch die ModellierungsspracheE, für die Modellierung von Protokollen und Peripherie, um anhand dieser dieFehlerfreiheit einer digitalen Schaltung zu überprüfen. SystemC ist jedoch nicht nur eine Modellierungssprache, sondern gleichzeitig ihr eigener Simulationskern. Dieser ist in der SystemC-Bibliothek enthalten (Bsp.: in jeder Referenzimplementierung der OSCI), sodass durch Kompilieren eines System-Quellcodes ein ausführbarer Simulator mit dem Verhalten des Quellcodes entsteht. Jedoch wird SystemC auch von kommerziellen Simulationstools wieModelsim unterstützt.
Viele Universitäten arbeiten an effizienten Programmen zurSchaltungssynthese aus SystemC-Modellen heraus. Einige Unternehmen bieten Lösungen an, die aus bestimmten SystemC-CodesNetzlisten fürASICs oderFPGAs generieren können. Im Jahr 2005 wurde die Version 2.1 der SystemC-Referenzbeschreibung von der internationalen IngenieursvereinigungIEEE als Standard IEEE 1666-2005 ratifiziert, welcher 2012 durch 1666-2011 abgelöst wurde. Dieser Standard stellt das aktuelle LRM (Language Reference Manual) dar und ist bei der IEEE kostenlos als Download verfügbar (siehe Weblinks).Im Jahr 2007 wurde die Open-Source-Referenzimplentierung der OSCI (Open SystemC Initiative) auf Version 2.2 aktualisiert um vollständig mit dem IEEE 1666 LRM konform zu sein.
Im Jahr 2016 wurde die Analog Mixed-Signal Erweiterung SystemC AMS als Standard ratifiziert (IEEE 1666.1-2016). Eine Open-Source-Referenzimplentierung ist kostenlos als Download verfügbar (siehe Weblinks).
Da SystemC eine Klassenbibliothek für C++ ist, werden hier nur die für SystemC typischen Konstrukte angegeben.
Module dienen dazu, um komplexere Systeme in überschaubare Teile zu gliedern. Sie bilden Bausteine, sind nach außen über Ports zugänglich und können wiederum Module enthalten.Die Syntax lautet
SC_MODULE (Modulname) {// Modulinhalt};Eine Instanz des Moduls wird durch den Konstruktor
SC_CTOR (Modulname) {. . . }realisiert.
Ports bilden die Schnittstelle des Moduls nach außen. Es gibt drei Arten von Ports und als vierten Typ Signale:
sc_in<Porttyp> PortInName; // Eingangsc_out<Porttyp> PortOutName; // Ausgangsc_inout<Porttyp> PortInOutName; // Bidirektionalsc_signal<Signaltyp> SigName; // Signal
Die Funktionalität der Module wird durch Prozesse gebildet.Es gibt drei Arten von Prozessen.
Methoden-Prozesse werden aufgerufen, wenn sich ein Signal aus derSensitivitätsliste ändert und übergeben nach ihrer Ausführung die Kontrolle wieder an den Simulator zurück. Durch
SC_METHOD (Funktionsname);
wird eine bestimmte Funktion installiert, die zuvor im Modul deklariert werden muss.Die Sensitivitätsliste wird durch
sensitive << Signal1 << Signal2 . . .
erzeugt.
Im Gegensatz zu Methoden-Prozessen werdenThread-Prozesse nur einmal gestartet unddurchlaufen immer wieder die gleiche Schleife, in der wait()-Kommandos zur vorübergehendenUnterbrechung dienen.
SC_THREAD (Funktionsname);
Clocked-Thread-Prozesse sind synchrone Thread-Prozesse, deren Aktionen erst zur nächstenTaktflanke sichtbar werden. Im Unterschied zu den Thread-Prozessen erfolgt keine Angabe der Sensitivitätsliste, sondern das zweite Argument im Aufruf
SC_CTHREAD (Funktionsname, Taktflanke);
spezifiziert, welche Flanke des Taktsignals den Prozess triggert.
EinAddierer in SystemC:
#include "systemc.h"SC_MODULE(adder) { // Moduldeklaration (eine Art Klasse) sc_in<int> a, b; // Zwei Eingangs-Ports (a und b) sc_out<int> sum; // Ein Ausgangs-Port SC_CTOR(adder) { SC_THREAD(doit); sensitive <<a <<b; } void doit() { while(true) { sum.write(a.read() + b.read()); wait(); } }};