Ein HDL-Projekt besteht nicht nur aus seinen Quelldateien. Spracheinstellungen, Bibliothekszuordnungen, Abhängigkeiten, generierte Quellen und Werkzeugversionen bestimmen mit, welches Design tatsächlich analysiert wird. Wenn ein Projekt nur auf dem Rechner seines ursprünglichen Entwicklers läuft, ist dieses Wissen häufig in lokalen Einstellungen versteckt. Reproduzierbarkeit bedeutet, dass ein anderer Arbeitsplatz aus demselben freigegebenen Stand einen erklärbaren Aufbau durchführen kann.
Logische Bibliothek und Verzeichnis unterscheiden
Eine VHDL-Bibliothek ist ein logischer Namensraum für analysierte Designeinheiten. Das physische Verzeichnis, in dem ein Simulator seine Daten ablegt, ist eine Implementierungsentscheidung des Werkzeugs. Ein Ordner namens common wird daher nicht automatisch zur Bibliothek common. Ebenso bedeutet eine vorhandene Datei noch nicht, dass ihre Entity oder ihr Package in der richtigen Bibliothek verfügbar ist. Diese Unterscheidung hilft, viele scheinbare Sprachprobleme als Konfigurationsproblem zu erkennen.
Der besondere Name work bezeichnet die aktuelle Arbeitsbibliothek des jeweiligen Analysekontexts. Er ist kein guter Ersatz für einen bewusst benannten gemeinsamen IP-Namensraum. Werden Quellen in verschiedene Bibliotheken analysiert, muss die Referenz dazu passen. Bei einer Fehlermeldung über eine fehlende Designeinheit sollten deshalb Name, Zielbibliothek, Analysefolge und die tatsächlich ausgewählte Architecture gemeinsam untersucht werden.
Eine einfache Struktur mit klaren Grenzen
project/
rtl/ # eigene synthetisierbare Quellen
tb/ # Testbenches und Referenzmodelle
scripts/ # Build- und Testeinstiege
config/ # Quelllisten und Spracheinstellungen
docs/ # Anforderungen und Bedienhinweise
vendor/ # freigegebene Fremdquellen oder Verweise
build/ # erzeugte Bibliotheken, Logs, ErgebnisseDie Namen sind ein Vorschlag, keine notwendige Norm. Wichtiger ist die Trennung von Eingaben und erzeugten Ergebnissen. Ein frischer Build darf ausschließlich erzeugbare Verzeichnisse neu anlegen. Quellen oder manuell gepflegte Constraints gehören deshalb nicht zwischen Simulatorartefakte. Auch eine schnell angelegte Diagnose-Datei sollte vor dem nächsten Bereinigungsschritt in einen sicheren, eindeutig benannten Bereich verschoben werden.
Versionieren Sie kleine Textdateien, die den Aufbau erklären. Große heruntergeladene Bibliotheken oder geschützte IP müssen nicht ungeprüft in ein Repository kopiert werden. Dokumentieren Sie stattdessen Bezugsquelle, freigegebene Version, Prüfsumme soweit verfügbar und erforderliche Nutzungsrechte. Ein reiner Downloadlink ohne Versionsbezug ist für eine langfristig nachvollziehbare Wiederherstellung zu wenig.
Abhängigkeiten explizit halten
Eine Package-Deklaration muss vor ihren Verwendern analysiert sein. Bei größeren Projekten reicht eine alphabetische Dateiliste dafür nicht aus. Entweder pflegt das Projekt eine korrekte Reihenfolge oder ein geeignetes Werkzeug ermittelt sie aus einem vollständigen Projektmodell. Beide Wege brauchen eine Quelle der Wahrheit. Wenn IDE und Simulationsskript unterschiedliche Dateimengen betrachten, sind widersprüchliche Diagnoseergebnisse vorprogrammiert.
VUnit dokumentiert einen Python-gesteuerten Projektaufbau und die Zuordnung von Quellen zu Bibliotheken. Sigasi dokumentiert wiederum externe Compileraufgaben auf Grundlage des ausgewählten Projekt-Targets. Diese Möglichkeiten können helfen, den Zusammenhang zwischen Entwicklungsumgebung und Simulation sichtbar zu halten. Ihre konkrete Konfiguration gehört zum Projekt und muss gegen die tatsächlich eingesetzten Versionen geprüft werden. VUnit user guide; Sigasi: Integrating with external tools.
| Versionierte Quelle | Logische Zielbibliothek | Aufgabe im Beispiel |
|---|---|---|
rtl/types_pkg.vhd | common | Gemeinsame Typen deklarieren. |
rtl/counter.vhd | design_lib | Den Baustein analysieren; benötigte Packages müssen verfügbar sein. |
tb/tb_counter.vhd | test_lib | Die Testbench analysieren; Referenzen müssen zu den Bibliotheken passen. |
Auf schmalen Bildschirmen lässt sich die Tabelle horizontal verschieben.
work bezeichnet die aktuelle Arbeitsbibliothek des jeweiligen Analysekontexts. Eine Quellliste muss Zielbibliotheken und Abhängigkeiten ausdrücklich beschreiben.
Generierte Quellen und FPGA-Bibliotheken
Generierte Dateien verdienen eine eigene Entscheidung: Sind sie reproduzierbar aus versionierten Eingaben ableitbar oder müssen sie als freigegebenes Ergebnis archiviert werden? Ein Generator benötigt möglicherweise dieselbe Version wie bei der letzten Freigabe. Festzuhalten sind daher Eingaben, Parameter und Werkzeugstand. Sonst kann ein scheinbar unveränderter HDL-Build nach einem Update andere Quellen erhalten.
FPGA-Herstellerbibliotheken werden häufig für eine bestimmte Simulator- und Werkzeugkombination vorbereitet. Behandeln Sie sie als versionierte Abhängigkeit und vermeiden Sie ein gemeinsam beschriebenes, ständig wechselndes Bibliotheksverzeichnis für alle Projekte. Verschiedene parallele Builds dürfen nicht versehentlich dieselben Artefakte überschreiben. Ein unveränderlicher vorbereiteter Bibliotheksstand plus projektbezogene Arbeitsbibliothek ist leichter zu kontrollieren.
Den sauberen Aufbau wirklich prüfen
Ein inkrementeller Lauf kann fehlende Buildschritte verbergen, weil alte analysierte Einheiten noch verfügbar sind. Ergänzen Sie deshalb regelmäßig einen Aufbau in einem neuen Ausgabeverzeichnis. Verwenden Sie dafür einen klar begrenzten Projektpfad; ein allgemein zusammengesetzter rekursiver Löschbefehl ist unnötig riskant. Der neue Aufbau soll sämtliche benötigten Eingaben selbst finden und bei fehlenden Abhängigkeiten verständlich abbrechen.
Zu jedem Ergebnis gehören mindestens Quellstand, Werkzeugversion, Testauswahl, Einstellungen und ein Zeitstempel. Wenn Zufall eingesetzt wird, kommt der Seed hinzu. Auch Umgebungsvariablen können relevant sein, etwa für Include-Verzeichnisse oder Lizenzserver. Geheimnisse dürfen dabei nicht ungefiltert in ein Buildprotokoll gelangen. Dokumentieren Sie die Bedeutung einer Einstellung, ohne vollständige Umgebungsabbilder zu veröffentlichen.
Eine Übergabe ist der stärkste Alltagstest
Bitten Sie eine zweite Person, ausschließlich mit der Projektanleitung einen kleinen Test zu starten. Jede mündliche Zusatzinformation ist ein Hinweis auf fehlende Dokumentation. Verbessern Sie die Anleitung danach und wiederholen Sie den Versuch auf einem getrennten Arbeitsverzeichnis. Das Ziel ist nicht eine besonders komplizierte Buildarchitektur, sondern ein verständlicher Einstieg, der kleine Änderungen und spätere Wiederholungen zuverlässig trägt.
Die Application Note zu reproduzierbaren Regressionen ergänzt diese Struktur um ausführbare Teststeuerung und Fehlerbehandlung. Der Beitrag über Syntaxprüfung, Linting und Simulation erklärt, welche Ergebnisse dabei getrennt aufbewahrt werden sollten.
Quellen und Stand
Recherche geprüft am 19.10.2026. VUnit user guide, Sigasi: Integrating with external tools.