TGI Praktikum

VHDL

VHDL ist ein Sprachstandard, mit dem man bei der Wahl der Tools prinzipiell die Wahl zwischen einer Vielzahl unterschiedlicher Hersteller hat.

Angesichts der Komplexität der meisten ernstzunehmenden Lösungen, fällt die Wahl gerade im Hinblick auf die Praktikumsdurchführung nicht immer leicht. In der Regel gilt: Weniger ist meistens mehr.

Das Problem ist, daß wir VHDL lediglich lehren, um Stundenten zumindest ein Gefühl für Rechnerarchitektur auf Ebene der Schaltungslogik zu vermitteln. Die Mehrheit der Werkzeuge werden allerdings eher dafür gebaut, reale Schaltungen zu entwerfen und auch zu implementieren. Zwischen den zwei Anliegen liegen leicht einige 10.000 € Anschaffunskosten, mehrere Millionen Zeilen Code, leider auch eine entsprechende Komplexität (sprich: Einarbeitungszeit).

Projektseiten

Zu den Ergebnissen einer Praktikumsarbeit gehören Dokumentation sowie Quelltexte, Listings, Mitschnitte ausgewählter Testläufe (z.B. in der JMic), Meßreihen, etc.

Während der Durchführung des Praktikums werden alle diese Ergebnisse in einer Website zusammengefasst. Bewertet werden nur die Ergebnisse die sich auch in der Website wiederfinden. Das impliziert das keines eurer Dokumente per Mail an mich geht. Statt dessen wird der Inhalt der Site inkrementell erweitert.

Das gibt einerseits euch die Möglichkeit, die Arbeit als eine Art Produkt zu gestalten, und das ist mehr als nur ein paar Zeilen Code und ein README. Andererseits macht es mir das Leben leichter, weil Verwaltung der kompletten Dokumentation von 10-15 Gruppen einen ganz schön auf Trab halten kann, ich zum Ende des Praktikums die Ergebnisse ganz gerne vergleiche. Auf diese Weise wird die Wahrscheinlichkeit geringer wird, daß ich was [positives ;)] übersehe.

Die Projektsite sollte bevorzugt auf dem durch die RBG betriebenen Webserver der Informatik zum liegen kommen.

Inhalt und Struktur der Site

Die Praktikumsordnung sieht neben der Lösung nur die unten beschriebenen Dokumente zur Benotung vor. Dem schließe ich mich natürlich an, das heißt alle in dieser Sektion beschriebenen Vorschläge sind optional und können ignoriert werden.

Im Prinzip reicht also eine kleine Frontseite mit Links zu allen Dokumenten, Programm- und Datenfiles. Wer es aber richtig gut machen will, sollte zumindest über folgende Erweiterungen nachdenken:

Die folgenden Bestandteile sind größtenteils freiwilliger Natur. Die Projektmanager sollten sich zumindest mit dem Gedanken daran auseinandersetzen, jenseits einer zumindest mit Eckdaten versehenen Projektseite wird allerdings kaum etwas mir wirklich verlangt.

Versionierung

In der Praxis kommen Projekte mit mehr als einem Entwickler (eigentlich nicht mal diese) nicht ohne Versionsmanagement aus.

Dafür gibt es Tools, z.B. für Quelltextverwaltung (SCM). Weiterhin Dokumenten- und Content-Managementsysteme, die wir aber hier sicher kaum einsetzen werden. Sinnvoll ist aber bereits, auch die Entwicklung der Dokumentation ihrerseits zu dokumentieren.

Das bedeutet zunächst das alle Revisionen ein und des selben Dokumentes auf der Projektseite verfügbar bleiben. Alte Versionen werden also auf keinen Fall gelöscht. Zur Vereinfachung des Zugangs dienen höchstens Links die z.B. auf die jeweils neueste Version eines Dokumentes verweisen.

Im Minimum erweitert man die Dateinamen um eine Versionsnummer und belässt es dabei. Schon realistischer sind Changelogs, d.h. Zusammenfassungen aller einer jeweiligen Version zugrund liegenden Änderungen.

Meetings & Minutes

