Ausarbeitung zum Thema " FLEETzero " der SUN MicroLabs - "Die Registerlose Prozessorarchitektur"

Inhaltsverzeichnis

1  Vorwort  2

2  Überblick  3

2.1  Motivation  3

2.2  Die Idee der kommunikationszentralen Sicht  3

3  FLEETzero Chip  5

3.1  Grundverständnis  5

3.2  Switch Fabric  6

3.2.1  Primitive  6

3.2.2  Netzwerke  6

3.3  Instruction Store  9

3.4  Ships  10

4  Ergebnisse  12

5  Fazit und Ausblick  14

5.1  Fazit  14

5.2  Ausblick  15

1

Kapitel 1

Vorwort

Diese Ausarbeitung beschäftigt sich mit der als innovativ angesehenen registerlosen Prozessorarchitektur des FleetZero. Sie basiert hauptsächlich auf der von Sun Microsystems Laboratories vorgestellten Präsentation zum „Seventh International Symposium on Advanced Research in Asynchronous Circuits and Systems“ im Jahr 2001, da diese als einzigste aussagekräftige Referenz angenommen werden kann. Leider existieren noch keine größeren Publikationen (im Rahmen der Ausleihmöglichkeiten unserer Universitätsbibliothek) zu diesem Thema. Im Internet zu findende Themen sind meißt recht deutlich an die Eigenbeschreibung der Sun Microsystems Laboratories angelehnt und somit kein Quell zusätzlicher Informationen. Das Ziel dieser Ausarbeitung ist es, einen Einblick in die FleetZero-Rechnerarchitektur zu bekommen, der durchaus zum Eingliedern in eine Vorlesungsveranstaltung (zum Beispiel als Ergänzung der speziellen und innovativen Rechnerarchitekturen) verwendet werden kann. Hierzu soll diese Ausarbeitung als Richtlinie dienen, sowie die beigefügten Folien zur Präsentation und als druckbares Skript. Diese Ausarbeitung enthält insbesondere viele Vereinfachungen und verzichtet bewusst auf Details, die nicht zum Verständnis der Thematik nötig sind. In dieser Arbeit wurde versucht grundsätzlich die deutsche Sprache zu verwenden. Lediglich bei einigen Fachbegriffen sowie Eigennamen wurde, um eventuelle Missverständnisse zu vermeiden, die englische Sprache verwendet.

2

Kapitel 2

Überblick

2.1 Motivation

Heutige Prozessorarchitekturen sind hauptsächlich in einer Zeit entwickelt wurden, in der Vakuum-Röhren und Großraumtransistoren die Logik-Einheiten darstellten. In den frühen 80’igern waren Logik-Bausteine „teuer“, sowohl in finanzieller, als auch aus Sicht der Rechenzeit und des Stromverbrauches. Deswegen konzentrierte man sich vor allem darauf logische Operationen (zB. ADD, NEGATE, usw.) zu optimieren, um Logikeinheiten, so weit es geht, einsparen zu können. Dazu benötigte Kommunikationsaktivitäten wurden hauptsächlich, bis auf Ausnahmen wie Load, Store, Input und Output vom Programmierer versteckt, da die Kosten für Kommunikation, im Verhältnis zur Logik, als vernachlässigbar angesehen werden konnten.Im Zuge der intensiven Forschungen auf dem Gebiet der Halbleitertechnik verschob sich dieses Bild aber vollständig und entspricht in keinster Weise mehr dem Stand der Dinge. Transistoren sind nahezu kostenfrei und in ausreichender Menge auf kleinstem Raum vorhanden, verbrauchen zudem wesentlich weniger Energie als noch vor Jahren. Kommunikationselemente hingegen verbrauchen viel Platz und Energie. Ein ganz entscheidender Fakt ist, dass es heutzutage länger dauert 2 Zahlen zu einer Addier-Logik zu bringen, als diese dann zu addieren.

2.2 Die Idee der kommunikationszentralen Sicht

