Das Freedom-CPU-Projekt

Andreas Romeyke

Ich beantworte gern Fragen zum Vortrag, und auch Diskussionen aus der Newsgroup werden hier zusammengefaüt.

Das vorliegende Dokument unterliegt der F-CPU-Charta und der GNU Documentation License

Das Freedom-CPU-Projekt widmet sich seit über 2 Jahren dem Entwurf eines Freien 64-Bit Prozessors. Frei heißt dabei, das der Bauplan jedem zugänglich sein soll, ihn jeder Umsetzen kann und er verändert werden darf, solange die Änderungen wieder frei verfügbar gemacht werden. Das Projekt wird - ähnlich wie das Freie Betriebssystem GNU/Linux - von unzähligen über die Welt verteilten Hobbyisten vorangetrieben und hat inzwischen beachtliche Fortschritte gemacht.

Wozu eine freie CPU?

Dies war die Frage, die im Jahre 1998 zur Entstehung des Freedom-CPU-Projektes geführt hat, doch zur Geschichte spüter mehr.

Der Hauptvorteil nicht nur bei dem F-CPU-Projekt, sondern bei allen freien Hardwareprojekten ist die gute, für jedermann erhältliche, frei verfügbare Dokumentation. Wenn man sich zum Beispiel an den C64 erinnert und dessen Entwicklung verfolgt, so versteht man die Begeisterung dafür und seine programmtechnische Ausreizung nur, wenn man sich auch die damalige Zeitschriftenlandschaft ins Gedächtnis ruft. Durch seine grosse Verbreitung und durch die vielen fundierten Beiträge und Artikeln in den C64-spezifischen Zeitschriften entstand über mehrere Jahre hinweg eine dermassen grosse Wissensbasis, die man heute bei Hardware vergebens sucht. Genau dieses Wissen über die Details der Hardware ist Grundlage für die optimale Anpassung der Software, und nur dann, wenn Hardware und Software aufeinander abgestimmt sind, erhält man ein optimales System.

Aber nicht nur die Dokumentation als solche ist ein Vorteil von freier Hardware, vielmehr ermöglich die Offenlegung der Quellen, der Baupläne eine individuelle Anpassung an ganz bestimmte Bedürfnisse, sei es weil man in einer Anwendung noch DSP-Fähigkeiten benötigt, oder Hardwareunterstützung für bestimmte Kryptoalgorithmen benötigt.

Desweiteren ist freie Hardware im allgemeinen nicht an politische oder marketingpolitische Entscheidungen gebunden, so das man alte und überholte Paradigmen über Board werfen kann (hier sei an das unsäglich Gate A20 und das vermurkste Befehlsformat bei x86-er Prozessoren errinnert), dadurch kann man Hardware realisieren, die einfach durch das Lernen von Fehlern anderer, diese vermeidet und im Vergleich eine echte Alternative auch in Punkto Geschwindigkeit oder Leistung/kosten-Verhültnis darstellt.

Indem man ein Design von Grund auf unter Vermeidung alter Fehler auf die Beine stellt, wird das Design auf die potentiellen Entwickler magische Anziehungskraft haben, so daü voller Zugriff auf den m&�uml;glichen Brainpool erreicht werden kann. Dies heisst nichts anderes als dass viele Ideen zusammenfliessen und erprobt werden. Nun, ein solches Projekt muss sich auch konkreten Zielen zuwenden, und so wurde als erstes über die Mailingliste diskutiert, welche Anforderungen man denn an ein CPU-Design hat.

Um eine CPU breit einsetzen zu können, muss das Design leicht skalierbar sein, dort brauche ich einen 8Bit Prozessor für kleine Geräte, dort was für numbercrunching. Wichtig ist hierbei, genauso wie für eventuelle Ergänzungen, daß das Design von seiner Architektur geradlinig und sauber implementiert ist, oder kurz gesagt, es muss durchdacht sein und dabei verständlich bleiben. Die Forderung nach der Verständlichkeit stellt dabei nicht nur der Ingeneur, der ggf. Anpassungen vornehmen will, auch die Softwareentwickler fordern, daszlig; der Befehlssatz überschaubar, orthogonal, also in sich konsistent ist (dh. keine speziellen Adressierungen abhängig von bestimmten Befehlen, sondern ein einheitliches Adressierungsschema). Neben einer ordentlichen Ausnahmebehandlung ist in der heutigen Zeit der Multitaskingbetriebssysteme vor allem eine gute Unterstützung für das Prozesshandling wichtig. Und was man nicht vergessen sollte, das beste Design nützt nichts, wenn es zu langsam ist.

Aus diesen ganzen Anforderungen wurde für das F-CPU-Projekt Designkriterien aufgestellt, hier in absteigender Wichtigkeit: Die CPU soll...

.