Bei größeren Projekten kommt man nicht umhin, über alle in Treffen der Arbeitsgruppe besprochenen Themen, getroffenen Entscheidungen und Argumentation die zu diesen geführt haben, offene Punkte, etc. zu protokollieren. Das ist typischerweise Aufgabe des Projektmanagers.

Solche Dokumentation werden in einem separaten Teil der Site archiviert und zumindest nach Datum sortiert. Sie beinhalten Aufstellungen aller bei der Besprechung anwesenden (und nicht anwesenden), Datum und Uhrzeiten, Tagesordnungspunkte und alle relevanten Inhalte und Entscheidungen der Besprechung. Auch Punkte bei keine Entscheidung erreicht oder deren Entscheidung aufgeschoben wurde.

Projektmanager die für die Praxis lernen möchten sollten es versuchen.

News und Summaries

Für komplexe Projekte die sich schnell und in unterschiedlichen Richtungen weiterentwickeln sind Zusammenfassungen sinnvoll.

Im einfachsten Fall beschränkt man sich auf eine gut strukturierte, tabellarische Aufstellung aller Änderungen im Projektstatus. Die wird nach Datum sortiert (die aktuellsten ganz oben) typischerweise gleich auf der Einstiegsseite plaziert.

Content Syndication ist in wenigen Jahren ein eigener Zweig des World Wide Web geworden, der vielen TGI-Studenten vielleicht schon vertraut ist.

Vor allem wer sich für elektronisches Publizieren interessiert (und das sollte dieser Tage praktisch jeder sein der sich mit Informationsverarbeitung befasst) sollte einen Versuch wagen.

Formate

Sämtliche Dokumentation ist in HTML zu erstellen. Pro Dokument ist mindestens eine separate Datei anzulegen. Wer gerne viel schreibt kann natürlich auch weiter untergliedern, das setzt jedoch eine Inhaltsangabe mit entsprechenden Verweisen voraus.

Die Dokumentation ist neben der Präsentation einer der wesentlichsten Teile des Praktikums. Ich kann oft nur den Teil eurer Entwicklungen beurteilen der auch dokumentiert oder präsentiert worden ist. Das Praktikum besteht allerdings aus mehr als nur die Implementierung. Es soll euch auch den Entwicklungsprozeß als solchen nahebringen.

Der besteht im Entwicklungsprozeß aus Phasen wie Anforderungsanalyse, Spezifikation, System Design, etc. Vieles davon wird euch natürlich erst im Hauptstudium beigebracht werden, aber das Praktikum kann zumindest ein Anfang sein.

Die Praktikumsordnung sieht ein Anzahl unterschiedlicher Dokumente vor, im Folgenden in Reihenfolge ihrer Erstellung und Lieferung:

1. Pflichtenheft
2. Spezifikation
3. Dokumentation

   Diese wiederum ist aufgegliedert in

   1. Benutzerdokumentation
   2. Entwicklerdokumentation

Das klingt als ob mehr Zeit für die Dokumentation verwendet werden muß als schon für Lösung und Implementierung. Das ist nicht ganz richtig. Wichtig ist, daß die Mehrheit dieser nicht sehr lang sein muß – die Aufgaben sind es ja auch nicht. Es geht lediglich darum, daß das jeweilige Dokument inhaltlich vollständig ist.

Programme und Dateien

Die eigentliche Lösung der Praktikumsaufgabe besteht, Abhängig vom Teilbereich, aus:

Quelltexte und Assemblercode

• VHDL-Programmcode
• IA-32-Assemblercode (NASM)
• MIC-Speicher/Registerdumps

Traces ausgewählter Testläufe

Mikroprogrammierung

Ablaufprotokolle der Mic, etc.

VHDL

Testbenches (eine weitere entity, welche nur dazu dient die Loesung zu testen) werden gerne akzeptiert. Bei mit Waveform-Editoren erstellten Tests werden eben solche in einem für die jeweilige Entwicklungsumgebung passenden Format benötigt.

Insgesamt

Alles, was es dem Betreuer eine Beurteilung der korrekten Funktion eurer Lösung leichter macht.

Meßreihen

