Wie viele andere Techniker und Ingenieure bastelte ich bereits in meiner Jugend mit analoger und digitaler Hardware. Damals natürlich im Wesentlichen mit einzelnen Operationsverstärkern, Gattern und Flipflops. Als mein Vater 1990 seinen ersten PC erwarb, begann ich mit dem Programmieren. Während meines Studiums der Elektrotechnik/Regelungstechnik an der TU Darmstadt wurde aus dem Basteln zunehmend ein Entwickeln, auch Mikrocontroller und Peripheriebausteine kamen zum Einsatz. Um im Rahmen meiner ersten Anstellung echtzeitfähige Software zur Modellierung und Regelung von verfahrenstechnischen Prozessen erstellen zu können, benötigte ich schließlich noch eine Portion numerische Mathematik, die aus heutiger Sicht im Ingenieur-Studium viel zu kurz kommt. Heute beschäftige ich mich mit der Integration von Sicherheitssystemen auf Schienenfahrzeugen, habe also mit der eigentlichen Hard- oder Softwareentwicklung nicht mehr viel zu tun. Dennoch ist es vorteilhaft, wenn man die Technik der Lieferanten etwas genauer versteht. Programmierbare Logik war eine der wenigen mir bis dahin völlig unbekannten Welten, so beschloss ich, dies zu ändern.
Nach ein paar Tagen allgemeiner Orientierung (was ist ein PLA, ein CPLD oder ein FPGA, welche Software braucht man etc.) bestellte ich den Spartan3-Starter Kit von Digilent als wohl eine der günstigsten Variaten, in die Welt der FPGAs einzutreten. Die ersten Schaltungen waren in VHDL schnell beschrieben und so sollte als nächstes ein digitaler Funktionsgenerator mit zwei Kanälen, 4-zeiliger LCD-Anzeige etc. entstehen. Soweit kein Problem, allerdings fiel auf, dass der Funktionsgenerator an sich nur einen Bruchteil eines FPGAs benötigt, die für die Bedienung erforderliche Hardware im FPGA allerdings in der Größenordnung von mehreren 100 Slices zuzüglich RAM liegt und der Bedienkomfort trotzdem nicht das ist, was man von dergleichen Systemen erwartet. Die geplante Erweiterung um einen USB-Anschluss und einen A/D-Wandler war auf dem Niveau jedenfalls nicht zu realisieren. Einzige Lösung war ein Mikroprozessor. Selbstverständlich im FPGA - dass dies machbar wäre, war mir aus diversen Artikeln und Foren-Beiträgen klar. Warum ich keinen fertigen Prozessor wie den Picoblaze eingebunden habe? Ich wollte doch was lernen - und dafür ist der Weg bekanntlich das Ziel.
Mit diesen Rahmenbedingungen wurde in mehreren Iterationsschritten ein auf den Spartan3 zugeschnittener 16-bit Prozessor entwickelt. Durch sehr effizienten Einsatz der zur Verfügung stehenden Komponenten des Spartan3 und gleichzeitige Optimierung der Codierung konnte ein Flächenbedarf von nur etwa 200 Slices und gleichzeitig eine Taktfrequenz von rund 66 MHz auf der langsamen Variante (Geschwindigkeitscode -4) erreicht werden. Hierbei wird für alle Befehle mit Ausnahme des Ladens aus dem Speicher und der Division grundsätzlich ein Takt benötigt. Insgesamt ergibt sich damit ein im Vergleich zu "Nachbauten" existierender Standardprozessoren wesentlich besseres Verhältnis von Geschwindigkeit zu Fläche.
Gleichzeitig muss natürlich darauf hingewiesen werden, dass die genannten Eckdaten wahrscheinlich nur mit FPGAs der Spartan3 und VirtexII-Familien erreicht werden können bzw. es nicht möglich war, alle VHDL-Beschreibungen Hardware-unabhängig zu halten. Zumindest das WebPack 8.1 ist an einigen Stellen nicht in der Lage, die Hardware aus einer Verhaltensbeschreibung heraus ideal auszunutzen.
Will man nicht Befehle von Hand codieren, muss ein Assembler her. Da ich auf die Schnelle nichts Brauchbares gefunden habe (entweder ohne jegliche Dokumentation oder zu einfach oder zu kompliziert), habe ich einen relativ einfacher Assembler in C geschrieben. Dieser ist in Kapitel 3 dieser Dokumentation beschrieben. Er ist hoffentlich mit jedem existierenden C-Compiler zu kompilieren, egal auf welcher Maschine. Ich nutzte sowohl gcc unter Linux als auch Dev-C++ mit mingw32.
Da sich in einem FPGA relativ schwer Fehler suchen lassen und ich mit der VHDL-Simulation des Prozessors wahrscheinlich heute noch am simulieren wäre, schrieb ich außerdem einen Simulator in Java, welcher gleichzeitig als Debugger dient. Der Prozessor wurde dabei nahezu auf RTL-Ebene abgebildet, was die Suche von Fehlern im VHDL-Code vereinfacht, aber natürlich für das Debuggen von Assembler-Programmen unnötig langsam ist. Insgesamt ist der Simulator wirklich extrem einfach gehalten, aber dafür hat er auch eine sehr einfach zu bedienende Oberfläche. Letztlich benötigt habe ich ihn dann doch nur für das Debuggen von Assembler-Programmen, da im VHDL-Code von Anfang an wider Erwarten keine wesentlichen Fehler waren.
Was vielleicht noch fehlt, ist ein C-Compiler. Da dieser für das Testen des Prozessors nicht nötig ist, habe ich bislang darauf verzichtet, mich auch noch in anpassbare C-Compiler einzuarbeiten. Da gibt es sicherlich Spezialisten, die das wesentlich besser und schneller hinbekommen als ich. Aufgrund des doch begrenzten Befehlsspeichers sowie in Anbetracht der Anwendungen von FPGA-Prozessoren überhaupt ist ein Compiler aus meiner Sicht doch eher "nice to have" als unbedingt notwendig.
| Zurück: Index | Index | Weiter: Prozessor |
Stand 16.09.2006
Copyright 2006 by Thomas Brunnengräber
Diese Dokumentation unterliegt den Bestimmungen der GNU Free Document License