Hallo zusammen, ich habe aktuell die Aufgabe, mich in ein fremdes VHDL Projekt einzuarbeiten. Dieses besteht aus nicht weniger als 116 .vhd Dateien, die natürlich ineinander verschachtelt sind. Um einen Überblick zu erhalten, habe ich mir ein Baumdiagramm geschaffen. In diesem zeichne ich ein, welches entity in welcher vhd Datei eingebunden wurde. So ist eine gute Übersicht antstanden, was das topfile ist und welche Datei wo eine Rolle spielt. Nun habe ich das Problem, dass ich nicht weiter weiss, wie ich mir den tieferen Sinn des Projektes erschließe. Die einzelnen Funktionen sind mir nur ganz grob bekannt. Ich habe also nur eine sehr grobe Funktionsbeschreibung und die Spezifikationen des Chips. Wie die Specs eingehalten wurden und vor allem wie es umgestezt wurde, dazu fehlen mir jegliche Angaben. Im Detail sieht das dann so aus: Kryptische Variablen-Namen, schlechte Dokumentation im Code (war ja klar!) und dazu kommt noch, dass er Urheber dieses Projektes nicht mehr greifbar ist. Gibt es hier Erfahrungen für die Herangehensweise an eine solche Aufgabe? Hangle ich mich nun von oben nach unten, oder von unten nach oben im Baumdiagramm? Ich habe schon versucht, die diversen vhd Dateien in kleinere Funktionseinheiten zu zerlegen und diese losgelöst zu verstehen. Aber aufgrund der undurchsichtigen Abkürzungen bei den Variablen fehlt dann der Bezug zur Außenwelt und das fehlende Verständnis für die Integration in das Gesamtprojekt. Ich wäre für Hinweise in diesem Bezug dankbar. Vielen Dank! MfG Andi
Bei Altera im Quartus ist ein RTL-Viewer Tool. Das zeichnet selber Übersichtsdiagramme. Also einfach mal versuchen, den Code mit Quartus zu übersetzen, und dann sich den RTL-Graphen zeichnen lassen.
Andreas B. schrieb: > Dieses besteht aus nicht weniger als 116 .vhd Dateien, > die natürlich ineinander verschachtelt sind. Weil ich einen simplen Addierer locker aus 4 Dateien beschreiben könnte, wäre es mal wichtig, die reale Größenordnung abzuschätzen. Da ist interessant: Wann wurde das Originaldesign erstellt? Zielplattform: ASIC oder FPGA? Falls FPGA: Welches? Wie voll ist das?
Ich zeichne in solchen Situationen immer endlos viele Blockdiagramme und gehe das Design von oben nach unten durch. Das Ziel ist dabei, Funktionsgruppen zu erkennen und Teile abstrahieren zu können.
Hallo, Zielplattform ist ein ASIC und die 116 .vhd Dateien umfassen 31853 Zeilen. Abzüglich der Kopfblöcke und der paar Kommentare kommt also trotzdem noch richtig viel zusammen. Das Projekt kann also in meinen Augen als "groß" bezeichnet werden. Das Projekt stammt von 2008-2009. Ich werde den Hinweis mit Quartus mal weiter verfolgen und das Ergebnis mit meinem Diagramm vergleichen. Vielleicht habe ich ja noch Fehler gemacht. Vielleicht gibt es ja auch eine Möglichkeit im ISE. Dort gibt es ja auch einen RTL Viewer und vielleicht helfen mir die schematics weiter. Ansonsten wäre mein nächster Schritt die in/out-Ports der Dateien in einer Art Blockdiagramm aufzuzeichnen um zu schauen, welche Signale wohin übergeben und wo genutzt werden. Aber das könnte viiiiele Stunden dauern. Oder gibt es auch hier Automatismen? Vielen Dank für alle bisherigen Antworten! MfG Andi
Für den Chip müsste es ja vermutlich eine Spec geben, die aussagt, was das Teil machen soll. Da würde ich mir mal den Datenpfad aufzeichnen, und schauen wie sich das auf Dein schon gezeichnetes Blockschaltbild passt. Als nächstes wäre sicher eine Toplevel-RTL-Funktional-Simulation sinnvoll. Wenn Du Glück hast, findet sich irgendwo im Projekt noch sowas (da es sich um einen ASIC handelt, bin ich mir fast zu 100% sicher dass extensiv simuliert wurde). Mit der Simulation, dem Blockdiagramm und der Spec solltest Du dann in der Lage sein, mal grundsätzlich einiges einzugrenzen, z.B. Unterscheidung in: - Datenpfad, Processing-Units (DSP, etc.) - Controlling (FSM, Register, uProc etc.) - I/F, Bridges - Memory, DMA - Eingekaufte IP's (ev. separate Blockspec suchen...) Vielleicht sind bis da auch einige der Namen (Signal & Entities) nicht mehr so kryptisch, wie sie am Anfang schienen (ausser sie wurden absichtlich nachträglich durch krypische ersetzt im Stile von "Security through Obscurity") Viel Erfolg
Und was genau soll dann deine Aufgabe sein, nachdem Du das Re-Engineering durchgefühtt hast?
Ein so großes Projekt einfach mal so voll zu durchblicken ist warscheinlich, selbst wenn du es entwickelt hast, schwer. Sich an den Stil des Vorgängers zu gewöhnen und sich einzelne Funktionseinheiten anschauen und in das Gr0ße Bild einzufügen wird wohl erstmal die Aufgabe sein. Versuch doch einfach mal eine neue Funktion bzw. Feature in das jetzige Design einzufügen. An der Grundlegenen Struktur wirst du ohne Redesign eh nichts ändern können. Nach meiner Erfahrung dauert es seine Zeit sich wirklich efektiv in ein Fremdes Design (das schlecht Dokumentiert) ist einzuarbeiten. Jedoch hilft damit Arbeiten am meißten (vor allem wenn man unter Druck steht) ;-)
Bei VHDL-Entwicklern scheint sich hierarchisches Design, Top-Down-Entwurf und saubere zielführende Dokumentation noch nicht herumgesprochen zu haben, oder wie ist es zu erklären, dass es über 100 Files mit Code gibt, deren Zusammenhang erst umständlich rekonstruiert werden muss, statt ihn einfach in einer Doku einzusehen und den Zusammenhang zwischen Anforderung und Realisation zu erkennen. Macht ihr keine reviews? Gibt es keine Dokumenationsanforderungen? Wie soll der Code gepflegt und Abkömmlinge verwaltet werden, wenn es keine Übersichten gibt?
Frank schrieb: > saubere zielführende Dokumentation Die gibt es in sehr, sehr vielen Softwareprojekten entweder gar nicht, oder sie ist unvollständig, oder sie ist von einer schlechten Qualität. Mit VHDL speziell hat das eher wenig zu tun, denke ich. Siehe auch das Bild "How it was documented" in dem allseits bekannten und beliebten Cartoon: http://www.projectcartoon.com/cartoon/55791
Ein Tip: Mit GHDL lassen sich auf simple Weise HTML-Kreuzreferenzen erstellen: ghdl --xref-html $(FILES) Klickbar, ergo gut zu navigieren. Moeglichweise kommt man auch mit Doxygen zu einer guten Uebersicht. Gruss, - Strubi
N'Abend, GHDL wollte ich dir auch empfehlen, gibt zumindest mal eine brauchbare Crossreference. 30K Zeilen ist schon was. Aber das 'Ding' muss doch irgendwas machen, das auch bekannt und beschrieben ist. Und das kannst du ja mit Testbenches mal nachvollziehen. Testfall beschreiben der was elementares im Design ausloest und dann mal die Signale der im Toplevel eingebundenen Komponenten anschauen, zur Not mit von dir eingefuegten Aliasen oder Hilfssignalen wegen der kryptischen Namen (und sich auch die Prozesse im Toplevel mal genau ansehen). Damit solltest du denke ich recht schnell wenigstens einen Ueberblick ueber die Funktion kriegen und auch welche Komponenten was machen. Danach kommen dann die Details... Wenn du rausgefunden hast, wo es bei bestimmten Operationen zuckt, ist auch der Rest nicht sooo schwierig.
Poste einfach den Code im Forum wie analysieren das dann für Dich :-) ;-)
Typischer Fall für ein Studentenprojekt. Einfach 10 Studies dranstellen und dokumentieren lassen. Dann jeden eine Testbench machen lassen und die Timingdiagramme auswerten. Dann den Studies die Aufgaben zuteilen :-)
...und einer darf dann am Schluss alles zusammenfassen. Genau so entstehen an manchen Instituten die Doktorarbeiten.... :-)
Strubi schrieb: > Ein Tip: Mit GHDL lassen sich auf simple Weise HTML-Kreuzreferenzen > > erstellen: > > ghdl --xref-html $(FILES) Wenn man ISE gewohnt ist und man alles anklicken kann, ist GHDL echt eine Umstellung. Da muss ich mir mal anschauen, wie ich ihm vor allem alle librarys beibringen kann. Denn wenn er nicht fehlerfrei kompilieren kann, erzeugt er auch keine html Dateien :) Vielen Dank! Ich habe erstmal angefangen das Projekt im ISE zu verarbeiten, habe alle fehlenden librarys angelegt und nun meckert er noch rum:
1 | "Cannot find <attributes> in library <synopsys>. Please ensure that the library was compiled, and that a library and a use clause are present in the VHDL file." |
Ich vermute mal, dass es noch eine Leiche von Bibliotheken ist... muss ich erstmal klären, wo und wie die verwendet wird und wo ich die unter Umständen herbekomme. Bei der GHDL Installation war eine dabei, aber die ist nicht die richtige, weil die Fehlermeldung auch nach Erstellen der synopsys Bibliothek die gleich bleibt. MfG Andi
Moin, > Wenn man ISE gewohnt ist und man alles anklicken kann, ist GHDL echt > eine Umstellung. Da muss ich mir mal anschauen, wie ich ihm vor allem > alle librarys beibringen kann. Denn wenn er nicht fehlerfrei kompilieren > kann, erzeugt er auch keine html Dateien :) > Zu den Libraries hat René Doss eine sehr brauchbare kurze Einführung geschrieben: http://www.dossmatik.de/ghdl/ghdl_unisim.pdf Klappt bei mir gut, ausser, dass manche Xilinx-Primitiven (v.a. die 'obfuscated coregen' Sachen so übel geschrieben sind, dass sie illegale Werte produzieren). Punkto "klickbar" hast du natürlich recht. Allerdings amortisiert sich das Erstellen eines Makefiles nach maximal zwei Tagen wiederkehrender Simulations/Entwicklungs-Zyklen, auch für Isim. Pfeil oben und Return ist einfach schneller als klicken, ausserdem verbrät mein ISE ne Menge Rechenzeit nur fürs Anzeigen des "Ich arbeite gerade"-Rädchens. Mit GHDL/gtkview lässt sich so im Schnitt ca. 3x schneller arbeiten, besonders, wenn man Signale und gewisse Bedingungen schnell anspringen muss. >
1 | "Cannot find <attributes> in library <synopsys>. Please ensure |
2 | > that the library was compiled, and that a library and a use clause are |
3 | > present in the VHDL file." |
> Ich vermute mal, dass es noch eine Leiche von Bibliotheken ist... muss > ich erstmal klären, wo und wie die verwendet wird und wo ich die unter > Umständen herbekomme. Bei der GHDL Installation war eine dabei, aber die > ist nicht die richtige, weil die Fehlermeldung auch nach Erstellen der > synopsys Bibliothek die gleich bleibt. Kenne das "attributes" package nicht. Kommt das von einem 'use synopsys.attributes.all' statement? Vermutlich musst Du irgendwelche synopsys-Library-Extensions im Source in GHDL importieren? Noch so ein Aspekt: ich nehme erst mal Isim, um die ganze Hierarchie und die zugehörigen Files aufzulösen (wenn ich nich schon einfach mal ALLE VHDL-Files importiere), konvertiere dann die .prj-Datei in 'ne Dateiliste fürs Makefile und dann geht's an die Auflösung/xref-htmlisierung per GHDL. Irgendwie hat sich dieser Parallel-Ansatz bewährt (ich bin recht ungeduldig wenn Weg A nicht geht, und probiere dann Weg B), auch wenn man sich mit der doppelten Anzahl an Tools beschäftigen muss... Grüsse, - Strubi
Also die Beste Herangehensweise an ein fremdes, großes VHDL Projekt ist immer noch, die Beine in die Hand zu nehmen und zu verduften! So ein Zeug überlässt man den Anfängern und schreibt eine sauber SPEC und baut der Kram selber
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.