Technische Universität Ilmenau

Fakultät für Informatik und Automatisierung

Fachgebiet Rechnerarchitektur

Hauptseminar zum Thema

Die registerlose Prozessorarchitektur

- die revolutionäre Prozessorarchitektur des FLEETzero -

Bischof, René 33665

Wintersemester 2006/2007

Studiengang Informatik M01

Technische Universität Ilmenau

Betreuer

Dipl.-Inf. Falk Berger

---

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 register-

losen 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 Publik-

ationen (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 Aus-

arbeitung 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 inten-

siven 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än-

ger 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 ne-

ben 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 Da-

ten von einer Quelle zu einem Ziel transportieren und diese während diesem

Transport weiter verarbeiten (addieren,negieren, usw.). Das ganze wäre je-

doch sinnlos wenn die Datenbewegung hierbei langsam wäre. Um den Durch-

satz 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är-

kung 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 Steuer-

schaltkreise ist dadurch zu erklären, dass die zentrale Taktgebung wegfällt

und somit die Geschwindigkeit des Gesamtsystems nicht mehr von der Ge-

schwindigkeit 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äte-

ren Entwicklungsstufen unter anderem auch als ,,Asynchronous Interlocked

Pipelined CMOS"-Technologie benannt.

In der Zeit zwischen 1998 und 1999 entstand der Experimentalchip FLEET-

zero, welcher für den ersten nichttrivialen Einsatz der GasP Steuerschalt-

kreise steht und der als Kern dieser Ausarbeitung näher vorgestellt werden

soll.

Abbildung 2.1: FLEETzero Chip Kern

4

---

Kapitel 3

FLEETzero Chip

3.1

Grundverständnis

Um einen noch nicht konkreten Einblick in die Grundstruktur der neuen Ar-

chitektur zu bekommen, soll als erstes Abbildung 3.1 dienen. An dieser Stelle

Abbildung 3.1: Abstrakter Blick auf FLEETzero

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 steu-

ert jede Dateneinheit vom Input zu einem der beiden Outputs, je nachdem

was durch die Steuereinheit vorgeschrieben wird. Die Steuerung der Da-

tenbewegung hierbei, erfolgt durch ein asynchrones FirstInFirstOut(FIFO)-

Protokoll. Die Abbildung 3.2 verdeutlich diese einfache Primitive. Eine Wei-

terentwicklung brachte jedoch ein modifiziertes Branch-Modul (siehe Abbil-

dung 3.3) hervor, welches nun hauptsächlich benutzt wird. Dieser vereinigt

den Daten- und Orderinput zu einem einzigen Kanal, wärend er am Out-

put 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 Da-

teneinheit 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.

Abbildung 3.2: Basic Branch

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 ein-

zelnen 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

---

Abbildung 3.3: Modifizierter Branch

Abbildung 3.4: Merge

Abbildung 3.5: Simple Switch Network

später. Auf der rechten Seite befindet sich das Merge Modul, welches mit Hil-

fe 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ög-

liche Topologien für solche Netzwerke gibt es viele, für die FLEETzero Switch

7

---

Abbildung 3.6: Horn-and-Funnel Netzwerk

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 ,,destinati-

on 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 ent-

scheidet 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. Ne-

benbei, 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 Adress-

bit, 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 über-

wacht wird. Liegt hier im Order FIFO Input das zweite Adressbit an, wird

die Dateneinheit aus CC hindurchgeleitet. Hieraus erkennt man die Bedeu-

tung 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

---

Abbildung 3.7: Switch Fabric Detail

3.3

Instruction Store

Die Befehle des FLEETzero werden in der sogenannten Dual Cargo Unit ge-

halten. 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-

Abbildung 3.8: Dual Cargo Rings

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 Quel-

ladressen 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 Funk-

tionen der bisher erschaffenen Schiffe soll Abbildung 3.9 dienen. Wichtig

Abbildung 3.9: Adress Map

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 vorgestell-

ten 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 ,,da-

ta 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 Ge-

räte unter vergleichbaren Grundausstattungen (0,35micron CMOS Techno-

logie). Um dies ins Verhältnis zu setzen betrachten wir einzelne Prozessoren

der Pentium Familie in Abbildung 4.1. Mit der Verkleinerung der Transis-

Abbildung 4.1: Vergleich zu Pentium

torengröße und der Abstände zwischen den Transistoren auf dem Chip, be-

kamen 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 Mei-

nung nach, hier mit den MIPS (Million Instructions Per Second) verglichen

werden, da er selber ja für jede Dateneinheit die er bewegt genau eine An-

weisung, 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ält-

nis 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 Adressele-

menten um die 22 liegt. Für den Test der in Abbildung 4.3 dargestellt ist,

12

---

Abbildung 4.2: Cargo Ring Durchsatz

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 be-

nö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 8-

bit 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 Hoch-

durchsatz-Datenbewegung und Steuerungsschaltkreisen hat gezeigt, dass die

von ihnen entwickelten Schaltkreise flexibel, robust, zu größeren Komponen-

ten 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 Relati-

on 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 Problem-

bereiche bzw Schwachstellen entdeckt.

Eines der Probleme ist, dass die komplette Datenübertragung des ver-

wendeten 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ängig-

keiten vorliegen, was zu sehr großen Latenzen führen würde.

Auch ist es bisher ungeklärt, wie komplexe Programme umgesetzt wer-

den, da spezielle Software-Kompiler noch nicht existieren und die ganze Tech-

nologien nach Jahrzehnten der Entwicklung immer noch in den Kinderschu-

hen steckt.

5.2

Ausblick

Nach eigenen Angaben der Schöpfer des FLEETzero blickt man in eine viel-

versprechende Zukunft. Unter Einsatz modernerer und ausgereifterer Tech-

nologien ist es möglich den Durchsatz noch fortlaufend zu steigern, desweite-

ren existieren vielfältige Einsatzgebiete für asynchrone Prozessoren, vor allem

dort wo Prozessoren benötigt werden, die bei geringer Voltzahl arbeiten, we-

nig 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 Insel-

lö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 .

5

3.2

Basic Branch .

6

3.3

Modifizierter Branch .

7

3.4

Merge .

7

3.5

Simple Switch Network .

7

3.6

Horn-and-Funnel Netzwerk

.

8

3.7

Switch Fabric Detail .

9

3.8

Dual Cargo Rings .

9

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 Symposi-

um 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

---