RST - Labor WS 2004/05

Transkript

1 Asynchrone Prozessoren (Die taktlose Welt) WS 2004/05 Schaumann, Kai Tjarks, Gunnar 21. Februar 2005

2 Inhaltsverzeichnis 1 Einleitung 2 2 Einführung in die asynchrone Welt Umriss der synchronen Welt Grenzen synchroner Schaltungen Umriss der asynchronen Welt Probleme asynchroner Schaltungen Asynchrone Technologien Micropipelines Delay Varianten Bounded delay model Current Sensing Completion Detection (CSCD) Dual rail Codierung Three rail Codierung NULL Convention Logic Das Konzept Implementierung Ein asynchrones Register mit NCL Realisierungen von theshold gates Asynchrone Projekte PsalM - Projektseminar asynchron laufender Prozessoren DEP-CPU Asynchrone Umsetzung der DEP-CPU Mikro-Prozessor Ergebnisse Asynchrone Prozessoren ASPIDA - Asynchronus open-source Processor Ip of the DLX Architecture DLX-Architektur Asynchrone Umsetzung von DLX Desynchronizing der DLX Amulet Fazit 26 A Glossar Februar 2005 Seite 1

3 Kapitel 1 Einleitung Nebenstehende Abbildung 1.1 zeigt die Entwicklung der asynchronen Prozessoren seit den Tagen der ersten Prozessoren überhaupt. Interessant hierbei ist, daß es immer asynchrone Entwicklungen gab, sie sich aber leider nie auf dem Markt haben durchsetzen können. Grosse Firmen wie Philips oder Intel sind ebenso an der Entwicklung beteiligt wie Pioniere der computerisierten Welt wie z.b. Alan Turing oder Ivan Sutherland. Dies geht soweit, daß heutzutage in modernen Intel-Prozessoren sogar asynchrone Komponenten integriert sind. In dieser Ausarbeitung wollen wir eine Einführung in asynchrone Technologien geben sowie auch einige Projekte bzw. Prozessoren vorstellen. Wir beginnen damit, die Unterschiede zwischen der asynchronen und synchronen Welt aufzuzeigen und die jeweiligen Vor- bzw. Nachteile darzulegen. Dieses schliesst mit einem Vergleich der beiden Welten ab. Im Anschluss gehen wir tiefer auf die dahinter stehenden Technologien wie Micropipelines und Null Convention Logic ein. Wir werden zeigen, wie diese Technologien arbeiten, welche Vorteile sie bieten und geben kurze Stichworte, wo sie auch tatsächlich eingesetzt werden. Im zweiten Abschnitt des Dokuments stellen wir verschiedene Forschungsprojekte vor, die sich mit asynchronen Prozessoren beschäftigen. Einen genaueren Blick werfen wir hierbei auf den Amulet Prozessor sowie eine Neuentwicklung aus dem Jahr 2003, den ASPIDA-Prozessor. Er steht als open-source Hardware zur Verfügung und wurde erstmals auf der ASYNC2004 in Griechenland vorgestellt. Den Abschluss bildet ein Fazit, welche Erkenntnisse wir aus den Untersuchungen gewonnen haben und wo sich eventuell weitere Nachforschungen lohnen. Abbildung 1.1: Entwicklung der asynchronen Prozessoren Quelle: /async/misc/technologyreview oct html 21. Februar 2005 Seite 2

4 Kapitel 2 Einführung in die asynchrone Welt 2.1 Umriss der synchronen Welt Bei heute übliche Prozessoren signalisiert ein zentraler Takt, die sog. clock, wann ein Ergebnis eines Logikblocks in das Ergebnisregister geschrieben wird und somit den Nachfolgeblöcken zur Verfügung steht. (siehe Abbildung 2.1) Der Takt muss sich nach dem langsamsten Logikblock richten, damit dieser sein Ergebnis zwischen zwei Taktflanken vollständig berechnen kann. (siehe auch [Pur02] - Vorlesung Grundlagen Digitaltechnik) Abbildung 2.1: Logikblöcke sind in Taktgesteuerten Prozessoren von einem Eingangs- und einem Ausgangsregister umgeben. Referenz: [Ble99] Grenzen synchroner Schaltungen Die Taktfrequenz ist heute vielfach eine Maßzahl für die Leistung von Microprozessoren geworden. Soll es schneller gehen, verkleinert man die Chip-Struktur, optimiert den chipinternen Aufbau oder verbessert den Herstellungsprozess. Dennoch sind diesem Vorgehen Grenzen gesetzt, wirft man einen Blick in die Zukunft. Jahr Strukturgröße(nm) Packungsdichte 50 x x 106 Transistoren / cm2 500 x x 106 Chipfläche (cm2) Gatterlaufzeit Taktfrequenz (GHz) Februar 2005 Seite 3

5 Quelle: [Ble99] Signale legen auf Leitungen ca. 1 mm in 100 ps zurück. Um einen Chip mit 30 mm Seitenlänge zu durchqueren, bräuchten diese bei 3 GHz also 10 Takte. Bei einer Taktfrequenz von 10 GHz wären es schon 27 Taktzyklen. Daß solche Chips mit einem zentralen Taktgeber nicht mehr betrieben werden können, ist wohl offensichtlich (siehe Artikel [Ble99]). Der Systemtakt muß sich nach der langsamsten Komponente richten und bremst damit schnellere Komponenten aus. Weiters schalten alle Komponenten im Rythmus des Takts, ob sie etwas sinnvolles tun oder nicht, dies wiederum erhöht die Verlustleitung, die in Form von Wärme zusammen mit den immer kleineren Strukturen für einen erhöhten Widerstand sorgt, welcher wiederum die Verlustleitung erhöht. Zu allem Übel führen die immer höheren Taktfrequenzen zu einer verstärkten hochfrequenten Abstrahlung, welche andere technische Systeme in ihren Funktionen behindern kann. Ein großes Problem liegt auch im Design heutiger Prozessoren. So dauert die Entwicklung eines modernen Prozessors circa 3 Jahre. Da allein durch die Verbesserung der Halbleitertechnik schon eine Erhöhung der Taktrate um den Faktor 2 in 18 Monaten erfolgt (Mooresches Gesetz), muss um einen schnelleren Chip zu entwickeln, zu Beginn des Designs eine Architektur angestrebt werden, die mit sehr viel höheren Taktraten arbeiten kann, ohne dass etwas nachträglich am Design geändert werden muss. Nicht unbedingt eine leichte Aufgabe und oft müssen von den angestrebten Zielen einige Abstriche bei den geplanten Features gemacht werden. 2.2 Umriss der asynchronen Welt Asynchrone Schaltungen synchronisieren sich selbst mit ihrer Umgebung und erleichtern somit im Normalfall den Entwurf eines Prozessors, da sich die Funktionsüberprüfungen auf einzelne Teile beschränken, die dann ohne globale Signalpfade o.ä. berücksichtigen zu müssen, aneinandergefügt werden können. Sie kommen ohne zentralen Takt aus und synchronisieren die Weitergabe der Ergebnisse an die Folgeblöcke selbständig. Durch Handshake-Signale signalisieren sie ihren momentanen Zustand. Mit einem Request (REQ) signalisiert ein Logikblock, dass er neue Daten ermittelt hat und die nächste Stufe diese abholen soll. Diese nimmt die Daten erst dann an, wenn sie ihr eigenes Ergebnis an die darauffolgende Komponente weitergegeben hat. Nach der Annahme der Daten berechnet die Komponente das Ergebnis und signalisiert danach durch Acknowledge (ACK) an den Vorgänger, dass er neue Daten schicken darf. Gleichzeitig unterrichtet sie ihren Nachfolger wiederum mit einem Request über die fertigen Daten. Aufgrund dieser Struktur laufen Datenwellen durch das asynchrone System. (siehe Artikel [Ble99]) Abbildung 2.2: Jeder Logikblock signalisiert über Handshake-Leitungen seinen momentanen Zustand. Referenz: [Ble99] Probleme asynchroner Schaltungen Das Hauptproblem bei Schaltungen ohne Takt ist, dass Ergebnisse auf verschiedenen Leitungen unterschiedlich schnell fertig werden können und somit für eine gewisse Zeit falsche Signale an den Eingängen der Nachfolgestufe anliegen können, diese aber nicht weiß, ob sie die Daten schon übernehmen kann, oder noch warten muss. Weiter ist nicht bekannt, wie lange ein Ergebnis gehalten werden muss, bevor weitergerechnet werden kann, also wann die Nachfolgestufe die Daten übernommen hat. Bei synchronen Schaltungen übernimmt diese Funktion der zentrale Takt, ist kein solcher vorhanden, müssen sich die Funktionsblöcke selbst synchronisieren. Aber woher weiß ein Logikblock, wann er fertig ist? An dieser Frage haben sich etliche Forscher und 21. Februar 2005 Seite 4