z.B. Assemblerprogrammierung: Performancevergleiche bei Experimenten mit unterschiedlichen Varianten der Lösung.

Alle dieser Dateien kommen auf die Projektseite. Wo es sich anbietet, können sie wie die Dokumentation im HTML-Format mit eingebunden werden

Ältere Versionen der Mic konnten das. Bei der jMic bin ich mir nicht sicher).

Aus immer wieder aktuellem Anlaß: Wenn es etwas zu übersetzen gibt, übersetze ich den Code selber. Mir also, idealerweise noch per Mail, Binaries zuzuschicken ist völlig unnötig.

Bitte die Datenfiles nicht in HTML formatieren. Schon gar nicht hexkodierte Mikroprogramme. Der einzige mir bekannte Fall in dem man das ganz gerne macht sind PGP-Keys in ASCII-Transferkodierung.

Bedeutung

Das Pflichtenheft (Requirements) beschreibt, wie der Name schon sagt, was die Ergebnisse eures Projektes leisten sollen.

Das klingt überflüssig, wenn die Aufgabenstellung wie im TGI-Praktikum eigentlich schon vorgegeben ist. Tatsächlich ist der am häufigsten gemachte Fehler, die Aufgabenstellung abzuschreiben und gleich zur Spezifikation überzugehen.

In der Praxis sollte die Bedeutung solcher Dokumente jedoch nicht unterschätzt werden. Für mich als Betreuer (nennt es Kunde) repräsentiert es den Erwartungshorizont dessen was ich bei Abnahme erwarten darf. Es präzisiert also vielmehr die Erwartungen, die mit meiner Aufgabenstellung bereits formuliert wurden.

Dieses Dokument wird nun aber von euch als Bearbeiter geschrieben, nicht etwa von mir. Diese Kleinigkeit impliziert einen entscheidenden Unterschied: Es wird nicht nur festgelegt was das Ergebnis leisten wird, sondern auch was es nicht leisten wird.

Kurz: Je präziser die Analyse und deren Ergebnisse im Pflichtenheft dargestellt sind, desto besser eure Position wenn ihr eure Ergebnisse bei der Präsentation verteidigen müsst, d.h. ob das Result auch dem Rückblick auf die Anforderungen stand hält.

Inhalt

Im folgenden ein paar Anhaltspunkte für den Inhalt. Die Liste erhebt keinen Anspruch auf Vollständigkeit.

Vorsicht: Die vorliegende Aufteilung deckt sich nicht unbedingt mit einer sinnvollen Gliederung. Diese bleibt euch überlassen.

Autor, Projektmitarbeiter

Klar. Namen und Rollenverteilung bzw. Verantwortlichkeit aller Gruppenmitglieder.

Datum, Revision

Änderungen werden normalerweise wie oben beschrieben in der Regel durch Revisionsnummern und ChangeLogs ihrerseits dokumentiert.

Anforderungen (Soll-Analyse)

Der Inhalt der Soll-Analyse baut i.d.R. zunächst auf der Aufgabenstellung auf. Wichtig bei der Soll-Analyse ist dabei die Beschränkung auf eine Black-Box Sicht, d.h. es werden keine unnötigen Details über die Realisierung vermitteln.

Beispiel Mikroprogrammierung: Zusammenfassung der zu realisierenden Befehle, jeweils mit deren Adressierungsart.

Die Darstellung in der Black-Box Sicht beschränkt sich auf:

Eingabe

Eingabeparameter, sowie deren im Rahmen der Aufgabenstellung zulässige Wertebereiche.

Ausgabe

Ausgabeparameter, und wieder deren im Rahmen der Aufgabenstellung zulässige Wertebereiche.

Operation

Da die Funktionsbeschreibung schon vorgegeben ist, erscheint der Punkt zunächst trivial. In vielen Fällen ist dem jedoch nicht so. Ein Beispiel: Was passiert mit unzulässigen oder zumindest nicht sinnvollen Eingabewerten? Gibt es solche? Ist eine Erkennung möglich? Ist das Resultat dann auch definierbar?

Kleiner Tip: Diese Sichtweise ähnelt i.d.R. stark der des Benutzers auf das fertige System. Sie kann später für die Benutzerdokumentation entsprechend aufbereitet werden.