Es wird also Zeit die traditionelle Ansicht hinter sich zu lassen und eine völlig andere Richtung der Entwicklung einzuschlagen. Hierbei kommt der Begriff der kommunikationszentralen Sicht ins Spiel. Dieser Begriff ist nicht neu, wurde aber in der Vergangenheit im Zusammenhang mit synchronen „trans-port triggered“-Architekturen verwendet. Ab hier soll er jedoch nur noch im Zusammenhang mit asynchronen Schaltkreis-Primitiven stehen, da diese neben verbessertem Durchsatz und verbesserter Flexibilität auch eine größere

3

Freiheit des Programmablaufes bieten. Um die Entwicklung dorthingehend zu verwirklichen, wurden spezielle Move-Anweisungen entworfen, welche Daten von einer Quelle zu einem Ziel transportieren und diese während diesem Transport weiter verarbeiten (addieren,negieren, usw.). Das ganze wäre jedoch sinnlos wenn die Datenbewegung hierbei langsam wäre. Um den Durchsatz zu erhöhen und gleichzeitig die Latenzzeiten zu verringern, wurden unter anderem folgende Gedanken verwirklicht:

• Latches in der Datenleitung integrieren, die nicht nur zur Signalverstärkung dienen, sondern auch das Kabel in aufeinander folgende Sektionen aufteilen, welche gleichzeitig agieren können und

• die Entwicklung einfacher aber sehr schneller Steuerungsschaltkreise, welche GasP genannt wurden (mehr dazu in [Suth01]).

Der Kernidee des schnelleren Betriebes der eben erwähnten GasP Steuerschaltkreise ist dadurch zu erklären, dass die zentrale Taktgebung wegfällt und somit die Geschwindigkeit des Gesamtsystems nicht mehr von der Geschwindigkeit der langsamsten Operation abhängt. Lokale Taktgeber geben also nur noch für kleine Teilbereichen der Schaltkreise den Takt vor. Dies stellt eine Weiterentwicklung der CMOS Schaltkreise dar und wird in späteren Entwicklungsstufen unter anderem auch als „Asynchronous Interlocked Pipelined CMOS“-Technologie benannt.

In der Zeit zwischen 1998 und 1999 entstand der Experimentalchip FLEETzero, welcher für den ersten nichttrivialen Einsatz der GasP Steuerschaltkreise steht und der als Kern dieser Ausarbeitung näher vorgestellt werden soll.

Kapitel 3

FLEETzero Chip

3.1 Grundverständnis

Um einen noch nicht konkreten Einblick in die Grundstruktur der neuen Architektur zu bekommen, soll als erstes Abbildung 3.1 dienen. An dieser Stelle

wird zum ersten mal das grobe FLEETzero Schema vorgestellt. Wollen wir nun versuchen, die einzelnen Komponenten nacheinander näher zu erläutern um zu verstehen, was eigentlich genau an jedem Ort passiert.

5

3.2 Switch Fabric

Die Switch Fabric besteht im wesentlichen aus zwei einfach gehalteten Basis-Modulen, die hier als Primitive bezeichnet werden.

3.2.1 Primitive

Das erste Primitiv ist das datenabhängig Branch-Modul. Jeder In-/Output Port repräsentiert hierbei einen Kanal, welcher einen Datenpfand und eine asynchrone Steueranweisung (Order-Input) enthält. Das Modul selber steuert jede Dateneinheit vom Input zu einem der beiden Outputs, je nachdem was durch die Steuereinheit vorgeschrieben wird. Die Steuerung der Datenbewegung hierbei, erfolgt durch ein asynchrones FirstInFirstOut(FIFO)-Protokoll. Die Abbildung 3.2 verdeutlich diese einfache Primitive. Eine Weiterentwicklung brachte jedoch ein modifiziertes Branch-Modul (siehe Abbildung 3.3) hervor, welches nun hauptsächlich benutzt wird. Dieser vereinigt den Daten- und Orderinput zu einem einzigen Kanal, wärend er am Output eine Kopie des Orderinputs erzeugt. Der Grund hierfür ist, dass einem Branch sehr oft ein Merge folgt, welches durch den Order-Kanal spezifiziert bekommt, was das vorangestellte Branch getan hat, um die Ordnung der Dateneinheit zu bewahren. Das zweite Primitiv, was bereits benannt wurde, ist also das Merge-Modul, welches in Abbildung 3.4 dargestellt ist und exakt an das modifizierte Branch-Modul angepasst ist. Mittels dieser beiden Module lassen sich nun einfache Schaltnetzwerke (Switch Networks) erzeugen.