Diese Kriterien entstanden durch die lebhafte Diskussion auf der Mailingliste und es brauchte knapp 2 Jahre, bis man sich für die heutige RISC-Technologie entschied und das Befehlsformat definierte. Im Jahre 1998 gab es die erste EMail auf der Mailingliste, und das Projekt Freedom-CPU, welches zuerst nur in den Köpfen und Mails der Linuxentwickler Andrew D. Balsa, Rafael Reilova und Richard Gooch als Idee existierte nahm langsam Gestalt an. Als erste Architektur war am Anfang TTA (transfer triggered architecture) im Gespräch, da TTA aber ein neues, ungewohntes Paradigma war, wurde es genauso wie der zweite Vorschlag einer M2M-Architecture (memory to memory) zu Gunsten von RISC (reduced instruction set) verworfen. TTA war bemerkenswert, und ich will versuchen die Unterschiede zwischen TTA und einer "klassischen" Architektur zu verdeutlichen:

Wenn man einem Arbeiter sagt: "Nimm den Stoff von Ort A, gehe zu B, färbe ihn, gehe zu C, trockne ihn, gehe zu D und schneide ihn zu, dann hat man es mit der klassischen Architektur zu tun. Ich setze explizite Befehle ab. anders bei TTA, dort gibt es pro Platz einen Arbeiter, der spezialisiert ist, die Arbeitsplätze sind durch ein getaktetes Förderband mit den Arbeitsplätzen verbunden und wenn der Arbeiter an A was angeliefert bekommt, bearbeitet er es und schickt es auf den Weg, genauso die anderen Arbeiter. Bei der TTA muss man quasi den Verbindungspfad zwischen den Stationen herstellen, dass ist der Unterschied. Die Vorteile liegen auf der Hand, die Hardware wird einfacher, da es spezielle "Schnittstellen", Ports zu den einzelnen Units gibt, die eine Aktion auslüsen, sobald Daten dort anliegen. Der Nachteil ist ein Compiler muss mühseliger die Pfade berechnen, und da diese technik neu ist, hatte man das Skalierungsproblem nicht im Griff, da die Ports als feste Adressen implementiert werden mussten, die nicht skalierbar waren, ohne die Binärkompatibilität zu geführden. Dies führte dann nach einem kurzen Abstecher über die M2M zum RISC. RISC war einfach im Befehlsaufbau, wurde scon lange genug untersucht und ermöglichte auch einen einfachen Hardwareaufbau. In der Ct' 3/2000 wurde dann die erste Unit der F-CPU und das zukünftige Design vorgestellt.

Um zu verstehen, wie die F-CPU funktioniert, muss man einige Grundkonzepte verstanden haben. Eine Grundfrage im Entwurf der Freedom-CPU war die, wie man, wenn man Fortschritte im Fertigungsprozess ausser Acht lässt, Prozessoren allgemein schneller machen kann. RISC bot eine Möglichkeit, indem Befehle mit gleicher Breite eingeführt wurden, die über eine Technik namens Superpipeling ein Ergebnis bei gefüllter Pipeline pro Takt lieferten. Neben RISC gibt es dann noch die Müglichkeit der Parallelisierung, dh. wenn möglich sollten mehrere Einheiten gleichzeitig an verschiedenen Dingen rechnen. Nicht ganz unwichtig ist dann noch der Aspekt der schon oft besprochenen Skalierung, da es einen Unterschied macht, ob ich eine 64-Bit Addition auf einer 8-Bit CPU oder auf einem 64 Bit Prozessor mache.

Bei der F-CPU versucht man die Vorteile aller drei genannter Techniken zu vereinen, der Befehlsdecoder wurde so gestaltet, daü sich ein Befehl in die bei RISC |blichen Stufen fetch (Holen), decode (Befehl dekodieren), adress (Adressieren der Daten), exec (eigentliches Berechnen) und write (zurückschreiben des Ergebnisses) gliedert. Was wird damit erreicht? Nun, wenn es verschiedene Einheiten gibt, die jede dieser Stufe erledigen und man diese Einheiten über eine Pipeline verbindet, so kann man vereinfacht gesagt, pro Takt ein Ergebnis bekommen. Das Ganze funktioniert wie eine Lüschkette, ist die Kette erst einmal aufgebaut, sprich der erste Eimer ist am Brandherd angekommen, dann kommt pro Takt ein Eimer Wasser an. Ein anderer Punkt ist, daü das Design der F-CPU so ausgelegt ist, das es über einen Parameter skaliert werden kann, sprich statt 64 Bit Register, können 256-Bit CPUs durch Ändern einer Variable im "Bauplan" erzeugt werden. Dieser Mechanismus wird sogar auf die letzte Parallelisierungstechnik der SIMD-Register/SIMD-Befehle angewandt, dabei ist gemeint, daß eine Einheit entweder ein 64-Bit, 2 32-Bit, 4 16-Bit oder 8 8-Bit Chunks eines Registers gleichzeitig bearbeiten kann. Dieser Mechanismus wurde in jede Einheit eingebaut und kann über jeden Befehl angesprochen werden.

