TU Wien:Hardware-Modellierung VL (Lechner)

Aus VoWi
Wechseln zu: Navigation, Suche
Diese LVA wird nicht mehr von dieser Person angeboten, ist ausgelaufen, oder läuft aus und befindet sich daher nur noch zu historischen Zwecken im VoWi. Eventuell findest du über dieser Meldung noch andere Vortragende, oder Links für dieselbe LVA.


Daten[Bearbeiten]

Inhalt[Bearbeiten]

Der Designflow eines einfachen Chip wird mit Hilfe von VHDL und den AlteraTools (ModelSim-Altera und Quartus II) realisiert. Die finale Version muss auf den FPGA-Boards (MJL Stratix, bereits aus der DIDELU bekannt) lauffaehig sein. Die Aufgaben waren bisher:

  • SS07: Schließfachsteuerung
  • SS09: Taschenrechner (soweit bekannt, erfolgte die Ausgabe auf dem Siebensegment und die Eingabe durch ein Keypad)
  • SS10: Taschenrechner: Die Eingabe erfolgt mittels PS/2-Tastatur und die Ausgabe auf einen VGA-Bildschirm. Dabei koennen bis zu 50 Berechnungen stattfinden, die ggf. mittels RS232 Schnittstelle zum PC gedumpt werden sollen. Folgende Rechenoperationen mussten unterstuetzt werden: Addition, Subtraktion, Multiplikation und Division, wobei letzteres fuer 32-Bit Zahlen gar nicht so einfach in Hardware zu realisieren ist. Ein IP-Core fuer das PS/2 bzw. das VGA Modul wurde von der LVA-Leitung bereitgestellt.
  • SS11: Zeichenanwendung: Die Eingabe soll mittels Touchscreen erfolgen und die Anwendung soll dann entsprechende Linien bzw Kurven auf dem LCD Display darstellen.

Ablauf[Bearbeiten]

Es gibt Vorträge am Anfang des Semester und eine Übung, in Gruppen mit zwei Personen, im Labor.

Empfehlenswerte Vorkenntnisse[Bearbeiten]

DiDe VO

DiDe LU

Vortrag[Bearbeiten]

Ist interessant, ein Besuch ist jedoch nicht notwendig, aber empfehlenswert da öfters Hinweise für die Implementierung gegeben werden.

Übungen[Bearbeiten]

Es gibt eine kurze Einführung in die Tools. Für nächstes Semester wurde auch ein Skriptum für die Übung versprochen. Die Übung finden im Labor statt, es gibt keine Zwischenabgaben oder fixen Termine. Am Ende muss nur ein Projekt fertig sein. Über SSH besteht die Möglichkeit, sich einzuloggen und über X-Forwarding zu simulieren. Funktionierte großteils ganz gut aber ich würde mich nicht darauf verlassen...

SS10: Die Übung findet noch immer im Labor statt. Es gibt jedoch fixe Termine für die Abgaben.

Abzugeben sind:

  • Erste Version der Spezifikation
  • Blinded Review zu zwei anderen Spezifikationen (3 Wochen später)
  • Abgabe der finalen Spezifikation (2 Wochen später)
  • Abgabe des Designs (4 Wochen später)

Es wurden für ein paar Gruppen, auf Anfrage, die Deadlines um ein paar Tage verschoben.

Weiters war es möglich zum Abgabegespräch eine neuerer Versions des Designs mitzubringen bzw. nach dem Abgabegespräch noch Sachen auszubessern.

Prüfung, Benotung[Bearbeiten]

Prüfung gibt es keine. Am Schluss gibt's ein kleines Abgabegespräch, wo die Lösung präsentiert wird. Benotung ist glaube ich sehr in Ordnung. Wenn das Projekt funktioniert und das Abgabegespräch (ist wirklich gemütlich, wenn du das Projekt selbst gemacht hast und halbwegs mitdenkst sicher kein Problem. Es gibt keine Fallen oder gemeine Fragen, bissl drüber reden sollte man halt können.) gut läuft hat man das "Sehr gut".

SS10: Im Abgabegespräch waren 2-3 Fragen von den Vortagen inkludiert die auch zur Note beitragen.

Anm. SS10: Meiner Meinung nach zählten die 2-3 Fragen bei der Abgabe nicht wirklich zur Note, sie wurden nur gestellt um zu überprüfen ob derjenige zumindest Grundahnung in VHDL hat. Läuft das ganze Projekt bekommt man auch ein "Sehr Gut". Es sollte aber alles funktionieren ansonsten gehen die Noten ganz schnell auf Befriedigend bis Genügend runter auch wenn nur Kleinigkeiten fehlen. Man hat jedoch die Chance die Fehler noch auszubessern und das Projekt erneut abzugeben.