3.2.2 Netzwerke

Ein ganz einfaches Netzwerk sei in Abbildung 3.5 dargestellt. Es soll lediglich als Einstieg in die Netzwerkstrukturen dienen und wird so natürlich nicht verwendet. Das Branch Modul auf der linken Seite leitet die ankommenden Inputs entweder an die obere oder untere Daten-FIFO weiter. Für jeden einzelnen Input wird zudem ein Bit erzeugt, welches in die Order-FIFO eingeht, welche ab hier auch als Order-Wire benannt werden soll, näheres dazu aber

6

später. Auf der rechten Seite befindet sich das Merge Modul, welches mit Hilfe der Order-FIFO den Originalinputdatenstrom wiederherstellen kann. Die kleinen Kreise stellen in der Abbildung nicht nur eine Menge von Latches dar, welche jeweils eine Daten-Einheit speichern kann, sondern auch einen GasP-Steuerschaltkreis, welche aufzeichnet, ob ein Latch gerade Daten hält oder leer ist.

Horn and Funnel Netzwerk

Ein weitaus komplexeres „Switch“- Netzwerk ergab sich aus der Anforderung 4 Inputs mit 4 Outputs (bzw. 8 Inputs mit 8 Outputs usw.) zu verbinden, wobei theoretisch jeder Input an jeden Output gesendet werden kann. Mögliche Topologien für solche Netzwerke gibt es viele, für die FLEETzero Switch

7

Fabric wurde ein spezielles Horn and Funnel Netzwerk benutzt. Das Horn steht hierbei im Sinne von Verzweigung (oder Aufspaltung), wobei Funnel im Sinne von Zusammenführung und Einhaltung der Ankunftsreihenfolge (oder trichtern) steht.

Im Detail unterteilt sich die FLEETzero Switch Fabric in 4 Bereiche. Dem „source horn“, welcher einem binären Auswahlbaum entspricht, dem „source funnel“, welcher einem binären Verbindungsbaum entspricht, dem „trunk“, welcher zwei Stufen besitzt und die Verbindungsleitung zwischen „source funnel“ und „destination horn“ darstellt, und zu guter letzt dem „destination horn“, welcher wieder einem binären Auswahlbaum entspricht. Ein Horn Bereich verwendet in dem Zusammenhang modifizierte Branch Module, der Funnel hingegen Merge-Module. Um die Arbeitsweise näher zu verstehen, ein kleines Beispiel mit einer 3-bit Adresse welche die Quelladresse S1 in Abbildung 3.7 darstellen soll. Betrachten wir zunächst einmal ausschliesslich die Linke Seite. Das Branch-Modul AA erhält das erste Adressbit und entscheidet damit, wohin er die übrigen Adressbits schickt. In unserem Beispiel schickt es die verbleibenden zwei Adressbits aufwärts zu Branch BB. Dieses entscheidet mit dem Adressbit Nummer zwei, ob es das Adressbit Nummer drei nach oben zum Merge CC oder nach unten zu Merge-Modul DD schickt. In unserem Beispiel schickt es Adressbit Nummer drei nach oben zu CC. Nebenbei, was nicht vergessen werden sollte, fügt es Adressbit Nummer 2 aber auch in die Order FIFO EE ein. Im Merge CC entscheidet das dritte Adressbit, dass Quelle S1 gewählt wird und sobald diese verfügbar ist, wird die darin befindliche Dateneinheit an FF geschickt. Das Merge Modul FF muss nun entscheiden welches seiner zwei Inputs weitergeschickt wird. Dies macht es mit Hilfe der Information aus der Order FIFO EE welche ständig überwacht wird. Liegt hier im Order FIFO Input das zweite Adressbit an, wird die Dateneinheit aus CC hindurchgeleitet. Hieraus erkennt man die Bedeutung der Order FIFO. Die gewählte Anzahl der Stufen, die diese beinhaltet ist ebenfalls von Interesse, denn wenn sie zu kurz ist, wird die Kapazität des Merge Moduls begrenzt, ist sie zu lang vergrößert das die Latenz. Genaueres soll hier jedoch nicht näher erklärt werden, für Interessierte wird aber auf [SML01] verwiesen.

