Entwicklung eines Single Instruction Computers (SIC) mit SystemC für ein Spartan3 Board

Transkript

1 Entwicklung eines Single Instruction Computers (SIC) mit SystemC Hochschule Bremen Technische Informatik Labor für Computertechnik Prof. Dr. Thomas Risse Wintersemester 2004/2005 Arbeiter, Ansgar (M.Nr.: 72682) Schröder, Stefani (M.Nr.: 84054) Kruse, Mirko (M.Nr.: 72694) Timmermann, Daniel (M.Nr.: 73090)

2 Inhaltsverzeichnis 1 Einleitung 2 2 Grundlagen SIC - Single Instruction Computer Digilent Spartan3 Board Projektziel Bestehende Projekte Ziel des vorliegenden Projektes Eigene Randbedingungen Realisierung Spezifikation und Alternativen System-Architektur Prozessor-Architektur Implementierung in SystemC Modulstruktur Anpassung der bestehenden Software Simulation eines Befehlszyklus Vom SystemC Entwurf zum FPGA-Board Synopsys Suite Kompilierung der Quelldateien auf dem ISMS Server Synthese und Programmierung des FPGA Entwicklung eines Compilers Mehrstufiger Compiler SIC-Simulator Demo-Programm Grenzen und Probleme Architektur SystemC Tools Compiler und Simulator Fazit 36 Literaturverzeichnis 37 A Tutorial 38 Seite 1

3 Kapitel 1 Einleitung Dieses Projekt versteht sich als Erweiterung schon existierender Projekte aus früheren Semestern, in denen bereits ein Single Instruction Computer (SIC) realisiert wurde. Im ersten Projekt [Oldenb2001] geht es um die Grundlagen eines SICs und die Umsetzung mittels der Hardware-Programmiersprache VHDL. Im zweiten Projekt [BurdRothPoot2003] geht es im Wesentlichen um eine Portierung in die an C angelehnte neuere Programmiersprache SystemC. Ziel unseres Projektes war es, den in SystemC geschriebenen SIC zu erweitern und auf einem Spartan3-Entwicklungs-Board der Firma Digilent zu implementieren. Nach genauer Analyse der bestehenden Projekte und Einbeziehung von möglichen zukünftigen Erweiterungen wurden die Architekturen des Systems und des Prozessors neu festgelegt. Insbesondere sollten I/O-Module Anwendung finden, sodaß die Ergebnisse eines Programms ausgegeben werden können. Außerdem sollte das auszuführende Programm über die serielle Schnittstelle ladbar sein, ohne den Festspeicher (Flash) neu beschreiben zu müssen. Das dynamische Laden wurde in den bestehenden Projekten zwar angedacht, aber letztlich nicht umgesetzt. Um für zukünftige Erweiterungen gewappnet zu sein, wurde ein Bus-System eingeführt, an das beliebige Module angeschlossen werden können. Dies gilt für Software- und für Hardware-Module. Da es nicht bei der theoretischen Umsetzung des SIC bleiben sollte, mußten die Entwicklungswerkzeuge für die existierende Hardware erkundet und in Einklang mit SystemC gebracht werden. Aufgrund keinerlei Vorkenntnisse von SystemC, war eine entsprechende Einarbeitung erforderlich und könnte als eigenes Projekt betrachtet werden, weil es sich um eine recht junge Sprache handelt, die bei der Synthese, also der Erstellung der Binärdateien für die Ziel-Hardware, erhebliche Schwierigkeiten verursachen kann. Weil der SIC per Definition nur einen Befehl beherrscht, sind die Programme hierfür sehr unleserlich. Es ist wünschenswert, einen Compiler zu haben, um verständliche Programme (ggf. in einer Hochsprache) formulieren zu können. Dies ist ein weiterer Schwerpunkt des Projektes. Da ein Testzyklus (Software ändern, compilieren, synthetisieren, laden) recht zeitaufwendig ist, wurde zusätzlich ein Simulator umgesetzt, mit dem das Kompilat sofort getestet werden kann. Die erzeugte Binär-Datei führt auf dem Simulator und dem Test-Board zum gleichen Ergebnis. Seite 2

