Hi an alle! Ich will gerade anfangen die Dokumentation zu meiner Diplomarbeit zu schreiben, die den VHDL-Entwurf und die Implementierung verschiedener Komponenten für einen FPGA beinhaltet. Nun stellt sich mir die Frage, wie man das Ganze am besten in einer Diplomarbeit darstellt. Ist es sinnvoll den VHDL-Code mit in den Text zu nehmen und diesen einzeln zu erläutern??? Oder sollte man eher den Code in den Anhang packen und mehr mit Blockschaltbildern und Signal-Zeit-Diagrammen zur Erläuterung arbeiten? Das erscheint mir eher sinnvoll. Welche Software würdet ihr zur Darstellung empfehlen? Visio, Corel Draw oder gibt es noch andere Alternativen? Sollte man so allgemeine Dinge, wie Aufbau eines FPGAs oder VHDL ansich mit in die Einführung nehmen, oder ist das unnötig, da schon x-mal beschrieben? Kann mir vorstellen, dass einige von euch ihre DA auch auf dem Gebiet geschrieben haben oder schonmal DOKUs zu Hardwareentwurf getippt. Also wie geht man da am besten ran? Freu mich auf eure Anregungen! MFG Dude
Hallo Dude > Ist es sinnvoll den VHDL-Code mit in den Text zu nehmen und > diesen einzeln zu erläutern??? Oder sollte man eher den Code > in den Anhang packen und mehr mit Blockschaltbildern und > Signal-Zeit-Diagrammen zur Erläuterung arbeiten? Ich finde es nicht sinnvoll den Quelltext mit in die Arbeit zu nehmen. Dein Professor hat bestimmt keine Lust die 1000 Zeile durchzulesen und dann auch noch zu verstehen. Der VHDL-Code ist ja auch nur die Umsetzung der Arbeit, die eigentliche Arbeit war davor ein Wirkmodell zu erschaffen, welches du dann mit Hilfe von FPGAs umgesetzt hast. Arbeite lieber mit Blockschaltbildern, die kann man leichter überblicken und verstehen. Visio kann ich dir nicht empfehlen, viel zu umständlich. Nimm lieber ein einfaches CAD Programm. Selbst eagle ist besser geeignet als Visio. > Sollte man so allgemeine Dinge, wie Aufbau eines FPGAs oder > VHDL ansich mit in die Einführung nehmen, oder ist das unnötig, > da schon x-mal beschrieben? Ich hatte das nur kurz in meiner Arbeit erwähnt, ansonsten würde ich mich an de Professor orientieren. Wurden bei ihm schon viele Arbeiten mit Programmierbarer Logik geschrieben? Dann kann man sich diesen Punkt langsam sparren und nur im Abkürzungsverzeichnis erwähnen. > Kann mir vorstellen, dass einige von euch ihre DA auch auf dem > Gebiet geschrieben haben .. Ich brauchte den FPGA nur als Hilfsmittel um schnelle Bitfolgen zu generieren und anschließend die Bitfehler zu zählen. MfG Holger
Ich hab in meiner DA nur Blockschaltbilder drin gehabt. Und Flussgraphen machen sich auch ganz gut, um einen Sachverhalt zu beschreiben. Für den VHDL-Code interessiert sich am Ende keiner mehr im Detail. Ausserdem kann man Blockbilder und Flussgraphen auch noch in dem Vortrag zur Verteidigung verwursteln, wo Codeschnipsel eher deplaziert wirken würden. Solche Bilder habe ich mit Adobe Framemaker erstellt, da ich meine ganze DA damit geschrieben habe. Ist wohl aber eher die Ausnahme, weil nicht weit verbreitetes Programm.
Dude wrote: > Ist es > sinnvoll den VHDL-Code mit in den Text zu nehmen und diesen einzeln zu > erläutern??? Oder sollte man eher den Code in den Anhang packen und mehr > mit Blockschaltbildern und Signal-Zeit-Diagrammen zur Erläuterung > arbeiten? Das erscheint mir eher sinnvoll. Welche Software würdet ihr > zur Darstellung empfehlen? Visio, Corel Draw oder gibt es noch andere > Alternativen? Kommt darauf an. Was ist der genaue Aufgabenbereich Deiner Arbeit? Steht die VHDL-Implementierung im Vordergrund? Spielt Effizienz eine Rolle? Benutzt du irgendwelche Tricks, um die Algorithmen umzusetzen? Für Übersichten ist generell eine grafische Darstellung sinnvoll. Zur Erklärung der Umsetzung schadet ein Stück Code sicher nicht. Für die Diagramme werde ich wohl Dia oder oodraw nehmen. > Sollte man so allgemeine Dinge, wie Aufbau eines FPGAs oder VHDL ansich > mit in die Einführung nehmen, oder ist das unnötig, da schon x-mal > beschrieben? Kommt darauf an. Wenn du auf spezielle Features der einzelnen FPGAs angewiesen bist, dann musst du das natürlich dokumentieren. Wenn du dem Synthesetool diese Arbeit überläßt, dann vielleicht nur kurz anreißen, was aus deinem Design letztendlich geworden ist. Eventuell hast du Entwurfsalternativen und kannst diese quantitativ vergleichen... > Kann mir vorstellen, dass einige von euch ihre DA auch auf dem Gebiet > geschrieben haben oder schonmal DOKUs zu Hardwareentwurf getippt. Also > wie geht man da am besten ran? Hm. Ich habe noch 3 Monate, also noch ein bisschen Zeit. :-) Wie Holger schrieb, schau mal andere Arbeiten an, die an dem Lehrstuhl geschrieben wurden und ungefähr in die gleiche Richtung zielen. Frag' doch einfach mal Deinen Betreuer nach den Erwartungen. Eventuell hast Du schon eine Grobgliederung und kannst sie mit ihm durchsprechen. -- stefan
Ich hatte zwar keine Zeile VHDL gehabt, dafür jede Menge "C". In die schriftliche Ausarbeitung habe ich nur paar knifflige Sachen rein genommen, die eine Erläuterung wert waren, und sonst das Projekt als Anhang auf die CD gebrannt mit dem CS Autostart und einer HTML-"Präsentation".
Erstmal besten Dank für die vielen Anregungen! Also wegen vorherigen DA muss ich meinen Prof mal kontakten. Bin momentan auf dem Standpunkt, dass ich es wohl weitgehend mit Blockschaltbildern und Flussdiagrammen machen werde. Für timing-kritische Sachen auf Interfaces denke ich auch an einige Signal-Zeit-Diagramme. Gibt es hierfür geegnete Software zur Darstellung, oder sollte man z.B. mit der Waveform von Modelsim arbeiten? Man kann die ja relativ gut anpassen. Gruß Dude
Für die Doku einer aufwändigen Schaltung / eines Systems benötigst Du jeweils a) einen logischen data flow für die relevanten events b) eine logische Blockstruktur auf Funktionsebene c) einen signal data flow auf Realisationsebene d) eine Schaltungsstruktur auf Realisationsebene e) ein Timing-Diagramm Realisationsebene f) Deailhardwaree Je nachdem wie das Modul aussieht und was es tut, können einige Punkte aus Banalitätsgründen entfallen. a und b kommen meist aus dem Lastenheft und beschreiben, was das System macht. Der logische Datenfluss wäre z.B. "Werteaufnahme", "Werteaufbereitung", "Wertespeicherung", hinzu kämen die Entscheidung (Baumdiagramm). Es existieren meist mehrere Flüsse für normalfall, Fehlerfall, Testfall etc. Dieser Fluss sollte sich im logischen Blockdiagramm 1:1 wiederfinden. Z.B. stehen dort die Blöcke, "Io-interface", "Prozesseinheit", "Überwachungseinheit", "Testinterface", "Rohdatenspeicher", "Servicedatenspeicher" etc. Auf dieser Ebene sind meist Hardware und Software gemischt dargestellt, da die einzelnen logischen Funktionen kombiniert realisiert werden. Für Hardware und Software (getrennt) exisiteren dann (auf Pflichtenheftebene) ... ... die Punkte c und d , die das ganze dann in die Realisation spiegeln. Hier tauchen dann im Schaltbild auf Hardwareebene konkrete Chips, Wandler (und was das FPGA angeht) die HDLs auf, die Zähler, Multiplexer, RAMS etc enthalten. Bezüglich des Punktes c, wären z.B. pipelines zu beschreiben, wann und in welchem clock sie was machen. Ausserdem steht hier die Erklärung zur Funktion ereignisgesteurter Signale. Punkt e geht nochmal eins runter und beschreibt (meist in der design spec) das microtiming. Das braucht man meist nur für die äussere Hardwareanbindung und Busse / uC-Interfaces. Es gibt noch den Punkt f, der die Hardwareebene hierzu beschreibt, den gibt es aber beim FPGa nicht, da alles durch die CLBs und IOBs realisiert ist und nicht nochmal gesondert dokumentiert werden muss. Aussgangseite handelt es sich dabei meist um das RAM oder eine CPU - die ebenfalls fix sind.
Da ich in der selben Situation wie einst Dude bin, greife ich diesen Beitrag einfach mal wieder auf. Ich würde gern wissen, ob es für VHDL sowas ähnliches wie UML gibt? Für eine gute Dokumentation ist das ja nicht gerade schlecht. Ansonsten gibt es nur die Möglichkeit Blockstrukturen und Flussdiagramme zu verwenden und wenn ja, gibt es hier eine Norm wie sowas auszusehen hat? Gruß Torben
UML für VHDL? Meinst du dass dir UML anhand vom Code erstellt wird_ Das glaube ich nicht, aber RTL ist ja auch nicht schlecht, wenn es um eine grobe Darstellung geht. Visio kann jedes Kind, verstehe nicht, wie man Visio mit einem Cad-Programm vergleichen kann. Zu deiner eigentlichen Frage, ich würde Code auf die CD packen und in der Arbeit nur das Verhalten einzelner Module beschreiben.
"Visio kann jedes Kind, " Hat aber nicht jeder zur Hand! Ich würde mich über ein Tool freuen, mit dem man post dokumentieren kann. Ich ärgere mich immer über die mangelnden Funktionen der Tools, die oft am Notwendigen vorbei gehen. Habe schon mit der Quartus IDE, der Xilinx ISE, Mentors HDL-Designer und Siemens Data Flow gearbeitet und bin da ehre unzfrieden, was import angeht. Die können allesammt nicht mal das, was sie behaupten, nämlich einen sauberen effizienten Top-Down-Entwurf mit geeigneten Manipulationsmöglichkeiten während des Designs. Sobald man irgendwelche Hierarchien eingeführt hat, wird das System starr und unbeweglich, womit es den Sinn verliert. Deshalb nutzten nur wenige solche Systeme.
Angehängte Dateien:
-
organigramm.png
11 KB
Um den Thread nochmal auszugraben. Also ich habe meine gesamten Hirarchien mit MS Visio gestaltet. Für die Signalflusspläne fand ich die ganz normalen Blockshapes am besten geeignet. Um Hierarchien gut abzubilden eignen sich hervorragend ein Organigramm (Geschäft->Organigramm).
Der Simulator spuckt doch schon die Timingdiagramme aus. Die muß man jetzt nur noch irgendwie exportieren, schön Beschriften, und einen Erklärenden Text dazuschreiben (ein Blockdiagram passend zum Timingdiagramm hilft auch)
Dude schrieb: > Ich will gerade anfangen die Dokumentation zu meiner Diplomarbeit zu > schreiben, die den VHDL-Entwurf und die Implementierung verschiedener > Komponenten für einen FPGA beinhaltet. Sowas wie Übersichtsdiagramme, strukturbeschreibungen, Strukturmodelle, Ablaufverhalten, Pipeline Struktur, Pipeline Timing und eigentlich alles andere auch - entstehen ... ... VOR und WÄHREND des Designprozesses, dann diese Arbeiten SIND der Design Prozess. Am Ende werden nur die letzten Änderungen und Flicks nachgetragen und natürlich die Testergebnisse und deren Interpretation, sowie die Schlussfolgerung für weiteres Vorgehen.
Noch ne Anmerkung: Zur direkten Source-Doku empfiehlt sich 'doxygen'. Generiert auch ganz brauchbare Diagramme. Ist allerdings eher für Low-Level-Codedokumentation gedacht.
Hallo zusammen, um auch noch meinen Senf dazuzugeben für VHDL in Bachelor/Master/Dipl-Arbeiten hat sich folgendes bewährt: - Prinzipiell bietet sich für solch Code- und Verweiselastigen Arbeiten vor allem TeX an. MS-Word ist denkbar ungeeignet und LibreOffice/OOO macht es auch nicht besonders komfortabel. - Vollständige IPs oder Komponenten kommen in VHDL/Verilog-Form in den Anhang. Verweise im Text nicht vergessen! - Einige wenige(!) ausgewählte Beispiele kann man auf die wichtigsten Zeilen eindampfen und die ausgeblendeten Zeilen z.B. durch [..] kenntlich machen. Wenn so etwas auftaucht muss es auch einen Sinn haben. Nur mal eben auf eine Zeile verweisen macht da noch keinen Sinn. Wenn es aber beispielsweise den zentralen Kern oder einen sehr wichtigen Ablauf wiedergibt, dann bitte auch erläutern. - Zur Visualisierung bietet sich UML sehr wohl für die Digitaltechnik/VHDL/Verolog an. In Frage kommen beispielsweise Sequenzdiagramme, Zustandsdiagramme und Aktivitätsdiagramme. In umfangreichen Projekten taucht eigentlich immer ein Zustandsautomat auf, der lässt sich hervorragend in UML beschreiben. Auch hier auf das wesentliche beschränken, denn nicht immer ist die größtmögliche Detailtiefe sinnvoll oder notwendig. Und natürlich Hierarchien in UML visualisieren. Ich liste auch hier mal ein paar Programme auf, die frei verfügbar sind: TeX: LaTeX/MikTeX, TeXMaker (empfohlen, da plattformübergreifend und Code<->PDF-Wechsel möglich, jeweils mit "Listings"-Toolbox, Vorlagen/Tutorials gibt es zu Hauf -> googeln. Diagramme: InkScape, LibreOffice/OpenOffice Draw, yEd (graphML-Editor, einen Blick Wert!), PaPDesigner Vor der Niederschrift bitte immer erst einmal ordentlich informieren, denn sonst macht ihr euch unnötig viel Arbeit. Aufbau/Struktur und Tools vorher abklären und das ganze skizzieren. Rechtzeitig anfangen meint hier auch nicht vier Wochen vor Abgabetermin, sondern mindestens 3 Monate. Unbedingt von unabhängigen Dritten Korrektur lesen lassen. Die müssen auch nicht vom Fach sein!
Danke René, für die ausführliche Beschreibung, hinsichtlich der Dokumentation von VHDL-Sourcen. Ich glaub ich sollt UML mal gescheit lernen. René B. schrieb: > TeX: LaTeX/MikTeX, TeXMaker (empfohlen, da plattformübergreifend und > Code<->PDF-Wechsel möglich, jeweils mit "Listings"-Toolbox, > Vorlagen/Tutorials gibt es zu Hauf -> googeln. Aber ich finde als besten LaTex-Editor das Plugin Texlipse für Eclipse. Vorteile: - guter filebrowser - Codevervollständigung - Liste bei \ref{} mit alen referenzierbaren labels - Templatevorlagen - Vorwärts und inverse Suche in PDF Editoren - In kombination eines SVN-Server, gute Versionsverwaltung - .... Ich könnt noch viel mehr aufzählen. Ich bin echt begeistert davon und kann jedem empfehlen für Latex Dokumente Eclipse zu verwenden.
Angehängte Dateien:
-
inst_fetch.png
17 KB
Ich muss hier auch mal ein Beispiel posten. Das ist nicht mehr aktuell im Projekt. Die graphische Darstellung war doch ab und zu schon mal Hilfreich, was in welcher Datei abgeht und ob man nicht Signale doppel generiert. gezeichnet ist die Sache mit Inkscape und es lohnt sich, von der Zeichnerischen Möglichkeiten ausreichend. Es ist aber kein UML.
René C. schrieb: > Beitrag "Re: Dokumentation VHDL für Diplomarbeit" > > Reme B. = Rene D. ? nein. ungleich Ich bin nicht Rene B. Die Frage hatte ich auch schon.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.