6 Ingenieure die Köpfe heiß gedacht. Jeder Logikblock ist aus Gattern aufgebaut, die nach Anlegen neuer Daten eine gewisse Zeit benötigen, um ihr Ergebnis an den Ausgang zu schalten. Zudem arbeiten alle Gatter unterschiedlich schnell. Es können daher kurzfristige ungültige Bitmuster am Ausgang erscheinen. Grob lassen sich alle Lösungsansätze zur Realisierung asynchroner Schaltungen in zwei Gruppen unterteilen: In Lösungen, in denen die eigentliche Funktion - also im Wesentlichen der Datenpfad - unverändert in konventioneller Logik ausgeführt und durch eine spezielle Logik zum Synchronisieren der einzelnen Funktionsblöcke ergänzt wird. Und in Lösungen, in denen die timing Informationen in die Logik einbezogen wird. (siehe NULL Convention Logic 3.4) Die wichtigsten Vertreter der ersten Gruppe sind die Micropipelines (siehe Kapitel 3.1) von Ivan E. Sutherland [Sut89]. Für diese Technik existieren auch die meisten praktischen Realisierungen bis hin zu vertriebsreifen Prozessoren. Wenig Verbreitung finden Ideen wie Laufzeitabschätzungen oder Verfahren, die das Ergebnis einer Berechnung durch elektrotechnische Messungen feststellen (CSCD, current sensing completetion detection). Für die zweite Gruppe gibt es verschiedene Verfahren die alle auf dem selben Prinzip basieren, eine mehrwertige (meist dreiwertige) Logik einzuführen, deren Werte die Information über die Vollständigkeit der Information mit codiert haben. Sie unterscheiden sich nur durch die verschiedenen technischen Realisierungen im Bezug auf Codierung in binärer Logik und Schaltungsimplementation. 1 1 Quelle [Mar00] 21. Februar 2005 Seite 5

7 Kapitel 3 Asynchrone Technologien 3.1 Micropipelines Ivan E. Sutherland beschrieb in den Sechzigern ein asynchrones Design für einen Graphikprozessor, der speziell das Problem des clippings in der Computergraphik mittels einer asynchronen, elastischen Pipeline implementierte, elastisch bedeutet hierbei, dass die Steuersignale der Pipeline, durch eine Event-Logik gesteuert wurden und nicht durch ein Taktsignal. Später hat er sein Konzept zu den sog. micropipelines verallgemeinert und unter [Sut89] veröffentlicht. Weitere wichtige Forschungen in diesem Bereich wurden von Charles Molnar an der Washington University in den Siebzigern durchgeführt. Die Micropipelines haben herkömmliche instruction pipelines als Vorbild. Wie bei diesen werden Operationen parallel in den einzelnen Pipelinestufen ausgeführt und die Ergebnisse an die nächste Stufe weitergeben. Im Unterschied zu herkömmlichen Pipelines werden in Micropipelines viel kleine logische Einheiten verarbeitet. Der wesentliche Unterschied ist jedoch, dass Micropipelinesstufen ihre nachfolgenden Stufen ihre Ergebnisse erst dann weitergeben, wenn diese signalisieren, dass sie dazu bereit sind. Das Kernstück der Micropipelines ist ein neues Schaltgatter, das Muller-C-Gate. Es hat zwei Eingänge A und B und einen Ausgang Q. Falls A und B 1 sind, schaltet auch Q auf 1. Wenn an beiden Eingängen 0 anliegt, kommt 0 aus dem Gatter. Haben die Eingänge unterschiedliche Pegel, behält Q seinen vorigen Pegel. Damit ähnelt das Muller-C-Gate einem Flipflop, und tatsächlich kann man ein RS-Flipflop und zwei AND-Gatter entsprechend zusammenschalten. 1 1 Quelle [Mar00] 21. Februar 2005 Seite 6

8 Abbildung 3.1: Das Muller-C-Gate verhält sich wie ein spezielles Flipflop, es ist das Kernstück der Micropipelines Quelle [Mar00] Aus Muller-C-Gates und Invertern lässt sich ein FIFO Speicher für Impulse aufbauen. Diese Kontrollstruktur verwaltet nur die Impulse der Micropipeline. Wenn jetzt Register, Logik und die verzögernden Bounded-delay-Module (siehe Kapitel ) hinzukommen, lässt sich eine Micropipeline aufbauen. Abbildung 3.2: Schematischer Aufbau einer Micropipeline. Das System arbeitet asynchron und organisiert sein Timing selbst. Quelle [Mar00] Die dünnen Linien stellen die Kontrollpfade dar. Die Datenpfade (dicke Linien) verbinden wie bei einer Prozessorpipeline die Register zwischen den Stufen und die eigentliche Logik. Angenommen die Pipeline sei (z.b. nach einem reset) leer und alle Kontrollpfade auf low. Dann verhält sich die Pipeline, als hätte sie keine Register, die Daten werden ohne Verzögerung durch die Logik geschleust. Kommt nun ein Signal auf R(in), das heißt, es liegen neue gültige Daten auf D(in), schaltet das erste Muller-C-Gate und das erste Register speichert den Wert auf D(in). Anschließend wird auf A(in) die Übernahme quittiert und über eine Leitung mit entsprechenden Delay ein Request R(1) an die folgede Stufe gesendet. Der übernommene Wert läuft nun durch die Logik. Hierbei ist wichtig, dass die Laufzeit durch die Logik kleiner ist als die Laufzeit des delay Elements. Denn erreicht das Signal R(1) das Muller-C-Gate, schaltet dieses und friert den von der Logik kommenden Wert D(1) ein. 2 2 Quelle [Mar00] 21. Februar 2005 Seite 7