4 Kapitel 2 Grundlagen 2.1 SIC - Single Instruction Computer Ein Single Instruction Computer (SIC) enthält einen Prozessor mit nur einem Befehl in seinem Befehlssatz. Beherrschen andere Prozessoren (z.b. ein Pentium) bis zu mehrere hundert Befehle, so kennt ein SIC-Prozessor nur einen einzigen Befehl. Damit kann er als Extrem-RISC-Prozessor bezeichnet werden (RISC = Reduced Instruction Set Computing; Gegensatz zu CISC = Complex Instruction Set Computing). Was auf den ersten Blick unsinnig bis unrealistisch erscheint, entpuppt sich auf den zweiten Blick als durchaus machbar und bietet sogar einige Vorteile. Da der Prozessor bei jedem Befehl das gleiche macht, ist keine Befehlsdekodierung erforderlich. Weil es eben nur einen Befehl gibt, ist nicht einmal ein Opcode nötig, der bei anderen Prozessoren angibt, um welchen Befehl es sich handelt. Es werden nur die Parameter eines Befehls im Programmspeicher abgelegt. Wenn Programm- und Datenspeicher getrennte Bussysteme verwenden, dann kann der Programmspeicher zur Befehlswortbreite ausgerichtet werden, d.h. eine an den Programmspeicher angelegte Adresse liefert genau einen Befehl (oder genauer: die Parameter eines Befehls). Ein Versatz bei der Parameterzuordnung ist damit ebenfalls ausgeschlossen. Zusätzlich kann der Programmspeicher direkt als Parameter-Register im Prozessorkern angesehen werden und es sind nur wenige zusätzliche Register erforderlich (eins für den Programmzähler IP und eins für die Operanden-Zwischenpufferung). Wird ein spezieller Datenspeicher verwendet, der gleichzeitiges Lesen und Schreiben erlaubt, so kann der Operanten- Zwischenpuffer auch noch eingespart werden. Auf diese Variante haben wir jedoch verzichtet, um gewöhnliche Hardware (RAM-Baustein) am Datenbus betreiben zu können. Der Prozessorkern benötigt insgesamt nur sehr wenige Elemente. Nun zu dem interessantesten Punkt: Welchen Befehl beherrscht der SIC-Prozessor? Ähnlich der Turing-Maschine, bei der mit einem endlosen Band und wenigen Operationen (Lesen, Schreiben, bedingt Richtung ändern) alle intuitiv lösbaren Probleme gelöst werden können (Church-Turing-These), benötigt auch ein SIC-Prozessor nur elementare Funktionen. Zwei Bedingungen muß der Befehl erfüllen, um ein entscheidungsfähiges Programm ausführen zu können: Es muß eine bedingte Verzweigung geben und um Daten manipulieren zu können, muß eine Berechnung möglich sein. Der verwendete Befehl lautet in unserem Fall sbn (Subtract and Branch if result is Negative) und hat drei Parameter: Aˆ, Bˆ, und Delta-C (kurz a,b und c). A und B sind Zeiger auf Variablen im Datenspeicher, Delta-C gibt die Schrittweite an, die gesprungen wird, wenn das Subtraktionsergebnis negativ ist. Seite 3

5 Formalisiert entspricht der Befehl sbn a,b,c folgenden Anweisungen: [a] = [a] - [b] if [a] < 0 then CP = CP + c else CP = CP + 1 (CP = Code Pointer) Um zu demonstrieren, das dieser Befehl geeignet ist, viele anderen Befehle nachzubilden (theoretisch alle), hier einige Beispiele: komplexer Befehl SIC-Befehlsfolge Erklärungen sub x,y sbn x,y,1 x = x - y clr x sbn x,x,1 x = x - x = 0 add x,y #var tmp Zwischen-Variable clr tmp tmp = 0 sub tmp,y tmp = tmp - y = -y sub x,tmp x = x - tmp = x - (-y) = x + y jmp z #var tmp Zwischen-Variable #const c 1 1 c 1 = -1 (Wert -1 wird als vorhanden angenommen) clr tmp tmp = 0 sbn tmp,c 1,z tmp - c 1 = -1 = negativ mov x,y #var tmp Zwischen-Variable #var tmp2 Zwischen-Variable clr tmp tmp = 0 clr tmp2 tmp2 = 0 sub tmp,x tmp = -x sub tmp2,tmp tmp2 = x sub tmp2,y tmp2 = x - y sub x,tmp2 x = x - (x - y) = x -x +y = y Wie zu erkennen ist, können komplexere Befehle durch geschickte Verkettung von sbn-folgen realisiert werden. Es wurde hier davon ausgegangen, daß einmal definierte Befehle in anderen selbstdefinierten Befehlen verwendet werden können. Andere denkbare Elementar-SIC-Befehle wären z.b. djnz (Decrement and Jump if result is Zero) rlcb (Rotate Left with carry and Branch if Carry is 1) Variationen in der Art der Parameter sind auch denkbar. In unserem Fall gibt es zwei Daten-Zeiger und einen Differenz-Schritt. Der letzte Parameter könnte auch eine absolute Adresse angeben, dies würde jedoch erfordern, daß die gleiche Wort-Breite wie der Programm-Adress-Bus nötig wäre, während eine relative Schrittweite mit weniger Bits auskommt. Weitere Sprünge sind ggf. durch Mehrfach-Sprünge realisierbar. Im Gegensatz zum SIMD-Prozessor (SIMD = Single Instruction Multiple Data), der in Großrechnern eingesetzt wird und einen Datenstrom durch eine immer gleiche Operation modifizieren soll, ist der SIC aus Sicht der Anwendung nicht dafür bestimmt, immer die gleiche Operation auszuführen. Vielmehr ist ein RISC-Prozessor auch für komplexe Aufgaben geeignet, nur ist dann die Komplexität mehr auf die Software verlagert, während die Prozessorbefehle relativ schlicht gehalten sind. Bei einem RISC-Prozessor steht eine möglichst kurze und gleichmäßige Seite 4

6 Abarbeitungszeit (Anzahl der Takt-Zyklen) pro Befehl im Vordergrund. Mit einem SIC wird dem Rechnung getragen. Da es nur einen Befehl gibt, ist die nötige Abarbeitungszeit immer gleich. Obwohl der SIC mit relativ geringem Aufwand zu realisieren ist und ein Musterbeispiel eines RISC-Prozessors darstellt, bleibt dennoch festzustellen, daß er in der Praxis kaum Relevanz haben dürfte. Der geringe Hardware-Aufwand geht zu Lasten einem zuweilen unverhältnismäßig großen Software-Aufwand, um ein Problem zu lösen. Logische Operationen (and, or, xor, inv usw.), die in der hardwarenahen Umgebung sehr häufig gebraucht werden, können beim SIC nur über umständliche Wege erzielt werden (siehe Kapitel 4.4). Mit einem geringfügig erweiterten Befehlssatz könnte eine deutlich effizientere Abarbeitung stattfinden. Dies wurde bei der Festlegung der Prozessorarchitektur zunächst auch in Erwägung gezogen, dann aber wieder verworfen, weil es in diesem Projekt nicht darum geht, einen möglichst effizienten Prozessor zu entwerfen, sondern zu demonstrieren, daß es möglich ist, den in seinem Funktionsumfang minimalsten Prozessor (eben einen SIC-Prozessor) auch konkret umzusetzen und darüber hinaus seine praktische Anwendbarkeit zu zeigen. Der reale SIC ist damit die Schnittstelle zwischen Theorie und Praxis. Seite 5