8

3.3 Instruction Store

Die Befehle des FLEETzero werden in der sogenannten Dual Cargo Unit gehalten. Diese Unit enthält jeweils zwei Cargo Ringe mit jeweils 32 Segmenten und bietet daher den Platz für 64 Anweisungen. Abbildung 3.8 verdeutlicht solch eine Cargo Unit. Um die Ringe zu „be- und entladen“ werden standar-

disierte Put/Take Schnittstellen benutzt, welche u.a. in [SML98] näher be-

9

schrieben sind. Durch ein externes Signal (Arbiter) kann die Abarbeitung der Ringe unterbrochen werden, wenn sich diese zum Bespiel gerade im Leerlauf befinden. Das Modul was in Abbildung mit T (für Toggle) beschriftet wurde, stellt einen Schalter dar, der abwechselnd Adress-Einheiten aus dem geraden und ungerade Cargo-Ring auswählt. Dieses Modul ermöglicht das zuliefern von Anweisungen unter einem maximalen Durchsatz. Einzelne, dann aber auch längere Cargo Ringe, die die gleichen Anweisungen enthalten, benötigen weitaus länger um die Adressen weiterzugeben. Auf die weiteren Elemente innerhalb der Cargo Units soll hier nicht näher eingegangen werden. FLEETzero hat also zusammen 4 solcher Cargo Rings, wobei ein Dual Cargo Ring die Quelladressen und der andere die Zieladressen enthält. Weil die Dateneinheiten im gleichen Ablauf durch den Trunk laufen, wie die Quelladressen in der Switch Fabric eintreffen, können die jeweiligen Zieladressen sich im Trunk mit ihren zugehörigen Dateneinheiten verbinden.

3.4 Ships

Es wurden bisher acht verschiedene Ships zu reinen Testzwecken erschaffen, welche speziell festgelegte Fähigkeiten anbieten. Zur Darstellung der Funktionen der bisher erschaffenen Schiffe soll Abbildung 3.9 dienen. Wichtig

für das Verständnis ist noch, dass eine Anweisungsquelladresse sich auf den Output und eine Anweisungszieladresse auf den Input eines Ships bezieht. „Data sink“ ist hier ein Beispiel für ein Ship was nur einen Input hat und „constant“ ein Beispiel für ein Ship was nur einen Output hat. Ein Adierer hingegen stellt ein zwei Inputs/einfach Output Ship dar. Die hier vorgestellten Ships sind sehr sehr einfach und es wurden noch keine größeren Gedanken daran verschwendet wie man diese zu komplexen Strukturen erweitern kann.

10

Die „external“I/O Ships empfangen und senden Daten zu externen Pins auf dem Chip. Hier wird das interne Signalprotokoll durch I/O-Schaltkreise in ein vierphasiges request/acknowledgement Interface umgewandelt. Das „data sink“ Ship dient dazu, Daten die dorthin gesendet werden zu löschen. Bei den Inputs als auch Outputs handelt es sich um 8 bit words. Wie man leicht sieht, kann dies bereits durch den Addierer Probleme verursachen. Auf eine Überlaufkontrolle wurde aus Vereinfachungsgründen bislang verzichtet, da man sich noch im Test befindet und die Größe der Inputs genau festlegt.

11

Kapitel 4

Ergebnisse

Spezielle Tests mit dem FLEETzero Chip zeigten einen Durchsatz von circa 1,2 Milliarden Dateneinheiten pro Sekunde(Giga Data Items per Second -GDI/s), was den Chip schneller darstellt, als alle bisherigen synchronen Geräte unter vergleichbaren Grundausstattungen (0,35micron CMOS Technologie). Um dies ins Verhältnis zu setzen betrachten wir einzelne Prozessoren der Pentium Familie in Abbildung 4.1. Mit der Verkleinerung der Transis-