Vorsicht: Diese Beschreibung ist nicht unbedingt indentisch mit der Benutzerdokumentation. Warum? Sie geht noch nicht genau auf die (Programmier-)schnittstelle ein (Diese ist abhängig von Anforderungen, die an dieser Stelle im Entwicklungsprozeß noch gar nicht betrachtet wurden).

Ist-Analyse

Die Ist-Analyse beschreibt die Ausgangssituation, also die Umgebung in der das Projekt durchgeführt wird und in der die Ergebnisse eurer Arbeiten zum Einsatz kommen.

Vorsicht: Es sollte bis hier klar geworden sein, das das Projekt nicht nur aus etwas Code besteht.

Zielsystem

Beschreibung aller im Hinblick auf die Anforderungen relevanten Eigenschaften, z.B. der mikroprogrammierbaren Maschine (jMic), des Zielrechners (ASM).

Dokumentationen

Welche Dokumentation ist verfügbar?

Infrastruktur

Was für steht zur Durchführung des Projektes zur Verfügung, bzw. was wird benötigt? Welche Software und Tools kommen zum Einsatz?

Arbeitsplan

Der Arbeitsplan beschreibt den geplanten Ablauf der Projektdurchführung:

• Identifizierte Teilaufgaben
• Arbeitsschritte und eventuelle Abhängigkeiten
• Aufteilung der Leistungen auf einzelne Gruppenmitglieder
• Zeiteinteilung
• Fertigstellungstermine
• Überprüfungs- und Abgabetermine

Lösungsansatz

Eine Vielzahl der gestellten Aufgaben erlaubt Alternativen in der Vorgehensweise. Entscheidet euch für eine Lösung, aber begründet eure Wahl. Alternativen sollten diskutiert und abgewägt werden. Dieser Teil ist ein sehr wichtiger Bestandteil der Spezifikation.

Bei komplexeren Aktionen sollte zunächst die globale Vorgehensweise dargelegt werden. In der Regel bezeichnet dies den Algorithmus, den ihr implementieren wollt. Die Beschreibung solcher Algorithmen teilt das Vorgehen zunächst in numerierte Einzelschritte auf. Diese können dann durch erneute Teilung in Unterschritte weiter verfeinert werden.

Achtung: Bei komplexen Schritten zunächst die allgemeine Vorgehensweise kurz beschreiben, dann daraus resultierende Einzelschritte verfeinern. Selbst bei einfachsten Algorithmen greift diese Vorgehensweise: Egal wie einfach der Algorithmus aus Sicht des Autors ist – die zugrunde liegende Idee wird immer durch ein oder mehrere einleitende Sätze zusammengefasst.

Zielgruppe

Die Beschreibung dieser Schritte erfolgt nicht etwa in einer formalen Notation, und schon gar nicht in Maschinensprache, sondern in ganzen Sätzen. Hier ist vor allem auf die Zielgruppe zu achten: Der Leser ist in der Regel mit Rechnerarchitekturen im Allgemeinen vertraut, aber nicht unbedingt mit dem konkret vorliegenden System. Programmierer können auf Basis der Spezifikation das System so implementieren wie der Verfasser es vorgesehen hat. Andere, z.B. der Projektbetreuer, können auf Basis der Spezifikation die Funktionweise des Systems nachvollziehen.

Beispiel Mikroprogrammierung: Begrifffe wie Datenbus, Adreßbus, ALU, Befehlszähler etc. können vorausgesetzt werden. Bezug auf R0 ist akzeptabel, der Ausdruck Y-MUX=AB gehört ganz klar nicht in die Spezifikation, sondern eher in die Entwicklerdokumentation.

Man gehe in der Spezifikation auf relevante Eigenschaften der Architektur ein, natürlich ohne die schon im Pflichtenheft inventarisierte Dokumentation nochmal zu schreiben, es genügen Verweise. Die einzelnen Schritte sollten schließlich detailliert genug dargelegt werden um glaubhaft zu machen, daß Ihre geplante Vorgehensweise auf Basis der vorliegenden Maschine tatsächlich realisierbar ist. Die geforderte Genauigkeit der Spezifikation beantwortet zu jedem Schritt u.A. schließlich folgende Fragen:

• Wie sind die Daten strukturiert?

  Mikroprogrammierung: Über die nötige Präzision solcher Angaben kann man streiten. Für komplexe Datenstrukturen reichen im Prinzip schon verbindliche Bezeichner für einzelne Felder. Da man bei der Spezifikation aber schon präzise auf die Zielarchitektur eingeht, sind auch hier schon exakte Angaben mit Basis- und Offset-Adressen legitim.

• Welchen Weg nehmen die Daten?

  Mikroprogrammierung: Welche Funktionseinheiten werden dabei benutzt?

  Solche Beschreibungen, die relativ genau auf die Mikroarchitektur eingehen, tendieren dazu die Dokumentation durch Wiederholungen unleserlich zu machen. Es bietet sich in solchen Fällen an, einen gegebenen Schritt in der Mikroarchitektur einmal zu beschreiben und danach einfach mit Verweisen zu arbeiten.

• Hat die jeweilige Funktionseinheit laut Dokumentation auch die geforderte Funktionalität?

  Es genügt im Zweifelsfall ein Hinweis, daß auf solche Fähigkeiten Rücksicht genommen, bzw. diese mit Hilfe der Dokumentation verifiziert wurden (Verweis auf Kapitel/Abschnitt).

Benutzerdokumentation

TBD

Entwicklerdokumentation

TBD

Organisatorisches

Dauer

Der Vortrag sollte ca. 10 Minuten dauern.

Ort

Die Vorträge finden üblicherweise in den Räumen 01.06.011 oder 01.06.020 statt (FMI Südseite, 1. Stock, Nähe HS2). Diese Räume verfügen über Videoprojektoren. Bevorzugt ist 01.06.020, hauptsächlich wegen der größeren Projektionsfläche.

Ausstattung

Bevorzugt sind Vorträge mit Videoprojektor auf eigenem Notebook.

Wer keine Hardware mitbringen kann oder will bekommt sie natürlich gestellt. Ohne weiteres geht in der Regel Powerpoint, OpenOffice oder schlicht PDF. In jedem Fall bitte vorher anmelden, da ich sonst nichts mitbringen kann.

Für den Notfall sind auch Overheadprojektoren vorhanden. Das Verfahren ist jedoch in den letzten Jahren ein wenig aus der Mode gekommen. Wer für das richtige Leben lernen möchte versucht es bitte in Software.

Inhalt

Keine Prosa! Versucht bitte nicht, eure Ausarbeitung als Präsentation verkaufen zu wollen. Es braucht Folien, keine Lesung.

Folien dienen zur Unterstützung beim Zuhören. In dem Sinne werden sie nicht einmal wirklich gelesen. Sie stellen nur einen Seitenkanal zur Ergänzung eurer Erläuterungen dar.

Kein Code! Manchmal ist der Versuchung, Codefragmente aufzulegen, schwer zu wiederstehen. Wer es nicht lassen kann, findet bei mir die einmalige Gelegenheit es zu versuchen, unter der Bedingung es nicht noch einmal zu tun. Es geht garantiert schief, aber ich kann damit leben.

Ich kann es allerdings auch entsprechend benoten.

Beispiel Mikroprogrammierung: Nichts verbindet mehr als gemeinsam ein paar Minuten auf ein paar hundert Byte tabellarisch formatierten Hexcode und Mnemonics zu starren, während der stolze Entwickler versucht zu erläutern was dort alles gleichzeitig passiert. Probiert es einfach zu Hause mit Freund/Freundin oder Familie einmal aus.

Struktur

10 Minuten sind eine kurze Zeit. Im folgenden ein paar Vorschläge zur Strukturierung. Diese können allerdings als unverbindlich betrachtet werden.

Aufgabe

Die Aufgabe muß zunächst erläutert werden, vor allem da mehr Praktikanten als Betreuer anwesend sind. Uninteressante Details können ausgelassen werden um Zeit zu sparen.

Lösung

Algorithmus in Grobdarstellung (siehe entsprechenden Teil der Spezifikation). Wo es angebracht erscheint, geht auf Alternativen und Begründungen ein.