9 Abbildung 3.3: Decoder mit vier Pipelinestufen. Quelle [Mar00] Abbildung 3.3 zeigt eine vierstufige Implementierung eines (1 von 8)-Bit-Decoders als Micropipeline. Die Kriterien für die Anzahl der Pipelinestufen sind ähnlich denen bei herkömmlichen Prozessorpipelines. Viele Stufen erlauben einen höheren throughput bei hohem Bauteilaufwand, weniger Stufen vermindern u.u. die latency, da weniger Register durchlaufen werden müssen Delay Varianten Hier stellen wir Varianten der Delay-Elemente der Micropipeline vor. Sie werden benötigt, um das ACK-Signal an die folgende Stufe zu senden Bounded delay model Das bounded delay model, auch als delay insensitve model bekannt, nimmt für gewisse Logikmodule konstante Obergrenzen für die Durchlaufzeit an. Aufgrund dieser Abschätzung wird dann eine Schaltung entworfen, die nach einem request diese Zeitdauer abwartet und dann das acknowledge Signal sendet. Diese Laufzeit muss für den worst-case ausgelegt sein, überschreiten Parameter wie hohe Temperatur oder niedrige Spannung diesen, funktioniert die Schaltung u.u. nicht mehr. ([Ble99]) Current Sensing Completion Detection (CSCD) Der CSCD-Ansatz versucht, über die Stromaufnahme von Gattern festzustellen, ob diese eine Operation bereits beendet haben. Bei der CMOS-Technologie ist die Stromaufnahme beim Schalten größer als im stabilen Zustand. Wird diese Stromaufnahme gemessen, kann eine Aussage über die Beendigung eines Schaltvorganges gemacht werden. Meist wird diese Methode mit einem Verzögerungselement für den worst-case Fall nach dem bounded delay model (siehe ) kombiniert, damit im Fall, dass die Beendigung nicht erkant wurde, weitergearbeitet werden kann. ([Ble99]) 4 3 Quelle [Mar00] 4 Quelle [Mar00] 21. Februar 2005 Seite 8

10 3.2 Dual rail Codierung Beim Dual rail encoding werden für jede logische Datenleitung zwei Leitungen verwendet. Es wird neben den Zuständen 0 und 1 - die als defined bezeichnet werden sollen - ein dritter logischer Zustand - undefined oder intermediate - eingeführt. Codiert wird diese dreiwertige Logik mittels zwei binären Leitungen. Dabei wird folgende Abbildung verwendet: U -> > > 01 Der Wert 11 ist nicht zulässig und dürfte in einer korrekten Schaltung auch nicht auftreten. Entscheidend ist, dass bei einem Übergang von 0 nach 1 (wenn man eine genügend feine Auflösung im Zeitbereich betrachtet) immer der Zustand U passiert wird. Eine Schaltung soll an ihren Ausgängen erst defined werden, wenn alle ihre Eingänge defined sind. Ebenso sollen ihre Ausgänge erst undefined werden, wenn alle Eingänge undefined sind. Somit ergibt sich folgender Ablauf: 1. Alle Eingänge sind undefined. 2. Alle Ausgänge werden undefined. 3. Einige Eingänge werden defined. 4. Alle Ausgänge bleiben undefined. 5. Alle Eingänge sind jetzt defined. 6. Alle Ausgänge werden defined. 7. Einige Eingänge werden undefined. 8. Alle Ausgänge bleiben defined. 9. weiter mit 1. Wenn alle Teilschaltungen sich nach diesem Muster verhalten, synchronisieren sie sich dadurch selbst und bilden ein self timed system Three rail Codierung Will man asynchrone Logik ohne Elemente mit internem Speicher oder Feedback (wie z.b. das Muller- C-Gate) sondern ganz normale boolesche Gatter, die ihr timing selbst bestimmen, braucht man eine dreiwertige Logik (siehe [SM99]). Dabei muss folgende Codierung (oder Permutationen davon) verwendet werden: 0 -> > 110 Unter Verwendung der Gatter aus Abbildung 3.4 kann ganz normale boolesche Logik weiter verwendet werden. Da diese Gatter überdimensional viele Leitungen und Gatter brauchen, ist dieser Ansatz wohl eher theoretisch. 6 5 Quelle [Mar00] 6 Quelle [Mar00] 21. Februar 2005 Seite 9

11 Abbildung 3.4: AND, OR und NOT in Three rail Codierung. Quelle [KMF97] 3.4 NULL Convention Logic Die NULL Convention Logic (NCL) [KMF97] hat ihre Wurzeln im invocation model of process expression, einem konzeptionellen Modell zur Beschreibung von Prozessen. Mit diesem Modell werden Prozesse modelliert, die sich um chemische, physikalische, natürliche oder künstlichen Vorgänge kümmern. Computer stellen für dieses Modell also nur eine von mehreren Anwendungsgebieten dar. Die NCL erweitert die Boolesche Logik um ein bzw. zwei Symbole. Im Gegensatz zum dual rail encoding [Ble99] wird das Konzept auf kleinster logischer Ebene angewandt. Dabei werden neue Elementargatter die sog. treshold gates deefiniert und mit diesen größere Bauteile konstruiert Das Konzept Bei der Booleschen Logik sind die beiden Zustände true und false mutual exclusive. Egal wie die Zustände interpretiert werden, repräsentiert diese immer Daten. Es existeren keine Symbole für Nicht- Daten oder Kontrolle im Wertebereich der Boole schen Logik. Nach dem invocation model of process expression muss ein neuer Wert hinzugefügt werden, welcher in der NCL mit NULL bezeichnet wird. Die Werte true und false werden data values, der Wert NULL non-data value genannt. Die sich dadurch ergebenden Wertetabellen für die Boole schen Operatoren AND, OR und NOT sehen so aus: Quelle [KMF97] Die Bedingungen sind somit die gleichen wie beim dual rail encoding im Bezug auf den intermediate Wert. Erst wenn sich alle Eingänge geändert haben, ändert sich auch der Ausgang. Ausgehend von einem Netz, in dem alle Leitungen auf NULL sind, breiten sich die gültigen Inputwerte wie eine Welle bis zu den Ausgängen aus. Durch einfaches Überwachen der Ausgänge läßt sich leicht feststellen, wann die Berechnung abgeschlossen ist, nämlich dann, wenn alle Ausgangsleitungen von NULL verschieden sind. Da, um eine neue Berechnung beginnen zu können, alle Leitungen wieder auf NULL sein müssen, muss nach Ende der Berechnung eine zweite Welle das System wieder komplett auf NULL setzen. Dies kann die oben definierte Algebra nicht erfüllen. Zur Lösung dieses Problems gibt es zwei Möglichkeiten: 1. Es wird ein vierter Wert intermediate eingeführt. Dadurch ergeben sich folgende Wertetabellen: 7 Quelle [Mar00] 21. Februar 2005 Seite 10