7 2.2 Digilent Spartan3 Board Das Testsboard von Digilent [XilBoard] bietet dem Entwickler zahlreiche Features für die Umsetzung komplexer Aufgaben. Mit dem Xilinx Spartan-3 XC3S200 [XilSpartan3] steht ein leistungsstarker FPGA (Field-Programmable Gate Array) mit Gates zur Verfügung, der über das beiliegende Parallel -> JTAG Kabel mittels der freien Software ISE WebPack von Xilinx programmiert werden kann, ebenso wie das PROM. Die nötigen Spannungsversorgungen und ein 50MHz Takt werden auf dem Board bereitgestellt. Diverse Ein- und Ausgabekomponenten sind implementiert, so daß relativ schnell einfache Anwendungen mit eben solchen Ein-/Ausgaben umgesetzt werden können. Im Folgenden werden anhand von Grafiken die wichtigsten Komponenten auf dem Board erwähnt. Ein FPGA ist allgemein ein programmierbarer Chip ähnlich eines PLDs (Programmable Logic Device), jedoch für wesentlich umfangreichere Aufgaben geeignet. Eine große Anzahl an logischen Einheiten, die als kombinatorische und/oder sequentielle Schaltungen genutzt werden können, werden über ein internes Netzwerk miteinander verbunden und ergeben so eine Gesamtschaltung für eine spezifische Anwendung. Der FPGA ist nach dem Reset nicht konfiguriert, d.h. er verliert seine Schaltung. Daher muß diese jedesmal neu oder wahlweise über einen ROM-Speicher automatisch nach dem Reset geladen werden. Der Aufbau eines FPGAs wird an dieser Stelle nicht weiter vertieft, ein kurzer Einblick in den prinzipiellen Aufbau und die Funktionsweise soll genügen. Abbildung 2.1: Digilent Spartan3 Board - Vorderseite [XilBoard] 1 : Xilinx Spartan-3 XC3S200 2 : 2Mbit ISP (In-System-Programmable) Flash PROM 4 : 1MByte Fast Asnchronous SRAM 5 : VGA-Port, 3 bit, 8 Farben 6 : RS232 Port, 9 Pins 7 : RS232 Treiberbaustein 9 : PS/2 Port für Tastatur/Maus 10 : 4x 7-Segmentanzeigen 11 : 8x Schalter Seite 6

8 12 : 8x LEDs 13 : 8x Taster, hier falsch eingezeichnet 19 : ( ) 3x Erweiterungsports 22 : JTAG Port Abbildung 2.2: Digilent Spartan3 Board - Rückseite [XilBoard] Seite 7

9 Kapitel 3 Projektziel Bereits in vorhergehenden Semestern wurde die Implementierung eines SIC auf ein FPGA von zwei verschiedenen Gruppen bearbeitet. Dieses Projekt verwendet die Ergebnisse der beiden Gruppen als Grundlage auf dessen Basis Erweiterungen an dem SIC vorgenommen werden sollen. Im Folgenden werden die bestehenden Projekte kurz vorgestellt, um anschließend die Ziele des vorliegenden Projektes mit dessen Randbedingungen zu definieren. 3.1 Bestehende Projekte WS 2001/02: Roul Oldenburger Implementierung eines Single Instruction Computers in VHDL [Oldenb2001] In diesem Projekt wurde der Single Instruction Computer (SIC) näher betrachtet. Dieser wurde in VHDL realisiert. Desweiteren sollte eine Entwicklungsumgebung für den SIC entstehen, welche zur Programmierung in Assembler und Hochsprache eingesetzt werden soll. Der verwendete Chip ist ein Spartan2. WS 2003/04: Nils Burdin, Christian Rother, Wilhelm Poot Implementierung eines SIC in SystemC [BurdRothPoot2003] Das Ziel dieses Projektes war es, einen SIC in SystemC zu entwickeln. Dieser SIC sollte eine Multiplikation ausführen können. Er wurde auf einem XILINX FPGA implementiert. 3.2 Ziel des vorliegenden Projektes Im Projekt Implementierung eines SIC in SystemC [BurdRothPoot2003] wurde SystemC als Sprache für die Beschreibung der SIC-Hardware angewendet. Der in diesem Projekt entwickelte SIC kann Programme ausführen, dessen Instruktionen fest in einem Registerspeicher abgelegt sind. Der Registerspeicher wurde als Array mit vorgegebenen Instruktionen in jedem Element fest in der Hardware verankert. Soll der SIC ein anderes Programm ausführen, so muß jeder Arbeitsschritt von der Änderung im Quellcode bis zur Programmierung des FPGA erneut ausgeführt werden. Ferner besteht keinerlei Möglichkeit, eine Ein- oder Ausgabe zum/vom SIC durchzuführen. Die Ergebnisse einer Berechnung konnten beispielsweise nur mit Hilfe eines extern angeschlossenen Logik-Analysators sichtbar gemacht werden. Diese Tatsachen machen einen Umgang mit dem entwickelten SIC zu umständlich, als das er sich dafür eignet, im Labor für Versuche Anwendung zu finden. Seite 8