Die Spezifikation welche zu erstellen waren wurden auch bewertet (meiner Meinung nach sehr streng), gingen aber auch nicht wirklich in die Endnote mit ein. Dennoch ist es ratsam Anfangs etwas Zeit in die Spezifikation zu stecken weil es bei der Implementierung und Aufteilung in der Gruppe enorm hilft.

Zeitaufwand[Bearbeiten]

Wir haben mit den Tools etwas gekämpft. Wird sicher mit Skriptum besser. Unterschätzen sollte man's nicht, da das Projekt in einer Stunde in C++ o.ä. geschrieben wäre - VHDL ist anders :) Es können oft die trivialsten Dinge größere Probleme werden.

Es sollte allerdings kein Problem sein das Projekt innerhalb von einer 40h Labor Woche zu implementieren, was für die ECTS Anzahl wirklich nicht sonderlich viel ist.

Andere Meinung: Wenn man keine Erfahrung mit VHDL hat, sollte man wesentlich mehr Zeit einplanen. Es sind verschiedene Dinge wunderbar simulierbar, aber nicht vernünftig synthetisierbar. Es ist sicher sinnvoll sich vor dem eigentlichen Programmieren darüber zu informieren, wie man gut synthetisierbaren VHDL-Code schreibt. Insgesamt war unser Zeitaufwand sehr deutlich über den oben angegebenen 40h und wir waren sicher nicht die einzige Gruppe bei der das so war. Die Benotung war dann allerdings, wenn das ganze Ding irgendwann funktioniert, sehr nett. --HrevilO 10:59, 14. Jun. 2010 (CEST)

Weitere Meinung: Im SS10 waren 40h definitiv unrealistisch. VHDL lernen bzw. Verständnis für hardwarenahes Programmieren haben, ist schon beim Schreiben der Spezifikation sehr hilfreich. Auch sollte man den Aufwand für eine gute Spezifikation nicht unterschätzen. Für eine gute Statemachine können schon 1-2 Stunden anfallen. Die Implementierung kann, wenn es zu keinen Problemen (Designänderungen usw.) kommt, in 3 Wochen (bei einer sehr guten/detaillierten Spezifikation und gutem Teamwork) gemacht werden. --Skinner33 19:12, 24. Jun. 2010 (CEST)

Unterlagen[Bearbeiten]

Ab nächstem Semester Skriptum. Folien gibt's auf der LVA-Seite. Es gibt auch ein kleines Demobeispiel im Home-Verzeichnis. Da sind Makefiles dabei, sehr praktisch als Vorlage für's eigene Projekt.

Skriptum gab es im SS10 keines, für den Design-Flow könnte man allerdings auf das Skript von der Digitales-Design LU zurückgreifen. --HrevilO 11:05, 14. Jun. 2010 (CEST)

Dauer der Zeunigsausstellung[Bearbeiten]

SS10: Abgabegespraech am 31.5.2010, Zeugnis war am 24.6.2010 im TUWIS

Tipps[Bearbeiten]

  • Vom Demobeispiel ausgehen.
  • Nicht unterschätzen.
  • Nicht zu sehr auf Demobeispiele fixieren, die sind uU etwas verwirrend und komisch im Aufbau
  • Die Spezifikation nicht als unwichtigen Wisch vernachlässigen, eine gute Spezifikation kann nachher viel Arbeit sparen
  • Schnell lernen wie man mit Modelsim umgeht. Es ist schneller etwas dreimal zu Simulieren als einmal in die Hardware zu spielen!
  • Besser länger an einer detaillierten State Machine arbeiten, als diese aus einer Simpleren beim Programmieren ableiten.
  • Am Besten schon nach der ersten Spezifikationsabgabe mit Programmieren anfangen und nicht erst lange auf die Reviews warten.
  • Schon früh ordentliche Testbenches für die Module schreiben.
  • Warnings in Quartus ernst nehmen bzw. beseitigen! Eine ignorierte Warning kann schon zu einem Nachmittag unnötiger Fehlersuche führen.
  • Wenn eine Simulation in Modelsim nicht, wie erwartet, funktioniert kann es helfen das Design mit Quartus zu kompilieren (Warnings, Signal fehlt in Sensitivity List, ...).

Verbesserungsvorschläge / Kritik[Bearbeiten]

noch offen