12 Quelle [KMF97] Damit ist es möglich, beide Arten von Wellen durch die Schaltung laufen zu lassen. Der Beobachter am Ende wartet auf DATA oder NULL und ignoriert alle intermediate-werte. 2. Jedes Gatter hat eine Rückführung, d.h. sein Ausgang wird als zusätzlicher Eingang rückgeführt. Das erlaubt dem Gatter, sich seinen Zustand zu merken und nur dann von NULL zu DATA zu wechseln, wenn alle Eingänge DATA sind, aber bei DATA zu bleiben, wenn ein Eigang NULL wird. Andererseits wechselt das Gatter von DATA zu NULL, wenn alle Eingänge NULL sind und bleibt dabei, auch wenn sich ein Eingang zu DATA ändert. Abbildung 3.5: Gatter mit Rückführung (Feedback). Quelle [KMF97] Die erste Lösung ist total delay insensitive, das heißt die Verzögerung ist im Code der Daten-Signale enthalten und kann damit keine ungültigen Signale erzeugen, die zweite nicht ganz. Sollte ein Feedback langsamer sein als eine ganze Wellenfront, würde dieser Ansatz nicht funktionieren. Da dies aber im Normalfall nicht auftritt, die Laufzeit durch das gesamte Gatter ist um vieles länger als ein einfaches Feedback, ist diese Lösung effectively delay insensitive, soll heißen dass ungültige Signale auftreten können, diese aber im Normalfall nicht auftretten Implementierung Da weder eine drei- noch vierwertige Logik existiert, muss diese auf zweiwertige Logik abgebildet werden. Da der Zustand low dem Wert NULL zugeordnet wird, bleibt nur ein Zustand high für DATA übrig. Mit mehreren Leitungen lassen sich aber auch verschiedene Werte kodieren. Da in so einer Gruppe nur eine Leitung auf DATA sein darf, nennt man so eine Gruppe auch mutually exclusive assertation group. Die Größe einer solchen Gruppe kann beliebig groß sein, so könnte man z.b eine Dezimalziffer mit 10 Leitungen kodieren. Hat die Gruppe nur zwei Leitungen (wie es bei der Feedback-Lösung der Fall ist) ist das Ergebnis das Gleiche wie beim dual rail encoding: N -> 00 F -> 10 T -> 01 Der Unterschied besteht darin, dass das dual rail encoding nur ein Protokoll zwischen den Schaltungen ist, bei der NULL-Convention-Logic ist diese Kodierung Teil der Logik selbst. Da bei der NCL nur ein Datenwert existiert, ist die einzige Funktion, die ein Gatter haben kann, zu zählen, wieviele Eingänge auf Data sind. Ein Gatter, das diese Funktion erfüllt wird dicrete threshold gate genannt. 8 Quelle [Mar00] 21. Februar 2005 Seite 11

13 Abbildung 3.6: Ein 5 input threshold 3 gate. Quelle [KMF97] Ein solches threshold n gate ist genau dann DATA, wenn mehr als n Eingänge auf DATA sind, ansonsten NULL. Wie sich leicht nachprüfen läßt, sind das AND oder OR Gatter Spezialfälle dieses Gatters (2 input threshold 2 gate bzw. 2 input threshold 1 gate). Als Beispiel zeigt Abbildung 3.7 nun einen Halbaddierer sowohl in konventioneller als auch in NULL- Convention-Logic. Mit diesem Gatter läßt sich leicht eine Schaltung bauen, die zwar DATA-Wellen richtig verarbeiten kann, aber wiederum keine NULL-Wellen. Die Anwendung der Lösungsansätze aus Kapitel führt zu folgenden Möglichkeiten: Abbildung 3.7: Ein Halbaddierer mit Wahrheitstablle, in boolescher und NULL-Convention-Logic. Quelle [KMF97] 1. Durch die Einführung des vierten Wertes bei der intermediate-lösung wird folgende Kodierung vorgenommen: enc DATA -> DATA, DATA enc INTERMEDIATE -> DATA, NULL enc INTERMEDIATE -> NULL, DATA enc NULL -> NULL, NULL Diese Kodierung ist eine Ebene über den mutually exclusive assertation groups und somit braucht jeder Wert vier Leitungen. (z.b.: 0 -> (enc DATA, enc NULL) -> ((DATA, DATA), (NULL, NULL))). Auch die speziellen threshold gates für diese Implementierung braucht viele Leitungen und Gatter [KMF97] und daher ist diese Lösung eher uninteressant. Sie soll daher nicht weiter behandelt werden. 2. Jedes threshold gate mit dem threshold Wert n wird mit einem Feedback vom Gewicht n-1 versehen. Abbildung 3.8 zeigt ein Beispiel und das Symbol für ein threshold gate mit Feedback. 21. Februar 2005 Seite 12

14 Abbildung 3.8: Ein threshold gate mit feedback. Quelle [KMF97] Dieses Gate wird erst DATA, wenn n Eingänge DATA sind, aber auch erst NULL, wenn alle Eingänge NULL sind. Das Muller-C Gate ist übrigens ein Spezialfall dieses Gates Ein asynchrones Register mit NCL Ein asynchrones Register muß folgende Aufgaben erfüllen: Die Fertigstellung einer DATA/NULL Welle erkennen. Dem Vorgänger melden, daß die DATA/NULL Welle fertig ist. Wenn der Nachfolger meldet, daß eine DATA/NULL Welle angekommen ist, die nächste NULL/DATA Welle starten. Abbildung 3.9: Blockbild eines asynchronen Registers. Quelle [KMF97] Das hierzu gehörende Blockbild ist in Abbildung 3.9 und eine einfache Implementierung in Abbildung 3.10 zu sehen. Angenommen, es wurde gerade eine NULL-Welle durch die folgende Schaltung geschickt. Meldet nun das nächste Register die Vervollständigung des Durchlaufs, wird die acknowledge Leitung von Nachfolger auf DATA gesetzt (durch die Negation) und daher können anliegende DATA-Werte das Register passieren. Erst wenn alle vier Gruppen auf DATA sind, schaltet das threshold 4 gate und die Leitung zum Vorgängerregister wird auf NULL gesetzt. Sind nun alle Werte durch die Logik gewandert und am nächsten Register angekommen und ist dieses bereit, liefert es eine NULL auf der acknowledge Leitung und dieses Register ist nun bereit, die NULL Welle passieren zu lassen. Nach diesem Schema können nun wieder Register und Logik zu einer Pipeline kombiniert werden Quelle [Mar00] 10 Quelle [Mar00] 21. Februar 2005 Seite 13

15 Abbildung 3.10: Ein asynchrones NCL Register. Quelle [KMF97] Realisierungen von theshold gates Die Effzienz der NCL steht und fällt mit dem Aufbau der threshold gates mit Feedback. In [KMF97] finden sich Anleitungen für die Implementierung in statischer, semi-statischer und dynamischer CMOS-Technologie. 11 Abbildung 3.11: Konzeptioneller Aufbau eines threshold gates mit Feedback in statischer CMOS- Technologie. Die einzelnen Blöcke enthalten die Bedingungen, bei denen das Gatter zu NULL bzw. DATA wird und deren Komplemente Quelle [GES] 11 Quelle [Mar00] 21. Februar 2005 Seite 14