10 Ziel dieses Projektes war, die o.g. Grenzen durch eine Erweiterung des bereits in SystemC realisierten SIC aufzuheben. Der erweiterte SIC soll über die serielle Schnittstelle mit variablen Programmen geladen werden können, welche er anschließend abarbeitet. Eine solche Möglichkeit hat zur Folge, daß die Programme komplexer und damit auch größer im Speicherbedarf werden können. Daher wurde eine höhere Kapazität für den Instruktions- und den Datenspeicher als Erweiterung definiert. Zusätzlich soll der erweiterte SIC eine Ein-/Ausgabe ermöglichen. Das Entwicklungsboard ist mit Schaltern, LED s und einer 4-Ziffern 7-Segment Anzeige ausgestattet, so daß diese Bausteine für die Realisierung von Ein-/Ausgabe genutzt werden können. Es werden I/O-Module gebildet mit denen der Benutzer Eingaben vornehmen kann (Schalter-Modul) und die Ergebnisse einer Berechnung angezeigt bekommt (LED und Siebensegment). Um sowohl den Speicher als auch die I/O-Module über eine gemeinsame Schnittstelle ansprechen zu können und gleichzeitig offen für die Einbettung weiterer Module zu sein, soll ein Bussystem eingeführt werden. Seitens der Software, sprich der Programme, welche auf der SIC Hardware ablaufen sollen, besteht das Problem, daß diese in rein binärer Form nur sehr umständlich zu schreiben sind. Auch besteht eine erhöhte Gefahr zu syntaktischen und logischen Fehlern, wenn der Entwickler seine Programme binär codieren muss. Wirklich sinnvolle, komplexere Programme für den SIC zu entwickeln wäre nur schlecht denkbar. Als ein weiteres Ziel dieses Projektes sollte daher ein Compiler entwickelt werden, mit dessen Hilfe Programme in einer Assemblersprache (und ggf. sogar in einer Hochsprache) formuliert werden können. Die Entwicklungsumgebung, in die der Compiler integriert wird, soll die Möglichkeit bieten ein Programm vorab zu simulieren. Durch diese Maßnahme verringert sich der Aufwand eines Testzyklus. Simulator und SIC-Hardware auf dem Entwicklungsboard verwenden beide die selbe Binärdatei, welche vom Compiler erstellt wird (das Kompilat). Kann die Funktionsfähigkeit eines Programmes im Simulator festgestellt werden, so sollte sich dessen Ausführung auf der SIC-Hardware gleich verhalten. Neben den soeben beschriebenen Zielen sollte das Projekt als Leitfaden gesehen werden, sich am Beispiel einer praktischen Aufgabe in den Umgang mit SystemC einzuarbeiten. In den Lehrveranstaltungen zum Thema Digitaltechnik wurde VHDL als Hardwarebeschreibungssprache eingeführt. Es lag in unserem Interesse die neuen Möglichkeiten von SystemC zu nutzen und dabei zu lernen, in wieweit sich mit Hilfe von SystemC die Hardwareentwicklung vereinfachen läßt. 3.3 Eigene Randbedingungen Für die Bearbeitung der in diesem Projekt angefallenen Aufgaben zum Erreichen der Projektziele wurden von unserer Seite verschiedene Randbedingungen gesetzt. Bei der Durchsicht der Dokumentation des Projektes Implementierung eines SIC in SystemC ist uns aufgefallen, daß die Projektgruppe eine Unzahl von Schritten unternehmen mußte, um von dem SystemC Entwurf zu einer programmierfähigen Datei zu gelangen. Nicht nur, daß verschiedene Software-Tools zu Einsatz kommen mußten, sondern diese zusätzlich auf unterschiedlichen Betriebssystemen (Windows/Linux/Solaris) residierten. Damit der Entwicklungszyklus vom Entwurf bis zur Programmierung des FPGA unkompliziert und schnell verlaufen kann, sollte unsererseits ein Weg gefunden werden, in dem die nötigen Schritte minimiert sind. Das bedeutete wiederum, daß möglichst wenige Software-Tools zur Erreichung des Ziels eingesetzt werden sollen. Grundsätzlich wurde zu Beginn des Projektes festgelegt, daß die erweiterte Version des SIC auf dem Entwicklungsboard der Firma DIGILENT mit XILINX Spartan3 FPGA lauffähig sein soll (siehe Kapitel 2.2). Das von der Firma XILINX kostenlos zur Verfügung gestellte Software-Tool ISE WebPack 6.3i war in der vorliegenden Version nur für Windows verfügbar. Mit ISE WebPack können die Arbeitsschritte von der Synthese von HDL Quellcode, über das Place-and-Route für den FPGA bis zur Erzeugung der binären FPGA-Programmierdatei (.bit Datei) durchgeführt werden. Seite 9