Implementierung

Die folgenden Anmerkungen beziehen sich mehrheitlich auf die Mikroprogrammierung. Für VHDL oder Assembler gilt sinngemäß ähnliches, nur eben mit anderer Entwicklungsumgebung.

Wie oben beschrieben: Bitte kein Code. Lediglich die interessanteren Teile, i.d.R. die jenseits Load/Store-Operationen hauptsächlichen Vorgänge im Algorithmus sollten beschrieben werden. Kniffligen Teilen, beispielsweise wenig genutzten Features in der ALU, sollte i.d.R. der Vorrang gegeben werden, da sie oft einen Kern der Aufgabenstellung ausmachen.

In der Regel beschränkt man sich auf eine abstrakte Sicht der Funktionalen Einheiten und eine auch für Außenstehende leicht nachvollziehbare Zusammenfassung der Operationen darauf. Das bedeutet ihr beschreibt das Zusammenspiel der einzelnen Maschinenteile, gerne auch grafisch.

Gewonnen hat, wer am wenigsten erklären mußte um plausibel zu klingen. Nicht etwa versuchen möglichst viel Stoff zu vermitteln. Die Vortragszeit ist bewußt so kurz gewählt.

Durchführung

Kurze Zusammenfassung: Wieviel Zeit wurde benötigt? Wie wurde diese auf einzelne Teilarbeiten aufgeteilt. Entsprach diese Zeiteinteilung dem Arbeitsplan? Wurde irgendwo unverhältnismäßig viel Zeit aufgewendet?

Format

Eine Einführung in Präsentationstechniken würde hier den Rahmen sprengen. Daher nur ein paar grundsätzliche Hinweise.

Schriften

Die allerminimalste rechtfertigbare Fontgröße auf Folien liegt bei 18pt. Der Standard deutlich über 24pt. Das ist vor allem wichtig wenn wir in Raum 01.06.11 sind, da Projektor und Auflösung dort deutlich kleiner sind als mittlerweile üblich.

Serifen dienen nur bei gedrucktem Material zur Verbesserung der Lesbarkeit. Auf Bildschirmen und Projektionsflächen kehrt sich dieser Effekt interessanterweise um. Auch bei Präsentationen sind daher serifenlose Schriftarten (z.B. Helvetica, Arial, Vera) zu bevorzugen.

Auflösung

Standardauflösung ist auch 2005 immer noch 1024x768px, mehr geben die Projektoren in der Regel nicht her. Wer mit seinem Notebook noch nicht präsentiert hat sollte prüfen ob das Umschalten der Auflösung reibungslos klappt. Das gilt insbesondere unter Linux. Die Präsentation muß aber auch auch bei 800x600px noch lesbar sein.

Kontrast

Eierschalenfarbene Schrift auf diesem speziellen hellgelbem Hintergrund mag am Vorabend auf dem heimischen CRT noch besonders feinsinnig gewirkt haben. Für Wandprojektionen bei Tageslicht kommen nur kontrastreiche Farbschemata in Frage.

Vorsicht, selbst einige der in modernen Office-Paketen mitgelieferten Templates gehen diesbezüglich manchmal von recht gewagten Voraussetzungen aus.

Bei Unsicherheit: Schwarz auf Weiß. Das funktioniert praktisch immer. Ansonsten: Im Winter Hell auf Dunkel, im Sommer umgekehrt.

Animationen

Animationssequenzen, z.B. in PowerPoint, sind in der Regel keine Gute Idee. Das gilt vor allem für herumfliegende Textfragmente. Animationen, die zur Visualisierung von z.B. Prozeßabläufen dienen sind dem gegenüber natürlich prima.

Wenn sie zur Verdeutlichung des vorgestellten Materials dienen, sind sie aber tatsächlich ein gutes Werkzeug. Allerdings auch ein zeitaufwändiges in der Vorbereitung und nie ein Ersatz für gut strukturierten Inhalt.

Audio

Um Gottes Willen keine Sounduntermalung.

Seid versichtert: Es gab öfters mal Gründe warum das hier extra erwähnt werden musste.