16 Kapitel 4 Asynchrone Projekte 4.1 PsalM - Projektseminar asynchron laufender Prozessoren Das PsalM ist ein an der Universität von Bielefeld verfolgter Ansatz, einen asynchronen Microprozessor zu implementieren; eine Ausarbeitung hierzu findet sich unter [BDH + 01]. Die Ansätze, die dort verfolgt wurden, sollen an dieser Stelle zusammengefasst werden. Ziel des Projektseminars war es, eine asynchrone Umsetzung des wohl bekannten Microcontrollers 6502 (siehe z.b. [Kup04]) zu erzeugen, welche auf einem handelsüblichen FPGA der Firma XILINX ( aufsetzt. Im ersten Schritt sollte jedoch ein den Beteiligten schon aus dem Grundstudium bekannter CPU-Typ asynchron implementiert werden. Die DEP-CPU (siehe Anhang A Glossar sowie 4.1.1). Anhand dieser CPU sollten asynchrone Entwurfstrategien im kleinen Rahmen getestet werden, um anfängliche Probleme für die Entwicklung des 6502 auszuschliessen. Vor der Umsetzung der CPU auf asynchronen Betrieb wurden die verschiedenen Möglichkeiten erörtert. Zur Auswahl standen hier zwei, erstens eine Umsetzung mittels des Schematic Editors der Firma Xilinx. Zweite Möglichkeit war der Entwurf mittels der Hardwarebeschreibungssprache VHDL (Näheres zu VHDL z.b. unter [RS03]). Da klar war, dass die Umsetzung mittels eines grafischen Toolkits wie dem Schematic Editor relativ aufwendig und wenig übersichtlich werden würde, entschied man sich für eine Implementierung in VHDL. Ein weiterer Grund war, dass man sich vorhandene VHDL-Codesegmente zu nutze machen wollte und dies nur bei Entwicklung in VHDL möglich ist. Die Entwicklung der DEP-CPU wie auch der asynchronen Variante des 6502 erfolgten auf durch die Universität zur Verfügung gestellten PCI-Karten, auf denen je ein FPGA eingesetzt wurde. Zur Anwendung kamen die beiden Typen XC4062XLT und XC4085XLA der Firma Xilinx. Die Karten werden unter dem Namen HOT2-XL von der Firma Virtual Computer Corporation ( vertrieben DEP-CPU Eine genaue Beschreibung der DEP-CPU findet sich bereits unter [BDH + 01], daher soll hier auf eine detaillierte Beschreibung verzichtet werden und auf das Kapitel 3 der genannten Ausarbeitung verwiesen werden. Wir werden uns im Folgenden auf diese Ausarbeitung beziehen. Eine Übersicht über die CPU soll jedoch den Einstieg erleichtern. Die DEP-CPU ist eine relativ einfach aufgebaute 8-Bit CPU, die nur zwei Addressierungsarten kennt. Absolute (ABS): Der Operand eines Befehls stellt eine Adresse im Speicher dar. Immediate (IMM): Der Operand eines Befehls stellt direkt den Wert dar. Die CPU ist in der Lage, einfache Bitoperationen auf dem Accu auszuführen. Hierzu zählen die logischen Grundfunktionen UND, OR und XOR. Diese Operationen können jeweils mit beiden oben genannten Addressierungsarten durchgeführt werden. Des weiteren sind einfache Load und Store Befehle möglich so z.b. das Speichern des aktuellen Wertes im Akku an die Adresse, die im Operanden 21. Februar 2005 Seite 15

17 übergeben wird. Der genaue Aufbau eines Befehls ist leider aus den uns vorliegenden Unterlagen nicht ersichtlich. Eine Übersicht über das Instruction Set liefern die folgenden Tabellen: Befehl OpCode OpCode Beschreibung IMM ABS LDA Laden des Akku mit dem Operanden ADD Addieren des Operanden zum Akku OR 4A 42 Bitweises ODER von Akku und Operand SBC 4B 43 Subtrahieren des Operanden (und des Carry- Bits) vom Akku XOR 4C 44 Bitweises exklusiv-oder von Akku und Operand ADC 4D 45 Addieren den Operanden und des Carry-Bits zum Akku AND 4E 46 Bitweises UND von Akku und Operand SETF 4F 47 Setzen des Carry- und Zero- Flags entsprechend Bit 6 und 7 des Operanden Tabelle 4.1: Adressmodiabhängige Befehle Befehl OpCode Beschreibung STA 80 Speichern des Inhalts des Akku an Adresse des Operanden BCS 28 Springen an die Adresse des Operanden, wenn Carry Flag gesetzt ist BEQ 18 Springen an die Adresse des Operanden, wenn Zero Flag gesetzt ist IN 50 Laden des Akku mit Inhalt des Ports des Operanden OUT 90 Speichern des Akku an Port des Operanden Tabelle 4.2: Adressmodiunabhängige Befehle Die in den Tabellen 4.2 und 4.1 gezeigten Befehle machen deutlich, dass die CPU zum Verstehen der grundsätzlichen Abläufe geeignet ist, zum produktiven Einsatz jedoch nicht taugt. Wir gehen daher davon aus, dass der Ansatz der hinter den Entwicklung dieser CPU steckt, rein didaktischer Natur ist. Dies begründen wir damit, dass der Funktionumfang nur für einfache Befehlsabläufe geeignet ist und somit für komplexere Operationen ein hoher Aufwand getrieben werden muss, um ein Ergebnis zu erzielen. Für einfache Bitoperationen ist die CPU jedoch geeignet, da hierzu sämtliche nötigen Logikfunktionen zur Verfügung stehen. Um ein vollständiges Bild zu erhalten, wollen wir im Folgenden noch auf das Layout der CPU eingehen. 21. Februar 2005 Seite 16

18 Abbildung 4.1: Layout der DEP-CPU Quelle: [BDH + 01] Abbildung 4.1 zeigt den Aufbau der CPU. Oben links bzw. rechts ist der Daten- bzw. Adressbus zu sehen, direkt an den Datenbus angeschlossen ist das IWR (Instruction Word Register), welches den zu verarbeitenden Befehl enthält. Das OPR (OperandenRegister) enthält den mit dem Befehl übergebenen Operanden, der entweder durch die ALU verarbeitet wird oder über den MuxAB als Adresswert auf den Adressbus ausgegeben wird. Der DECODER ist das Herzstück der CPU, er steuert mittels AluOP die Funktion der ALU und gibt mittels der CE x (ChipEnable) Leitungen die entsprechenden Register zum Überschreiben frei. Direkt an der ALU ist der Akku (AccR - AccuRegister) sowie das Carry- und Zero-Flag zu finden. Durch den Multiplexer MuxPC wird entweder eine Sprungadresse (1) oder der aktuelle Wert um 1 inkrementiert (0) in das PCR (Program Count Register) geladen. So kann ein Sprung durchgeführt oder der nächste Befehl abgearbeitet werden Asynchrone Umsetzung der DEP-CPU Innerhalb des genannten Projektseminars wurde versucht, eine asynchrone Umsetzung der DEP-CPU zu erreichen. In der Projektgruppe wurden verschieden Ansätze verfolgt, die DEP-CPU taktlos zu gestalten: Micropipelining Flankengesteuertes Dual-Rail Pegelgesteuertes Dual-Rail Diese drei Versuche schlugen aber alle fehl, da immer wieder Timing Probleme auftauchten oder sie aufgrund ihrer Größe schlicht nicht in den FPGA geladen werden konnten. Aus diesem Grund wurde für das eigentliche Ziel eine asynchronen 6502 Mikrocontroller zu entwickeln ein neuer Ansatz gewählt. Da man feststellte, dass ein Pegelgesteuertes Dual-Rail immer wieder zu Timing-Problemen führte, entwickelte man diesen Ansatz weiter und beließ nur noch die eigentliche Logik in dieser Implementierungsart. Die Kommunikation erfolgte mittels Flankensteuerung. Dies verdeutlicht die 21. Februar 2005 Seite 17

19 folgende Abbildung: Abbildung 4.2: Angewendetes Dual-Rail Verfahren Quelle: [BDH + 01] Die Abbildung 4.2 zeigt den grundsätzlichen Aufbau einer jeden Grundfunktion wie AND, OR, XOR. Die hierzu benötige Logik findet sich in dem Block in der Mitte als Disjunktive Normalform (DNF). Auf der linken Seite befinden sich die Edge-Detectoren (ED), welche ankommende Signale (Flanken) interpretieren und in stabile Pegelgesteuerte Dual-Rail-Signale umwandeln, auf der rechten Seite dazu die Gegenstücke, die Edge-Generatoren (EG), welche das Ergebnis interpretieren und dann ausgeben. Für den schematischen Aufbau der Detectoren und Generatoren sei in den Abschnitt 6 des unter [BDH + 01] zu findenden Dokuments verwiesen. Eine genaue Erklärung würde an dieser Stelle zu weit führen. Die Timing-Probleme in den vorhergehenden Versuchen rührten daher, dass man nicht wusste, wann ein Ergebnis nun komplett ist. Dieses Problem ist hier nun so behoben, dass die Generatoren, sobald sie einen stabilen Pegel erhalten, eine Flanke erst vorbereiten (den nächsten Ausgabewert in einem FlipFlop speichern). Sind sie bereit, geben sie ein ACK aus, welches die Eingangs-Detectoren wieder zurück setzt und welche wiederum dann eine Nullwelle auslösen. Ist diese Welle durch die DNF gelaufen, gehen alle Ausgänge auf LOW-Pegel und durch das untere grosse AND-Gatter wird das CLK-Signal generiert. Dieses CLK-Signal zeigt den Generatoren das alle Daten bereit sind und sie geben gemeinsam ihren gespeicherten Wert aus. Auf diese Weise werden alle Ausgänge gleichzeitig geschaltet und zeitkritische Überlegungen werden an dieser Stelle überflüssig. Die gesamte Komponente ist somit entkoppelt vom Gesamtsystem. 21. Februar 2005 Seite 18

20 Abbildung 4.3: Asynchrone Variante der DEP-CPU Quelle: [BDH + 01] Die Abbildung 4.3 zeigt nun das Ergebnis der Bemühungen. Wie zu sehen ist, wurde im Gesamtsystem wohl mit Flanken- als auch mit Pegelgesteuerter Dual-Rail gearbeitet. Dieses Entwurfskonzept war das einzige, welches ein lauffähiges Ergebnis auf einem FPGA hervorbrachte. Aus diesem Grund wurde dieser Ansatz auch für die Entwicklung der asynchronen Variante des 6502 gewählt Mikro-Prozessor 6502 Der Prozessor MOS6502 ist ein 8-Bit Prozessor basierend auf der Motorola 68xx Serie. Er wurde das erste Mal um 1975 auf den Markt gebracht, kurze Zeit später - wegen Bedenken von Motorola - aber wieder vom Markt genommen. Anschließend nach einer kleinen Korrektur, die sicherstellte, dass Motorolas Rechte nicht mehr verletzt wurden, wurde er endgültig Marktreif. Weitere Informationen über diesen Chip gibt es in div. Literatur, eigenen Webseiten für diesen Prozessor sowie Fachzeitschriften. Eine ausgewählte Quelle soll [EL86] zeigen, gleiche Quelle beschreibt auch die Architektur des Prozessors genauer. Hierzu finden sich auch im bereits erwähnten Dokument der Projektgruppe detaillierte Hinweise - an gleicher Stelle wird ebenfalls der Befehlssatz erläutert. Aufgrund nicht ausreichender Dokumentationen, die zur Verfügung standen, spiegelt das Ergebnis keine exakte Kopie des Originals wieder. Es erfüllt jedoch die Anforderungen und lief im regulären Betrieb wie das synchrone Vorbild. Welche Einschränkungen genau gemacht wurden, ist aus genanntem Dokument zu ersehen. So ist der erzeugte Baustein nicht Pinkompatibel zu seinem synchronen Vorbild und arbeitet ebenfalls nicht mit konventioneller Logik sondern erwartet Flankengesteuerte Signale an seinen Eingängen und erzeugt diese an den Ausgängen. Um also die synchrone Variante mit der entwickelten asynchronen zu ersetzen, wird zusätzlich eine entsprechende Übersetzungsschaltung benötigt. Das Blockschaltbild wurde bei der Umsetzung auf asynchrone Logik weitestgehend beibehalten, durch die Vorarbeiten, die während des Entwurfs der DEP-CPU entstanden sind, war eine Implementierung der 6502 CPU sehr viel schneller möglich. Die synchronen Komponenten wurde quasi nur ersetzt. Eine genauere Beschreibung, wie hier vorgegangen wurde, würde nur in einer Wiederholung der uns vorliegenden Ausarbeitung münden. Daher soll hier darauf nur verwiesen werden Ergebnisse Es zeigte sich, dass die erzeugte CPU nur um den Faktor 3 mehr Platz im FPGA benötigte als die synchrone Variante. Mit 3091 CLB blieb dies weit unter den Erwartungen der Projektteilnehmer. 21. Februar 2005 Seite 19

21 Eigentliches Ziel war es, einen Benchmarkvergleich zwischen beiden Prozessoren durchzuführen. Dies scheiterte jedoch am hohen Platzbedarf des asynchronen Entwurfs. Die für den Benchmark benötigte Hardware fand schlicht keinen Platz mehr im FPGA. Diese Hardware wäre benötigt worden, um eine Übersetzung von konventioneller Logik auf die Flankengesteuerte Logik des asynchronen 6502 durchzuführen. Als Gesamtergebnis des Projektes stellte sich heraus, dass durch stark optimierte Kompilerdurchläufe, im Bezug auf den Platzbedarf, das Ziel erreicht werden konnte einen asynchronen Prozessor auf einem vorhandenen FPGA zu implementieren. Dies jedoch auf Kosten der Geschwindigkeit der CPU. Ebenfalls mussten neue Ansätze entwickelt werden, um auftretende Probleme u.a. beim Timing zu lösen. Eine Lösung mit konventionellen, asynchronen Verfahren (wie Micropipelining) war bei den gegebenen Möglichkeiten nicht anwendbar, da entsprechende Messtechnik (bzw. Simulationssoftware) fehlte, um die erzeugte Hardware aussreichend zu untersuchen und die Probleme so zu beheben. Es wird jedoch davon ausgegangen, dass der Ansatz des Micropipelinings erfolgversprechend wäre, sofern die entsprechende Laborausstattung vorhanden ist. Durch die Entwicklung der DEP-CPU konnten viele Funktionen in Standard-Komponenten zusammengefasst werden, was bei der Entwicklung des 6502 einen enormen Zeitvorteil brachte. Es wird davon ausgegangen, dass diese Komponenten auch bei jeder weiteren Entwicklung einen Zeitvorteil bringen. Diese Ansätze kombinieren die geringe Größe des pegelgesteuerten Dual-Rail mit der Geschwindigkeit des flankengesteuerten Dual-Rail, so konnte die Größe der CPU minimiert werden und trotzdem nur geringe Einbußen bei der Geschwindigkeit gemacht werden. Es zeigte sich, dass bei den relativ kurzen Logikoperationen in einem 6502 kaum Geschwindigkeitsvorteile gegenüber der synchronen CPU erreicht werden. Zusätzlicher Zeitaufwenig ist der ständige Zugriff auf den Speicher, der die eigentliche Berechnungszeit in den Hintergrund treten lässt. Es wird jedoch vermutet, dass sich bei komplexerer Logik für einen Befehl dieses Verhältnis zu Gunsten der asynchronen Variante ändert. Zusätzlichen Zeitvorteil würde hier ein asynchron implementierter Cache bringen. Die verwendeten FPGA s sind für den synchronen Entwurf ausgelegt, es scheint daher sinnvoller, auf vorhandene ASIC zurückzugreifen, die komplett asynchron implementiert sind. Ein solcher Ansatz wird mit dem Amulet Prozesor verfolgt (siehe Kapitel 5.2). Ebenso wäre es möglich, FPGA s zu nutzen, die eine asynchrone Implementierung besser unterstützen. Auf diesen Punkt gehen wir im zusätzlichen Laborbericht noch einmal ein. 21. Februar 2005 Seite 20

22 Kapitel 5 Asynchrone Prozessoren 5.1 ASPIDA - Asynchronus open-source Processor Ip of the DLX Architecture Der ASPIDA-Prozessor ist eine asynchrone Implementierung der DLX Architektur eines RICS Prozessors. Die Vorlage zu dieser Implementierung bilden die Entwürfe von Hennesy und Patterson [HP90]. An der Entwicklung sind beteiligt die Universitäten von Griechenland ( Manchester ( sowie Turin ( Dies ist insofern interessant, da so eine Verbindung zu der Entwicklung des schon länger bekannten asynchronen Prozessors AMU- LET (siehe unter Kapitel Amulet) an der University of Manchester hergestellt wird. Personell wird diese Verbindung durch Dr. Doug Edwards - Mitglied der Amulet-Group - gestärkt. Ebenso ist beteiligt Prof. Steve Furber - ehemaliger Chef-Designer für ARM-Prozessoren bei ACORN Ltd. Beginnen wollen wir mit einer kurzen Einführung in die Architektur eines DLX-Prozessors, um später ein besseres Verständnis für die asynchrone Implementierung zu erreichen DLX-Architektur Der DLX-Prozessor ist ein Prozessor aufgebaut aus einer fünfstufigen Pipeline, aufgeteilt in Instruction Fetch (IF), Instruction Decode (ID), Execute (EX), Memory(MEM) sowie Write Back(WB). Für eine genauere Erklärung der Pipelinestufen verweisen wir auf die Rechnerstrukturen-Vorlesung und das zugehörige Script [Ris04] aus dem Sommersemester Hier finden sich auch viele weitere Erklärungen bezüglich der DLX-Architektur. Grundsätzlich verarbeitet der Prozessor drei Typen von Operationen: I-Type für logische und arithmetische Operationen zwischen einem Register und einem immediate sowie Verzweigungen und Load/Store Anweisungen. R-Type für logische und arithmetische Operationen zwischen drei Registern. J-Type für Sprünge. Für den Aufbau der Instruktion-Set-Architecture (ISA) im Bezug auf Aufbau des Befehlscodes sowie mögliche Instruktionen sei ebenfalls auf obige Quellen verwiesen. 21. Februar 2005 Seite 21

23 Abbildung 5.1: Datenpfad der DLX Architektur Quelle: arch.html Abbildung 5.1 zeigt den Datenpfad der DLX Architektur, gut zu erkennen die 5 Pipelinestufen. Diese Architektur bildet die Grundlage für die asynchrone Implementierung sowie eine synchrone Referenzimplementierung Asynchrone Umsetzung von DLX Bei der Umsetzung wollte man nicht zu weit von der gut bekannten und an vielen Universitäten und Fachhochschulen gelehrten Architektur abweichen. Man wählte zwei Wege der Umsetzung, zum einen eine Programmierung in Verilog und anschließender Synthese mittels des Tools Pipefitter (Näheres zu Pipefitter unter [BL00]). Der andere eingeschlagene Weg ist eine Implementierung mittels Handshake, auf diese Implementierung wollen wir an dieser Stelle weiter eingehen. Sie liegt uns als lauffähige Version in Verilog sowie als direktes Bitfile vor. Für die Implementierung mittels Pipefitter sei auf das Dokument [unk03] verwiesen, es ist uns nicht bekannt, ob hierzu eine Implementierung vorliegt Desynchronizing der DLX Das gewählte Verfahren eine synchrone Implementierung taktlos zu gestalten, nennt man Desynchronizing, das Verfahren wurde u.a. von dem Projektverantwortlichen Dr. Christos P. Sotiriou entwickelt. Nähere Informationen zu dem Verfahren finden sich unter [SL00]. Grundsätzlich lässt sich sagen, dass in diesem Verfahren das globale Clocksignal entfernt wird und zwischen den einzelnen Pipelinestufen sog. Delay-Elemente eingefügt werden. Sie kümmern sich um die Datenübergabe sowie das Handshaking. 21. Februar 2005 Seite 22

24 Abbildung 5.2: DLX Architektur nach Desynchronizing Quelle: asic.html Abbildung 5.2 zeigt das Ergebnis des Desynchronizing Vorgangs. Deutlich zu sehen sind die eingesetzten Delay-Elemente zwischen den Pipelinestufen. Eine Implementierung, wie sie Abbildung 5.2 beschreibt, liegt uns, wie schon gesagt, als lauffähige Version vor. Die erste Vorstellung der Implementierung erfolgte auf der ASYNC2004 (The 10th IEEE International Symposium on Asynchronous Circuits and Systems) Konferenz vom April 2004 in Griechenland (Siehe hierzu Hier wurde von der Forschungsgruppe eine Demo vorgeführt, die das mathematische Problem Game-of-life implementiert. Dieses Demo wollen auch wir als praktischen Anteil vorführen. Eine Erklärung, wie Game-of-life funktioniert, findet sich an vielen Stellen im Internet. Als aussagekräftige Quelle haben wir [Köl00] empfunden. Dieses Demo-Programm zeigt lediglich die grundsätzliche Funktionsfähigkeit des ASPIDA. Es ist sogar so, dass in diesem Fall die synchrone Variante schneller ist als die asynchrone. Einen Erklärungsversuch hierzu streben wir im zusätzlichen Laborbericht an, der dieser Ausarbeitung anhängt. 5.2 Amulet Die Reihe der Amulet Prozessoren wird von einer Forschungsgruppe voran getrieben, die an der Universität von Manchester beheimatet ist, der APT-Group (The Advanced Processor Technologies Group) [URL: Bis heute sind ausgegangen vom ersten Prozessor - dem Amulet1 - drei weitere Prozessoren entwickelt worden. Aktuell ist der Prozessor Amulet3i. Er wurde als System-on-a-Chip (SoC) bereits im September 2000 in Silikon gegossen - wie es auf der Webseite heißt. 21. Februar 2005 Seite 23

25 Abbildung 5.3: Amulet Chip-Layout Quelle: Deutlich zu erkennen ist in Abbildung 5.3 die Aufteilung des Chips, so sind z.b. unten links die 8 schwarzen Blöcke als jeweils 1kByte RAM zu sehen. Der Prozessor selber ist rechts auf dem Bild zu sehen. Die Simulation des Chips zeigte, dass ein Vergleich mit einem ARM9-Prozessor (Siehe hierzu durchaus zulässig ist und eine durchschnittliche Zahl von MIPS erreicht wurde, dieses aber abhängig von den jeweiligen Daten, was nahe liegt, da je nach Komplexität der Daten eine Instruktion bei einem asynchronen Prozessor länger oder eben kürzer dauert, wobei ein getakteter Prozessor immer die gleiche Zeit benötigt, da eben der Worst-Case-Fall die Taktfrequenz bestimmt. Abbildung 5.4: Amulet Chip-Layout Quelle: mainframe.htm#intro Den Vergleich komplett macht die Abbildung 5.4, sie zeigt die elektromagnetische Ausstrahlung beider Prozessoren im Vergleich. Deutlich zu sehen ist die unruhige Linie beim ARM9 Prozessor, dem gegenüber eine gleichmäßige Linie beim Amulet Prozessor. Dies zeigt, dass nicht ein globales Taktsignal die Flip-Flops zum Schalten bewegt sondern ein asynchrones Verfahren eingesetzt wird. Dies 21. Februar 2005 Seite 24

26 minimiert die elektromagnetische Ausstrahlung. Zum Vergleich könnte der Gleichschritt von Soldaten beim Laufen dienen; ist dieser synchron so kann eine Brücke in Schwingungen geraten. Läuft dieselbe Anzahl Personen über die gleiche Brücke - nicht im Gleichschritt -, passiert nichts dergleichen. Für Embedded Anwendungen ist dies sehr interessant, da so z.b. GPS, Mobilfunk oder andere Datenübertragungen nicht gestört werden. Aus gleichem Grund können die Kosten für eine Abschirmung gering gehalten werden. 21. Februar 2005 Seite 25

27 Kapitel 6 Fazit Wir fanden die behandelten Themen sehr interessant und leider in der Industrie viel zu wenig beachtet. So wartet z.b. der fertig entwicklete Amulet Prozessor noch immer auf seinen Einsatz in einem industriellen Umfeld. Die Ansätze, die wir gesehen haben, zeigen einige Vorteile sowohl für die Entwickler als auch im Betrieb der Komponenten. So kann durch die Handshake-Technologie beispielweise jede Komponente separat betrachtet werden und herausgenommen aus dem Gesamtsystem weiterentwickelt werden. Durch die definierten Schnittstellen, innerhalb asynchroner Schaltungen (Handshake), können die verbesserten oder erweiterten Komponenten, ohne Folgen für die Funktionalität des Gesamtsystems fürchten zu müssen, ausgetauscht werden. Eine grundsätzliche Feststellung war, dass asynchrone Komponenten weniger Strom für die gleiche Leistung benötigen. Sie verarbeiten meist die Signale weder schneller noch mit weniger Aufwand, sind aber sparsamer mit den Ressourcen und so speziell für den Embedded Bereich von Vorteil. Auch sind sie weniger abhängig von Umwelteinflüssen wie beispielweise Wärme. Die elektromagnetische Abstrahlung asynchroner Komponenten ist sehr viel geringer als die ihrer synchronen Gegenstücke. So muss ein geringerer Aufwand für die Abschirmung getrieben werden. Die Beeinflussung von Signalen durch die Komponenten ist ebenfalls geringer. Wir denken, dass die asynchronen Technologien im Bereich der Embedded Systeme einen höheren Stellenwert erreichen werden als im konventionellen PC. Durch die stetig steigenden Taktzahlen steigt auch der Aufwand, alle Komponenten in einem Prozessor synchron zu halten. Durch den sog. Clock-Skew erhalten einige Komponenten das Taktsignal später als andere und laufen so nicht mehr synchron, dies gilt es in einem synchronen Prozessor zu vermeiden. Bei einer asynchronen Implementierung fällt dieser Aufwand weg. Für zukunftige Projekte wäre evtl. eine Untersuchung der von der ASPIDA-Forschungsgruppe zur Verfügung gestellten C-Library ein interessantes Betätigungsfeld. Für uns blieb hierzu leider während der Laufzeit des Projektes keine Zeit. 21. Februar 2005 Seite 26

28 Abbildungsverzeichnis 1.1 Entwicklung der asynchronen Prozessoren Logikblöcke sind in Taktgesteuerten Prozessoren von einem Eingangs- und einem Ausgangsregister umgeben Jeder Logikblock signalisiert über Handshake-Leitungen seinen momentanen Zustand Das Muller-C-Gate verhält sich wie ein spezielles Flipflop, es ist das Kernstück der Micropipelines Schematischer Aufbau einer Micropipeline. Das System arbeitet asynchron und organisiert sein Timing selbst Decoder mit vier Pipelinestufen AND, OR und NOT in Three rail Codierung Gatter mit Rückführung (Feedback) Ein 5 input threshold 3 gate Ein Halbaddierer mit Wahrheitstablle, in boolescher und NULL-Convention-Logic Ein threshold gate mit feedback Blockbild eines asynchronen Registers Ein asynchrones NCL Register Konzeptioneller Aufbau eines threshold gates mit Feedback in statischer CMOS- Technologie. Die einzelnen Blöcke enthalten die Bedingungen, bei denen das Gatter zu NULL bzw. DATA wird und deren Komplemente Layout der DEP-CPU Angewendetes Dual-Rail Verfahren Asynchrone Variante der DEP-CPU Datenpfad der DLX Architektur DLX Architektur nach Desynchronizing Amulet Chip-Layout Amulet Chip-Layout Februar 2005 Seite 27