11 Da ISE WebPack auf jeden Fall für die Belegung der Pins am FPGA und für die Generierung der Programmierdatei herangezogen werden mußte, würde mindestens eine Software unter Windows installiert sein. Damit kein Wechsel der Betriebssystem - Plattform notwendig sein muß, entschieden wir uns die komplette Entwicklung des erweiterten SIC auf der Microsoft Windows Plattform vorzunehmen. Die SystemC Bibliotheken in der Version wurden mit einer Unterstützung für Microsoft Visual C++ 6 ausgeliefert. Obwohl die Projektgruppe des Vorgängerprojektes negative Erfahrungen im Umgang mit Visual C++ gemacht hatte, entschieden wir uns trotzdem die ersten Versuche mit dieser Entwicklungs- umgebung zu unternehmen. Was uns zu dem Zeitpunkt der Erstellung der Randbedingungen noch nicht bewußt war, war die Frage auf welche Weise überhaupt der SystemC Quellcode für den FPGA synthetisiert wird. Die ersten Recherchen im Internet zeigten schnell, dass zwar Produkte mit integrierten SystemC Compilern auf dem Markt verfügbar waren, diese jedoch immer Lizenzbestimmungen unterlagen und im Preis unsere finanziellen Möglichkeiten weit überschritten. In der Dokumentation des Vorgängerprojektes wurde beschrieben, daß die Synthese mit einer Suite der Firma Synopsys vorgenommen wurde, die auf einem Server der Hochschule installiert war. Wir entschieden uns einen Weg zu finden mit dem die Software-Tools der Synopsys-Suite auch von zu Hause unter Windows benutzt werden konnte. Seite 10

12 Kapitel 4 Realisierung 4.1 Spezifikation und Alternativen System-Architektur Vergleich der Von-Neumann-Architektur mit der Harvard-Architektur: Die Von-Neumann-Architektur zeichnet sich dadurch aus, daß Programm und Daten über den gleichen Bus übertragen werden. Somit ist es möglich, Daten und Befehle in einem Speicher zu halten. Es ist nur eine Bus-Schnittstelle vorhanden, was einen geringen Hardwareaufwand darstellt, aber Befehle und Daten müssen nacheinander übertragen werden. Außerdem kann das Program versehentlich von Daten überschrieben werden, oder es können durch einen falsch gesetzten Befehlszeiger Daten als Befehle interpretiert werden, was in beiden Fällen zu fatalen Fehlern führen kann. Bei der Harvard-Architektur sind Programm- und Datenspeicher voneinander getrennt und mit unabhängigen Bussystemen verbunden. Dies ermöglicht einen gleichzeitigen Zugriff auf beide Speicher und schützt vor versehentlichem Ausführen von Daten, weil die Befehle ausschließlich aus dem Programmspeicher kommen. Dieser kann zudem schreibgeschützt werden und so vor versehentlichem Überschreiben geschützt werden. Es müssen allerdings zwei Bus-Schnittstellen vorhanden sein. Diese können jedoch unterschiedlicher Wort-Breite sein, was den Vorteil bietet, den Programmspeicher exakt auf die Befehlsbreite zu dimensionieren, wenn die Befehlsbreite konstant ist. Der Adressbereich kann komplett für das Programm ausgenutzt werden. Ein Nachteil ist, dass beim Laden aus Programm- und Datenspeicher unterschieden werden muss. Bei einem SIC kann das bedeuten, daß vom Programm aus gar nicht auf den Programmspeicher zugegriffen werden kann (weil es nur einen Befehl gibt, der auf den Datenspeicher zugreift), und somit keine Konstanten benutzt werden können. Nach dem Abwägen der Vor- und Nachteile wurde die Architektur folgendermaßen festgelegt (siehe Abbildung 4.1). Seite 11

13 Abbildung 4.1: System-Architektur Seite 12

14 Die einzelnen Komponenten werden durch einen Daten- bzw. einen Instruktionsbus miteinander verbunden (im folgenden auch D-Bus und I-Bus genannt). Beide Busse arbeiten mit getrennten Read- und Write-Leitungen, die vom Bus-Master, der CPU gesteuert werden. Der Datenbus hat eine 8-Bit Adresse und 8-Bit Daten. Der Instruktionsbus arbeitet mit 16-Bit Adressen und 24-Bit Daten. Mit Hilfe des Reset-Signals (das vom Loader gesteuert wird) ist es möglich, die CPU anzuhalten. Durch das Betätigen der Load-Taste wird der Loader aktiviert und der Instruktionsspeicher kann über die serielle Schnittstelle neu beschrieben werden (Programm laden). Dabei gelangen Daten von der seriellen Schnittstelle über den D-Bus zum Loader und werden dort in 3-Byte-Paketen (24 Bit) über den I-Bus zum I-RAM (Instruktionsspeicher) übertragen. Nachdem die Daten vollständig übertragen wurden, muß die Reset-Taste betätigt werden, um die CPU wieder zu starten (Ausführung beginnt ab Adresse 0000h). Die I/O-Module werden durch ihre Adressen über den D-Bus angesprochen. Das DRAM sowie die I/O-Module werden über den Datenbus angesprochen. Dabei ist das DRAM genauso groß dimensioniert wie die I/O-Module, jeweils 128 Adressen. Bei der Festlegung der Größe wurde ein Kompromiß eingegangen. Auf der einen Seite soll das RAM möglichst groß sein, die Befehlsgröße allerdings soll möglichst klein sein. Die Datengröße wurde auf 8 Bit festgelegt. Dies ist eine übliche Größe und in unserem Fall sinnvoll, da auf dem Digilent Board 8 Schalter, 8 LEDs und 8 Bit für die 7-Segment-Anzeige angelegt sind. Pro Adresse wird eine Instruktion angesprochen, diese besteht aus a, b und c mit jeweils 8 Bit (24 Bit). Dabei sind a und b Zeiger auf das jeweilige Datum. c gibt die Sprungweite an, sie kann zwischen -128 und 127 variieren. Somit kann sowohl vorwärts als auch zurück gesprungen werden. Der Instruktionsspeicher hat 1024 Adressen (0000h - 03FFh). Der Adressbereich des I-Bus ist 16 Bit breit. Seite 13