torengröße und der Abstände zwischen den Transistoren auf dem Chip, bekamen aktuelle Prozessoren jedoch immer höhere Geschwindigkeiten, wobei dadurch Vergleiche nur noch mit älteren Prozessoren (wie hier abgebildet) sinnvoll sind. Der GDI/s Durchsatz des FLEETzero Chips, kann meiner Meinung nach, hier mit den MIPS (Million Instructions Per Second) verglichen werden, da er selber ja für jede Dateneinheit die er bewegt genau eine Anweisung, den Move Befehl, geben muss. Natürlich darf man hierbei nicht die Umrechnung von Milliarden in Millionen vergessen. Man sieht das der FLEETzero bis ins Jahr 2001 den vergleichbaren Chips sozusagen überlegen war und erst mit der Einführung noch kleinerer Designgrößen (kleiner als 0.18micron - P4 aufwärts) nicht mehr mithalten konnte. Für einen einzelnen Cargo-Ring wird in den Abbildungen 4.2 und 4.3, der Durchsatz im Verhältnis zur Anzahl der Items und auch der Durchsatz/der Stromverbrauch im Verhältnis zur Eingangsspannung dargstellt. Wie hieraus hervorgeht, liegt ein maximaler Durchsatz von 1,5 GDI/s vor, wenn die Anzahl an Adresselementen um die 22 liegt. Für den Test der in Abbildung 4.3 dargestellt ist,

12

wurde genau diese Anzahl von 22 benutzt, weil diese im vorherigen Test den maximalen Durchsatz erzeugt. Zu sehen ist hier, dass die Cargo Rings in einem breiten Bereich von 1,2V bis 4,8V angelegter Spannung arbeiten und selbst unter maximal angelegter Spannung weniger als 1 Watt an Energie benötigen. Eine weitere Durchsatzbegrenzung des Dual Cargo Rings entsteht

Abbildung 4.3: Durchsatz und Energieverbrauch vs. Spannung

aber durch den begrenzten Durchsatz am Schalter (Toggle).

13

Kapitel 5

Fazit und Ausblick

5.1 Fazit

Der FLEETzero Chip ist das Resultat zehnjähriger Forschung und mehr als 30 vorherigen Experimentalchips. Zum gegenwertigen Zeitpunkt ist der FLEETzero jedoch nicht mehr als ein Spielzeug, da er mit gerade einmal 8bit Words, acht Ships sowie ohne Möglichkeit der Programmverzweigung und ohne Speicher auskommen muss. Er legt aber den Grundstein für eine völlig neue Architektur, welche auf der kommunikationszentralen Sicht aufbaut. Die andauernde Arbeit der Sun Microsystems Laboratories über Hochdurchsatz-Datenbewegung und Steuerungsschaltkreisen hat gezeigt, dass die von ihnen entwickelten Schaltkreise flexibel, robust, zu größeren Komponenten erweiterbar und vor allem, genau wie erwartet, sehr schnell sind. Alle Bausteine, die auf dem FleetZero genutzt werden, können in ungefähr sechs Logikgatterverzögerungen ("gate-delays"á 0,1ns) durchlaufen, was in Relation gesetzt, ungefähr der Geschwindigkeit eines Drei-Inverter-Ringoszillators entspricht. Ein schnelleres Ausführen ist hier kaum vorstellbar. Die bisher erzielte Performance ergibt sich aus einer ganzen Reihe von Faktoren. Vor allem wurde sehr viel Wert darauf gelegt:

• Primitiven-Schaltkreise einfach zu gestalten

• besondere Aufmerksamkeit auf das Erzeugen von Nebenläufigkeit zu legen

• den Vorteil der einheitlichen lokalen Verzögerungen auszunutzen (kein globaler Takt vorhanden)

• den Aufbau der Transistoren unter Zuhilfenahme logischer Anstrengungen betrachten

• den Durchsatz zu erhöhen (auch wenn dadurch die Latenz steigt)

14

