TU Wien:Computer Architecture LU (Grünbacher)
- Computer Architecture LU (Grünbacher) (TU Wien, veraltet, 0 Materialien)
- Computer Architecture VO (Grünbacher) (TU Wien, veraltet, 6 Materialien)
Daten[Bearbeiten | Quelltext bearbeiten]
Vortragende | O.Univ.Prof. Dipl.-Ing. Dr.techn. Herbert Grünbacher, Univ.Ass. Dipl.-Ing. Wolfgang Puffitsch |
---|---|
ECTS | 3 |
Sprache | English |
Links | Homepage |
Masterstudium Software Engineering & Internet Computing | |
Masterstudium Technische Informatik |
Inhalt[Bearbeiten | Quelltext bearbeiten]
Wie in der Vorlesung geht es um die Architektur eines Prozessors. In der Übung wird ein Prozessor in der Gruppe geplant und für ein FPGA-Board implementiert.
Ablauf[Bearbeiten | Quelltext bearbeiten]
In einer Gruppe von 2-4 Leuten gibt es mehrere Teile zu erledigen.
ISA I[Bearbeiten | Quelltext bearbeiten]
Jedes Gruppenmitglied beschreibt eine beliebige Architektur, in einem gemeinsamen Dokument werden diese Architekturen verglichen (Adressierungsarten, Pipeline, Instruction Set, RISC/CISC,...)
ISA II[Bearbeiten | Quelltext bearbeiten]
In der Gruppe wird ein eigener Prozessor entworfen. Im Prinzip ist das Ergebnis eine Liste von Instructions. Mit ein paar Loads, einfachen arithmetischen Befehlen, jumps und branches läuft der Prozessor - aber umso mehr Gedanken da reinfließen, umso weniger Probleme gibt's. Wenn die Befehle ordentlich angeordnet sind, ist's in der Pipeline weitaus einfacher, sie entsprechend zu behandeln. Also: ähnliche Befehle so aneinanderreihen, dass ein einziger Vergleich über das Instruction Word reicht, um zu erkennen, ob eine Einheit des Prozessors benötigt wird. Nur ein Beispiel. Ich wollte damit nur sagen, dass das Beispiel vielleicht einfach wirkt und zum "Runtertippen" verleitet, aber nicht unterschätzt werden sollte.
Üblich sind 32- oder 16-bit Prozessoren, ähnlich MIPS. Kreativere Ideen dürften aber gern gesehen sein.
Assembler und Simulator[Bearbeiten | Quelltext bearbeiten]
Es muss ein Assembler gebaut werden. Anforderung: aus ASM-Code Maschinencode entsprechend der ISA bauen. Wie der gebaut ist, ist egal. Für die Größe reicht wohl ein Python-Script (oder irgendwas in C++, Java,... zusammengehacktes), wer sich mit Compilerbautools wohler fühlt, kann die nehmen. Ich fand den Weg über $Programmiersprache und Zeile für Zeile durch Regular Expressions jagen eigentlich sehr effizient.
Weiters muss ein Simulator programmiert werden. Programmiersprache egal, Hauptsache das ISA wird (korrekt) simuliert. Unterstützung von Hardwareerweiterungen (UART, Timer, ...) muss nicht sein.
FPGA Design Flow[Bearbeiten | Quelltext bearbeiten]
Es geht um den Design Flow (sollte bereits bekannt sein, als Wiederholung).
Für den Designflow steht im Labor Quartus zu Verfügung, für Simulationen Modelsim. Die Programme sind zwar leider nicht frei, es gibt aber gratis Webeditions für Windows und Linux. Diese würde ich sehr empfehlen, die Zeit im Labor kann sonst sehr lang werden.
Blockdiagramm[Bearbeiten | Quelltext bearbeiten]
Das grundlegende Zusammenspiel der Pipelinestufen muss als Blockdiagramm dargestellt werden. Wenn man hier ein paar Stunden mehr investiert und wegen Abhängigkeiten nachdenkt kann das nachher viel Zeit sparen!
Simulation 1-3[Bearbeiten | Quelltext bearbeiten]
Es müssen die verschiedene Stufen der Prozessorentwicklung per Simulation vorgeführt werden. Im Abstand von je 2 Wochen müssen folgende Punkte vorgeführt werden:
- die einzelnen Pipeline Stufen
- das auflösen von Datenabhängigkeiten
- das auflösen von Kontrollabhängigkeiten
Abgabe[Bearbeiten | Quelltext bearbeiten]
Der Prozessor muss auf der Hardware laufen und die vorgegeben Testprogamme ausführen.
Ein Punkteschema findet sich auf der LVA-Seite.
Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten | Quelltext bearbeiten]
Grundkenntnisse, was in einem Prozessor steckt, sollten da sein.
VHDL ist grauslich (und da muss man den Artikel jetzt nicht als subjektiv markieren, das ist es einfach ;) ), Hardware Modellierung, Digitales Design,... Sowas gemacht zu haben ist nicht verkehrt.
ASM - um das Teil auch programmieren zu können...
Vortrag[Bearbeiten | Quelltext bearbeiten]
Es gibt eine gleichnamige VO, der Artikel ist über die LU, daher nur ein kurzer Link (dort sind Folien): http://ti.tuwien.ac.at/rts/teaching/courses/cavo
Prüfung, Benotung[Bearbeiten | Quelltext bearbeiten]
Benotet wird nach dem Punkteschema auf der LVA-Seite. Das Abgabegespräch ist eher harmlos nach dem Basteln am Prozessor. Vorführen, was geht - verschweigen, was nicht geht. Geniale Programme werden nicht erwartet, Demonstrationen, dass die Funktionen des Prozessors korrekt sind, reichen prinzipiell.
Dauer der Zeugnisausstellung[Bearbeiten | Quelltext bearbeiten]
Weiß ich noch nicht.
Zeitaufwand[Bearbeiten | Quelltext bearbeiten]
Sehr hoch. Im TI-Vergleich wohl nahe Embedded Systems Übung, würde ich sagen. Wenn du 3 ECTS für's Master willst, vergiss es. Wenn du einen Prozessor bauen willst - mir hat's echt Spass gemacht und mir tut's sicher nicht leid um die Zeit. Gibt viel zu lernen und ich fand's höchst interessant.
Unterlagen[Bearbeiten | Quelltext bearbeiten]
- VO Folien: http://ti.tuwien.ac.at/rts/teaching/courses/cavo
- Wikiversity: http://en.wikiversity.org/wiki/Computer_Architecture_Lab
- CYCORE: http://www.jopdesign.com/cyclone/index.jsp
- DSPIO Board: http://ti.tuwien.ac.at/rts/teaching/soc/dspio
- LVA-Wiki: http://www.soc.tuwien.ac.at/Computer_Architecture_Lab/Benchmarks
- Deep Thought Source: http://wien.tomnetworks.com/gitweb/?p=calu.git
- Buch: Computer Architecture - A Quantitative Approach von John L. Hennessy und David A. Patterson
Das Buch ist nicht unbedingt notwendig. Ich habe nur kleine Teile davon gelesen, die waren aber schon hilfreich. Ich wusste vorher nicht so detailliert, wie eine Pipeline geplant werden soll oder ähnliches.
Tipps[Bearbeiten | Quelltext bearbeiten]
Tja, den Teil zum Prozessor basteln habe ich sehr kurz gehalten, ich weiß nicht wirklich wie ich hier Tipps geben kann.
- gut planen
- evtl. die Pipeline(stages) samt Register graphisch darstellen. Hilft doch sehr beim Implementieren, wenn du die Blöcke vor dir siehst...
- VHDL Vorkenntnisse und evtl. mit ganz kleinen simulierbaren Beispielen üben. Hier (http://de.wikibooks.org/wiki/VHDL) gibt's zB eine kleine Übersicht. Einfach kleine Programme mit Blinklichtern (= ein Signal) basteln und simulieren, um ein Gefühl zu bekommen. Je nachdem, wie gut die eigenen VHDL-Kenntnisse sind...
- Hardware ist anders als Software, jedoch stimmt auch hier die Regel, dass alles x mal länger dauert als geplant
- Wikiversity anschauen, da gibt's ein paar Tipps bzw. Dokumentation der letzten Jahre
- Warnungen in Quartus können sehr böse sein
- auf Timing aufpassen, wenn externe Hardware (zB SRAM) verwendet wird. In den Settings von Quartus lassen sich Delay requirements eintragen.
- Für Eclipse gibt's ein Plugin namens Simplifide für VHDL/Verilog - nicht perfekt, aber das beste, was ich für VHDL gefunden habe...
- Quartus und Modelsim sind bei ihrer VHDL-Standard Konformität/Auslegung ziemlich unterschiedlich was zu langem (Fehler)suchen führt
- Design Space Explorer + ein paar Rechner im TILab + ~ 1 Stunde == Verbesserung der fmax um vlt 1MHz
Meinung[Bearbeiten | Quelltext bearbeiten]
- Wie ich schon vorher erwähnt habe, mir hat's wirklich Spass gemacht. Zeitaufwand ist hoch, aber die Zeit ist gut investiert.
Verbesserungsvorschläge / Kritik[Bearbeiten | Quelltext bearbeiten]
noch offen