15 4.1.2 Prozessor-Architektur Der Prozessor hat folgende Architektur: Abbildung 4.2: Prozessor-Architektur Der Prozessorkern benötigt nur zwei Register IP (Instruction Pointer) und A (A-Ergebnis) und wenige weitere Komponenten. Diese werden von einer Zustandsmaschine (State Machine) gesteuert (siehe Kap ). Die Zeiger A und B werden durch einen Multiplexer gesteuert. Liegt an DA sel eine 1 an, so wird der Zeiger A und bei 0 der Zeiger B weitergeleitet. Zunächst muss der Inhalt von A geholt werden, dazu wird DWrite auf 1 und DRead auf 0 gesetzt. ST A wird 1, so dass A in das Register geschrieben werden kann. Im nächsten Schritt wird ST A auf 0 gesetzt, B wird in den Subtrahierer geholt. Dort wird dann A - B gerechnet und das Ergebnis in das Register geschrieben. Ist das Ergebnis der Subtraktion negativ, so ist das MSB = 1 und IP sel wird gesetzt. Durch das Setzen von DRead (DRead = 1) und DWrite = 0 wird das Ergbenis auf den D-Bus gelegt. Das Signal IP sel steuert einen weiteren Multiplexer und entscheidet somit, ob die Sprungweite = 1 ist oder dip als Sprungweite verwendet wird. Mit Hilfe des Signals IP set wird das Setzen der neuen Adresse bestimmt. So kann geregelt werden, daß die neuen Daten erst anliegen sobald die alten verarbeitet wurden. Seite 14

16 4.2 Implementierung in SystemC Modulstruktur Grundsätzlich wurde während der eigentlichen Programmierung das Ziel verfolgt, eine ähnliche Struktur wie in VHDL basierten Hardwareentwürfen zu schaffen, die wir im Laufe unseres bisherigen Studiums bereits häufiger umgesetzt hatten. Dabei ist es im wesentlichen erforderlich eine getaktete Statemachine zu erzeugen, die synchrone Steuersignale ausgibt, welche zur Ansteuerung asynchroner Prozesse verwendet werden. Dieser Ansatz wird an dieser Stelle nicht weiter vertieft, da es nicht zum Projektziel gehört, VHDL typische Entwürfe zu erörtern. Jene Vorgehensweise erwies sich im Laufe der Implementierung zusätzlich als die am geeignetste, da der Synopsys SystemC Compiler nur für die SystemC Version 1.0 anwendbar ist, welche einen objektorientierten Ansatz nicht vorsieht. Ab der Version 2.0 ist auch ein solcher Ansatz umsetzbar, jedoch ließe er sich mit den gegebenen Tools lediglich simulieren, nicht aber kompilieren. Weiterhin wurde in der Dokumentation zu SystemC 1.0 selber, sowie in weiteren Quellen eine solche Vorgehensweise eindringlich empfohlen [SynSSC]. Der Quellcode wird auf einer CD beigefügt und wird hier nicht weiter erörtert. Die folgenden Erklärungen beschränken sich darauf, den Zusammenhang der einzelnen Module sowie deren grundsätzlichen Aufgaben zu verdeutlichen. Eine einführende Grafik veranschaulicht den Zusammenhang: Abbildung 4.3: Blockschaltbild SICTOP Das Top-Modul beinhaltet die Instanziierung der sieben darunter liegenden Module und die Verbindung ihrer Ein- und Ausgänge. Der D-Bus sowie diverse Steuersignale sind zur Synchronisation der einzelnen Module und für den internen Datenaustausch vorgesehen. Der Simulator übernimmt prinzipiell die gleichen Aufgaben wie das TOP-Modul, jedoch wird zusätzlich der Startpunkt für die ausführbare Programmdatei (sc main) gesetzt und eine Simulation eingebunden. Beim eigentlichen Ausführen des compilierten Programmes werden die zeitlichen Verläufe der Signale in eine tracedatei exportiert. Data-Memory Der Datenspeicher ist über den D-Bus mit dem Prozessor verbunden. Es können Lese- und Schreiboperationen ausgeführt werden. Seite 15

17 Core Der Prozessor mit seinen drei Bestandteilen Instruction-Unit, Data-Unit und Control-Unit wird in diesem Modul erzeugt. Auch hier werden interne Steuersignale für die Kommunikation der einzelnen Sub-Module verwendet, die sämtliche Funktionalitäten enthalten. So ist der Kern eigentlich auch nur ein Top-Modul. Instruction-Unit: Sie enthält den Instruction Pointer (IP), der auf den Instruktionsspeicher zeigt und die Adresse des nächsten zu verarbeitenden Befehls enthält. Diese Adresse wird zuvor berechnet und anschließend auf den I-Adressbus gelegt. Zusätzlich werden die Instruktionen gesplittet und in ihre 3 Komponenten zerlegt. Data-Unit: Die Data-Unit schaltet die Zeiger mit den Adressen der Operanden auf den D-Adressbus, ließt Operand A ein und puffert ihn internen zwischen. Anschließend wird Operand B gelesen, mit A verrechnet und das Ergebnis zurückgeschrieben. Control-Unit: Hier ist die Zustandsmaschine zur Steuerung der Abläufe innerhalb des Kerns verwirklicht. Die Zustände (IF, READ A, READ B, CALC, WB) werden in einer Endlos-Schleife nacheinander durchlaufen, wobei im wesentlichen folgende Schritte abgearbeitet werden: IF(Instruction Fetch): Adresse des nächsten Befehls auf den I-Adressbus legen, worauf dieser sofort verfügbar ist und eingelesen wird READ A: Erster Operand wird über den D-Bus gelesen und in einen Puffer gespeichert READ B: Zweiter Operand wird über den D-Bus gelesen und mit erstem Operanden verrechnet CALC(Calculate): Ergebnis der Berechnung mit entsprechender Adresse wird auf den D-Bus gegeben WB(Write Back): Das Signal DWrite des D-Busses wird aktiviert, damit das Ergebnis an die entsprechende Adresse geschrieben wird Eine detailierte Erklärung der einzelnen Zustände und der gesamte Ablauf eines Befehlszyklus sind weiter unten unter beschrieben. Instruction-Memory Der Instruktionsspeicher ist über den I-Bus mit dem Prozessor verbunden. Es können auch hier Leseund Schreiboperationen ausgeführt werden. Loader Der Loader ist für die Programmierung des Instruktionsspeichers vorgesehen. Er darf dafür den Prozessor anhalten, um über den D-Bus von der Serielle Schnittstelle Instruktionen zu empfangen und sie über den I-Bus in den Programmspeicher zu laden. Seite 16