Leider wurden im FLEETzero - Projekt auch schon einige Problembereiche bzw Schwachstellen entdeckt.

Eines der Probleme ist, dass die komplette Datenübertragung des verwendeten Netzwerkes über die Hauptleitung (trunk) erfolgen muss, was den Durchsatz des Systems natürlich auf dessen maximalen Durchsatz beschränkt. Erste Lösungsversuche mittels vergrößerter Topologie schienen vielversprechend, verschoben den Flaschenhals jedoch nur Richtung Instruction Fetch Einheit. Ein weiteres Problem ist das der Datenabhängigkeiten. Unter Beachtung dieser käme der komplette Datenfluss zum erliegen, sollten Datenabhängigkeiten vorliegen, was zu sehr großen Latenzen führen würde. Auch ist es bisher ungeklärt, wie komplexe Programme umgesetzt werden, da spezielle Software-Kompiler noch nicht existieren und die ganze Technologien nach Jahrzehnten der Entwicklung immer noch in den Kinderschuhen steckt.

5.2 Ausblick

Nach eigenen Angaben der Schöpfer des FLEETzero blickt man in eine vielversprechende Zukunft. Unter Einsatz modernerer und ausgereifterer Technologien ist es möglich den Durchsatz noch fortlaufend zu steigern, desweiteren existieren vielfältige Einsatzgebiete für asynchrone Prozessoren, vor allem dort wo Prozessoren benötigt werden, die bei geringer Voltzahl arbeiten, wenig Energie verbrauchen und trotzdem sehr schnell sind. Der größte Markt hierfür liegt beispielsweise im Notebook, PDA und Mobiltelefonbereich. Es gibt aber immer noch eine Vielzahl von Problemen zu lösen, bis die neue Technologie ihre Marktreife erlangen wird. Zum einen fehlen neben neuen Kompilern auch ein Verständnis für Daten-abhängige Verzögerungen, zum anderen fehlt es noch an der breiten Akzeptanz. Mit spezialisierten Insellösungen in einem konventionellen Gesamtsystem will man in den nächsten Jahren versuchen dafür eine Basis zu schaffen, auf die sich dann nach und nach aufbauen lässt.

15

Abbildungsverzeichnis

2.1 FLEETzero Chip Kern . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Abstrakter Blick auf FLEETzero . . . . . . . . . . . . . . . .

3.2 Basic Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Modifizierter Branch . . . . . . . . . . . . . . . . . . . . . . . 3.4 Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Simple Switch Network . . . . . . . . . . . . . . . . . . . . . . 3.6 Horn-and-Funnel Netzwerk . . . . . . . . . . . . . . . . . . . 3.7 Switch Fabric Detail . . . . . . . . . . . . . . . . . . . . . . . 3.8 Dual Cargo Rings . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Adress Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1 Vergleich zu Pentium . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Cargo Ring Durchsatz . . . . . . . . . . . . . . . . . . . . . . 13 4.3 Durchsatz und Energieverbrauch vs. Spannung . . . . . . . . 13

16

Literaturverzeichnis

[Sun06] Sun Microsystems Laboratories online-Artikel,“Beating the Clock“, http://research.sun.com/features/async/, 2006

[SML00] William S. Coates, Jon K. Lexau, Ian W. Jones, Scott M. Fairbanks and Ivan E. Sutherland, Sun Microsystems Laboratories, „FleetZero: An Asynchronous Switching Experiment“, 2000

[Suth01] I. Sutherland and S. Fairbanks, „GasP: A Minimal FIFO Control“, Proc. of the Seventh International Symposium on Advanced Research in Asynchronous Circuits and Systems, 2001.

[SML98] William S. Coates, Jon K. Lexau, Ian W. Jones, Scott M. Fairbanks and Ivan E. Sutherland, Sun Microsystems Laboratories, „A FIFO Data Switch Design Experiment“, Proc. of the Fourth International Symposium on Advanced Research in Asynchronous Circuits and Systems, April 1998.

[Suth05] I. Sutherland, „FLEET - A One-Instruction Computer“, Memo der UC Berkeley Computer Science, August 2005.

17