TU Wien:Computer Architecture LU (Grünbacher)
- Computer Architecture LU (Grünbacher) (TU Wien, veraltet, 0 Resources)
- Computer Architecture VO (Grünbacher) (TU Wien, veraltet, 6 Resources)
Daten[edit | edit source]
Lecturers | O.Univ.Prof. Dipl.-Ing. Dr.techn. Herbert Grünbacher, Univ.Ass. Dipl.-Ing. Wolfgang Puffitsch |
---|---|
ECTS | 3 |
Department | Forschungsbereich Cyber-Physical Systems |
When | winter semester |
Language | English |
Links | Homepage |
Master Software Engineering & Internet Computing | Wahlmodul Unbekannt oder "Prä-Modul-Ära" - EDIT ME |
Master Technische Informatik | Wahlmodul Unbekannt oder "Prä-Modul-Ära" - EDIT ME |
Inhalt[edit | edit source]
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[edit | edit source]
In einer Gruppe von 2-4 Leuten gibt es mehrere Teile zu erledigen.
ISA I[edit | edit source]
Jedes Gruppenmitglied beschreibt eine beliebige Architektur, in einem gemeinsamen Dokument werden diese Architekturen verglichen (Adressierungsarten, Pipeline, Instruction Set, RISC/CISC,...)
ISA II[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
Weiß ich noch nicht.
Zeitaufwand[edit | edit source]
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[edit | edit source]
- 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[edit | edit source]
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[edit | edit source]
- 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[edit | edit source]
noch offen