18 IO-Seg7 Die 7Segmentanzeige wird auch über den D-Bus angesprochen, wobei Lese- und Schreiboperationen ausgeführt werden können. Das intern erzeugte Modul Seg7-Module verwaltet die Anwendung bzw. Codierung eines empfangenen Bytes, so daß es auch tatsächlich angezeigt werden kann. Dabei ist eine Ansteuerung der Anzeige laut der Dokumentation des Testboards berücksichtigt [XilBoard]. IO-Led Dieses Module ist ebenfalls über den D-Bus an den Prozessor angeschlossen und bietet eine Schreiboperation an, die das empfangene Byte an den LED s ausgibt. UART Das Modul UART ist eine weitere Ein-/Ausgabekomponente, die an den D-Bus angeschlossen ist. Der Datenaustausch über die Serielle Schnittstelle ist in der aktuellen Version auf eine Leseoperation begrenzt, da er ausschließlich zum Empfang von Daten vorgesehen ist Anpassung der bestehenden Software Die aus den vorherigen Projekten gegebenen Softwaremodule wurden als Grundlage für unsere überarbeitete Version genommen. Dabei sind jedoch folgende entscheidende Erweiterungen bzw. Veränderungen vorgenommen worden: 1. Asynchrone Daten- und Instruktions-Busse: Das Model zweier getrennter Speicher wurde aufrecht erhalten, jedoch werden sie nicht mehr über Multiplexer an den Prozessor angeschlossen, sondern über zwei getrennte, asynchrone Busse. Somit sind auch die Speicher asynchron, weshalb beispielsweise realer SRAM verwendet werden kann. In der aktuellen Version wird jedoch weiterhin der Speicher durch Flip Flops innerhalb des Chips simuliert. 2. Machinenzyklen: Ein Maschinenzyklus besteht nun nicht mehr aus zwei Zuständen, sondern aus fünf, was an der Statemachine des Prozessors erkennbar wird. Die zusätzlich eingeführten Zustände sind durch die Einführung des Bussystems begründet, da die Operanden nun sequentiell vom Speicher gelesen werden müssen, und nicht mehr parallel über Multiplexer gelesen werden. 3. Ladbares Programm: Der Instruktionsspeicher wird nicht mehr statisch eingerichtet, sondern kann zur Laufzeit vom Loader über die Serielle Schnittstelle downgeloadet werden. Dabei wird der Prozessor angehalten und in den Reset-Zustand gesetzt, weshalb das komplette Bussystem an den Loader als Master übergeben wird. Einführung des Bussystems Die Einführung eines Bussystems bestehend aus zwei getrennten Bussen für Instruktions- und Datenspeicher (I-Bus/D-Bus) ist wohl die bedeutendste aller Erweiterungen. Grundsätzlich sind die eigentlichen Daten- und Adressleitungen sowie zwei Steuersignale für das Lesen und Schreiben einer Adresse Hauptbestandteil der Busse. Weiterhin steuert der Kern als Master sämtliche Aktivitäten auf dem Bus, die Ein- und Ausgabekomponenten, wozu ebenfalls der Speicher zählt, müssen daher jeweils eine Busschnittstelle beinhalten, die in den Tristate-Zustand gehen kann. Das Prinzip eines Busses soll hier nicht vertieft werden, lediglich diese fundamentalen Bestandteile aufgezählt werden. Die einzelnen Busbreiten sind: D-Adressbus: 8bit D-Datenbus: 8bit Seite 17

