Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Praktikum: “Games with Cellular Automata” auf parallelen Rechnerarchitekturen (PParRA)
Hi!
Hat jemand das Praktikum gemacht? Wie war die Durchführung / worauf wird besonders geachtet? Sollte man sich auf irgendwas vorher einstellen? Wie anstrengend war der VHDL-Teil? 
Kurze Zusammenfassung:
Los ging es mit dem “Software”-Teil. Es wurde Wärmeausbreitung mit Hilfe eines Jacobi-Glätters implementiert. Den Algorithmus zu optimieren (z.B. Mehrgitterverfahren) ist nicht vorgesehen, es geht darum den Algorithmus so zu lassen und die Hardware optimal auszunutzen.
Als erstes also einfach mal den Algorithmus implementieren. Danach mit SSE beschleunigen. Der nächste Schritt ist mit Hilfe von OpenMP auf mehreren Kernen bzw. Prozessoren zu rechnen. Danach kam MPI an die Reihe um mal auf mehreren Nodes zu rechnen. Man entwickelte dann auch noch eine CUDA-Version.
In dem Teil sollte man verschiedene “Systeme” (MPI auf Nodes mit 2x6 Kerne vs. 2x2 Kerne; Tesla vs. Geforce) vergleichen (Speedups etc.) und die Leistung dahingehend bewerten was die Hardware theoretisch an FLOPS oder GLUPS schafft und wie viel man davon erreicht hat.
Der zweite Teil der dann auch etwas länger war als gedacht war Programmierung auf einer Cell BE. Um erstmal mit dem Chip zurecht zu kommen wurde eine Vektoraddition implementiert. Anschließend bekamen wir ein Framework vorgegeben in dem wir die Funktionen mit Code füllen mussten. Leider war da recht wenig kommentiert, so dass man nicht eindeutig wusste was wo hin soll. Also haben wir halt mal irgendwie gemacht, so dass das Programm insgesamt funktioniert. Das Problem war aber auch, dass Max, von dem das Framework ist, zwischenzeitlich nicht da war und somit Fragen zum Framework nicht beantwortet werden konnten.
Es wurde hier natürlich auch wieder eine Wärmeausbreitung mit einem Jacobi-Glätter implementiert.
Bei VHDL ging es dann erstmal damit los ein DFF in VHDL zu basteln. Weiter ging es mit einem Volladdierer und einem Ripple-Carry-Addierer wobei der Volladdierer von der Aufgabe vorher verwendet wurde. Für DFF und Volladdierer wurde noch eine funktionale Simulation durchgeführt. Anschließend wurde eine 7-Segment-Anzeige angesteuert. Das alles wurde dann zusammengefrickelt und mittels Schalter konnte man zwei Binärzahlen einstellen die über die 7-Segment-Anzeige angezeigt wurden, der RCA hat diese Zahlen addiert und auch das Ergebnis wurde ausgegeben. Es wurde auch noch ein Lauflicht programmiert, wobei man die Richtung per Schalter festlegen konnte und auch die Geschwindigkeit konnte beeinflusst werden.
Als letztes gab es noch (Soft-)IPs. Hier weiß ich grad nicht mehr auswendig wie wir angefangen haben. Aber man wurde wieder Schritt für Schritt weiter geführt und hat am Schluss drei MicroBlazes (in VHDL als IP vorhandene Mikrocontroller) mittels GIPO-Blöcken verbunden. Auf zweien sollte ein Programm (das man in C geschrieben hat) ausgeführt werden, Kommunikaiton zwischen den MicroBlazes erfolgte per GPIO. Der dritte MicroBlaze bekam ebenfalls per GPIO die Werte der anderen beiden geliefert und kümmerte sich um die Darstellung (Ansteuerung des VGA-Ports war bereits in VHDL gegeben, musste aber an den Bus vom MicroBlaze angebunden werden). Was wir am Schluss als Programm drauf laufen lassen (Wärmeausbreitung oder Game of Life etc.) war egal, es musste nur laufen 
Vor Ort musste man an zwei Tagen die Woche je 4 Stunden sein. Zu Beginn jeden Tages gab es immer einen Vortrag in dem die Aufgabe vorgestellt wurde, ggf. die Hardware oder das Programm das verwendet wurde und dann konnte man loslegen. Der Rest der 4 Stunden war bisschen wie betreute Rechnerzeit in AuD oder SP. Außerhalb der Termine konnte man immer in den Raum wenn man Lust hatte und konnte weiterarbeiten. Bei den Software-Sachen konnte auch per SSH von zu Hause aus gearbeitet werden (bei der FPGA-Programmierung auch, aber man konnte halt nicht kontrollieren was der FPGA grad an der 7-Segment-Anzeige ausgibt ).
Nach jedem Block (1. SSE, OpenMP und MPI, 2. CUDA, 3. CELL, 4. VHDL, 5. IPs) gab es ein Kolloquium. Diese waren etwas unterschiedlich. Am Anfang war es noch nur Unterschiede zu beschreiben und bisschen Erfahrungen aus den Versuchen. Bei CELL musste man schon den Aufbau des Chips kennen und bei den letzten beiden sollte man vorher alle Folien der Vorträge gut angeschaut haben usw. Es gab aber zu Beginn von jedem Termin eine kleine Fragerunde bei der der Betreuer immer Fragen zu dem Thema vom vorherigen Termin gestellt hat. Das waren meist auch Fragen die so oder ähnlich auch im Kolloquium drankommen.
Es gab noch zwei freiwillige Bonusaufgaben die aus bisschen Rumblödeln entstanden sind. Eventuell werden sie zu richtigen Bonusaufgaben.
Die erste war einen Musikspieler in VHDL zu programmieren, der (da es kurz vor Weihnachten war) ‘Stille Nacht’ Spielt. Wenn man das hinbekommen hat wurde einem das Kolloquium erlassen.
Die zweite Zusatzaufgabe war wieder dem FPGA beizubringen Töne zu spielen. Diesmal sollte die Musik nicht fest eingebaut sein sondern es sollte beliebiges gespielt werden können. Hierzu konnte man z.B. die serielle Schnittstelle nutzen um die zu spielenden Töne entgegen zu nehmen und nach der Übertragung wird das “Lied” in Endlosschleife abgespielt. Wer ganz viel Langeweile hat kann auch eine Tastatur anschließen und ein Keyboard basteln, hat aber niemand gemacht.
(die erste Zusatzaufgabe wurde von zwei Teams bearbeitet, die zweite von einem)
In den Protokollen wurden Erfahrungen und Schilderungen von Problemen mit Lösungen erwartet. Teilweise auch Beschreibung der Hardware, teilweise sollte man die Hardware aber explizit auch nicht beschreiben, da ‘das auch überall im Internet nachgelesen werden kann’ (Zitat entsprechender Betreuer).
Die Note setzt sich aus der Mitarbeit vor Ort, den Kolloquien und den Protokollen zusammen, genaue Aufteilung siehe Webseite.
Der Teil mit der Cell BE wurde in der Nachbesprechung kritisiert. Da man bei der Cell zwei Programme schreiben muss und diese nicht gescheit mit gdb etc. gedebuggt werden können ist die Fehlersuche etwas schwieriger. Hier soll nachgebessert werden. In welcher Form wurde aber nicht gleich beschlosen.
Insgesamt interessant und empfehlenswert. Wenn jemand viel VHDL machen will, der wird aber wohl enttäuscht sein, dass das nur ca. die Hälfte ist.
Mit wenigen Ausnahmen konnten die Aufgaben in der Präsenzzeit (also 2x4 Stunden die Woche) bearbeitet werden. Allerdings kommt noch die Protokollierung und das Protokoll schreiben hinzu.
Wenn man den Arbeitsaufwand mit dem Hacker-Praktikum vergleicht muss man aber sagen, dass hier die 10 ECTS geschenkt sind (so weit ich das gelesen hab, muss man beim Hacker-Praktikum deutlich mehr machen).
5 „Gefällt mir“