Neben den oben beschriebenen Techniken und Verfahren kommen noch eine ganze Menge anderer zum Einsatz, die das F-CPU-Projekt so interessant machen, beispielsweise ist der Befehlssatz so ausgelegt, daß 110 Befehle mit allen möglichen Erweiterungen, ua. für Coprozessoren definiert sind, verschiedene Arithmetiken ( IEEE Gleitkomma, gebrochene Zahlen), spezielle Speicherstromsteuerungsbefehle und das SIMD-Flag unterstützt werden. Es gibt RISC-typisch 64 allgemeine Register, es wird Paged Memory unterstützt, es gibt einen TLB um virtuelle und logische Adressen zu mappen, einen Crossbar, der dynamisch logische Kanäle zwischen den Einheiten realisiert, und was ganz feines, so genannte Context Memory Blocks, die in Verbindung mit einem Smooth-Register-Backup-Mechanismus den kompletten Status eines Prozesses halten. Hier sei auf Grund der Fülle von Informationen auf das Handbuch verwiesen, wo jedes Detail und auch jede Einheit ausführlich beschrieben ist.

Nun, wie sieht der Bauplan aus? Man verwendet beim F-CPU-Team die Hardwarebeschreibungssprache VHDL'93. Durch diese Programmiersprache ist es möglich das F-CPU-Projekt, wie ein beliebiges Softwareprojekt zu handhaben, man kann also den Lieblingseditor seiner Wahl benutzen, und auch auf ausgefeilte Teamwork-Werkzeuge wie CVS und Co zurückgreifen. Die erste Phase des Freedom-CPU-Projektes ist also naturgemäss die Fertigstellung der Spezifikation und der VHDL-Files, sowie deren Simulation und Verifikation. In Phase 2 werden die VHDL-Files als Grundlage für die Programmierung der FPGAs dienen, wobei es heute noch keinen bezahlbaren FPGA gibt, in den die F-CPU bzw. der FC0-Core im Ganzen hineinpasst.

Wenn die CPU über die FPGAs getestet wurden sind, so wird die letzte Phase anlaufen, bei der das Projekt in Silizium gegossen wird. Laut Handbuch wurden für den Herstellungsprozess Erkundigungen gemacht, so das man bei 10.000 Stück von einem Stückpreis von ca. 60 USD ausgeht, wir werden sehen...

Wenn man von einer CPU redet, dann sollte man nicht vergessen, dass eine CPU nichts ist, wenn es keine Software dafür gibt. So hat das F-CPU-Team schon frühzeitig mit den Entwicklern des GCC und des Linuxkernels Kontakt aufgenommen, so daß Erfahrungen ua. in das Befehlssatzdesign eingeflossen sind. Aber nicht nur dass, auch wurde vom F-CPU-Team schon ein GCC angepasst und ein Assembler erstellt, man kann also sofort loslegen.

Einige wichtige Dinge braucht na ja noch, wenn man eine CPU etablieren will, was fehlt ist ein Motherboard, bzw. Socket. Das F-CPU-Projekt hat sich darüber erstmal keine Gedanken gemacht, im Manual wurde der Alpha-Socket erwähnt, das muss man abwarten.

Was ein Problem darstellt, ist die Simulation. 64-Bit sind nicht von Pappe, vor allem, wenn man Testvektoren generiert und die Reaktionen auf Logik- und Registerebene überprüfen muss. Erfahrungen haben gezeigt das die Simulationssoftware wohl ca 4GB RAM benötigt und auf schnellen CPUs mehrere Tage rechnet. Wer uns also solch eine Maschine zur Verfügung stellen kann...

Ebenso problematisch sind zur Zeit die EDA-Tools, wobei das Hauptproblem in der unvollständigen Implementierung des VHDL'93-Standards in vielen Tools ist. Auch kann man meist die freien EDA-Tools nicht einsetzen, da es sie bis vor kurzem einfach mangels Hardware und Interesse nicht gab. Das ist auch der Grund, warum in dem Projekt nur Wenige involviert sind, es gibt einfach nicht so viele Leute, die sich mit Hardwaredesign allgemein und mit VHDL im Speziellen auskennen.

Ich muss zugeben, daü dies ein ganz schön langer Text geworden ist, für diejenigen denen es zuwenig oder gar zuviel war, gebe ich hier noch ein paar Links an, wo man sich auch noch informieren kann:

Die Materialien zum Vortrag sind erreichbar unter: http://gaos.org/vortrag/f-cpu bzw. unter http://andreas-romeyke.de/privat/

Für Rückfragen stehe ich unter andreas{dot}romeyke[at]web{dot}de zur Verfügung.

© 06/2001 Andreas Romeyke