19 DRead+DWrite: 2bit I-Adressbus: 16bit I-Datenbus: 24bit IRead+IWrite: 2bit Da ein Zustand ohne Busaktivität erforderlich ist, sind 2 Signale für die Durchführung der Lese- und Schreiboperationen notwendig. Um auf den Bussen eine fehlerfreie Datenübertragung durchzuführen, müssen die Schreibvorgänge in 3 und die Lesevorgänge 2 Taktzyklen umgesetzt werden. Diese Sachverhalte werden weiter unten unter genauer erläutert. IO-Komponenten/Serielle Schnittstelle Ein- und Ausgabekomponenten sind mit dem D-Bus verbunden und werden über einen definierten Adressbereich angesprochen. Dabei werden grundsätzlich Lese- und Schreiboperationen ausgeführt, die dann, je nach Komponente, weiterverarbeitet werden. Ein Beispiel liefert hier die serielle Schnittstelle, die als eine solche Komponente fungiert, obwohl sie nur Daten empfangen kann, also ausschließlich Leseoperationen anwendbar sind. Dazu erzeugt ein interner Taktgenerator, der für eine Baudrate von Baud ausgelegt ist, einen Takt zur Abtastung des Eingangssignales. Ein Start- und zwei Stoppbits markieren ein gültiges Byte. Eine Statemachine durchläuft insgesamt 5 Zustände, von denen ausgehend alle weiteren Funktionalitäten gesteuert werden. Ein Zähler ist für die Anzahl an abgetasteten Bits verantwortlich, der Buszugriff erfolgt über eine Busschnittstelle. Da die Serielle Schnittstelle in erster Linie für die Möglichkeit zum Laden verschiedener Programme in den Instruktionsspeicher verwendet wird, ist ein allgemeiner Gebrauch während des Programmablaufes nicht vorgesehen. Eine Erweiterung für Schreiboperationen leicht realisierbar. Laden eines Programms/Loader-Modul Mittels eines Tasters wird der SIC in den Zustand LOAD gesetzt, in dem der Prozessor angehalten wird und der Loader die Steuerung des Bussystems als Master übernimmt. Damit hat der Loader als einzige Komponente neben dem Prozessor Zugriff auf beide Busse, weshalb allgemeine Busschnittstellen, die auch für weitere IO-Komponenten verwendbar sind, implementiert sind. Die Funktionalität sieht vor, daß die Rohdaten, also die Instruktionen, an die Serielle Schnittstelle gesendet und dort gepuffert werden. Ist mindestens eine komplette Instruktionen, also 3 Bytes, im Puffer gespeichert, werden sie vom Loader über den D-Bus abgeholt und über den I-Bus in den Instruktionsspeicher geschrieben. Dieses geschieht solange, bis der SIC über den Reset-Taster in den Ablaufmodus zurückgesetzt wird. Die Befehle werden also sequentiell beginnend ab Adresse 0x00 in den Speicher geschrieben. Ein Beschreiben des Datenspeichers ist nicht vorgesehen, kann jedoch nachgerüstet werden, da das Loader-Modul bereits an den D-Bus angeschlossen ist Simulation eines Befehlszyklus Der implementierte SystemC Entwurf des erweiterten SIC kann mit SystemC simuliert werden. Dazu werden die einzelnen Module in der sc_main Methode instanziiert und über Signale miteinander verbunden. Im ersten Simulationslauf generierte der C/C++ Compiler eine Reihe von Fehlermeldungen. Es stellte sich heraus, daß ausnahmslos alle Ausgänge eines Moduls an ein Signal gebunden werden müssen [Grimm2003]. Für die Stimulierung aller Module wird der Systemtakt angelegt: // Systemtakt sc_clock clock("clock", 2, SC_MS); Seite 18

20 Die Änderungen auf den Signalen können mit der sc_trace_file Funktion in einer Datei aufgefangen werden. Über sc_trace werden die einzelnen Signale in den Trace einbezogen: // Tracefile vorbereiten sc_trace_file *trace_file = sc_create_vcd_trace_file("sim_trace"); sc_trace(trace_file,clock,"clock"); sc_trace(trace_file,reset,"reset"); sc_trace(trace_file,i_addr,"i_addr"); sc_trace(trace_file,i_read,"i_read"); sc_trace(trace_file,i_write,"i_write"); sc_trace(trace_file,i_data,"i_data"); sc_trace(trace_file,d_addr,"d_addr"); sc_trace(trace_file,d_read,"d_read"); sc_trace(trace_file,d_write,"d_write"); sc_trace(trace_file,d_data,"d_data"); sc_initialize(); Das Ergebnis der Simulation wird in die Datei SIM_trace.vcd geschrieben. Bevor die Ergebnisse in ModelSim betrachtet werden können, muss die.vcd Datei in das.wlf Format gewandelt werden. ModelSim liefert zu diesem Zweck das Befehlzeilenprogramm vcd2wlf mit. Nach der Konvertierung kann die Simulation in ModelSim betrachtet werden. Abbildung 4.4: Waveform der SystemC Simulation in ModelSim In Abbildung 4.4 sind die einzelnen Phasen der Befehlsverarbeitung durch Zahlen markiert: Phase 1 (Instruction Fetch) Nachdem das Reset Signal auf low gewechselt hat, legt der SIC Kern die erste Instruktionsadresse auf den I-Adressbus (Signal i addr). Der asynchrone Instruktionsspeicher liefert gleich darauf den Inhalt der adressierten Speicherzelle auf den I-Datenbus (Signal i data) zurück. In der Instruktion sind die Adressen der Operanden im Datenspeicher hinterlegt (Zeiger). In diesem Fall ist die Adresse für A 0x01h und für B 0x03h. Sprungweite C ist in der Instruktion mit 1 angegeben, d.h. bei einem negativen Ergebnis wird der Instruktionszeiger trotzdem auf die nächste Instruktion in Folge zeigen. Für diese Simulation wurden an der Datenspeicheradresse 0x01h der Wert 1 und an der Adresse 0x03h der Wert 3 hinterlegt, so daß -2 als Ergebnis der Instruktion erwartet wird. Der Ergebniswert muss an die Speicherstelle A, also 0x01h, zurückgeschrieben werden. Phase 2 (Read Operand A) Der SIC Kern beginnt damit den Wert des Operanden A aus dem Datenspeicher auszulesen. Die Adresse des Operanden A wurde bereits direkt aus den Instruktionsdaten in Phase 1 auf den D-Adressbus gelegt (Signal d addr). In dieser Phase wird das Signal d read auf high gesetzt, Seite 19