Ein Fachportal der eVision Systems GmbH

EDA Praxis / Application Notes

Sigasi Visual HDL und Riviera-PRO: Externe Kompilierung einrichten

Ein dokumentierter Weg vom Sigasi-Projekt zum externen Riviera-Compiler, mit Diagnose und klar getrennter Simulation.

Abstrakte technische Illustration zur HDL-Entwicklung.

Problem und Ziel

Ein HDL-Projekt kann in der Entwicklungsumgebung plausibel erscheinen und erst beim später verwendeten Compiler eine Diagnose erzeugen. Ursache können werkzeugspezifische Regeln, abweichende Spracheinstellungen oder unterschiedliche Bibliotheken sein. Diese Note beschreibt, wie ein Sigasi-Projekt zusätzlich mit dem externen Compiler von Riviera-PRO geprüft wird. Ziel ist ein reproduzierbarer Compile-Schritt im Editor und eine verständliche Zuordnung seiner Ergebnisse. Ein erfolgreicher Compilerlauf wird ausdrücklich nicht als erfolgreich absolvierte Simulation ausgegeben.

Der Ablauf verwendet die aktuelle Sigasi-Visual-HDL-Dokumentation für VS Code. Die dort beschriebene Aufgabe heißt sigasiRivieraCompile. Historische Anleitungen für Sigasi Studio in Eclipse können andere Menüs und Konfigurationsdateien zeigen. Für ein neues Projekt sollte deshalb die Dokumentation zur tatsächlich installierten Produktgeneration verwendet werden. Ein entsprechender aktueller eingebauter Active-HDL-Task wird hier nicht behauptet. Sigasi: External compilers.

Voraussetzungen und Versionsbezug

  • Eine berechtigt nutzbare Sigasi-Visual-HDL-Installation in VS Code und ein funktionierendes Projekt-Target.
  • Eine berechtigt nutzbare Riviera-PRO-Installation mit erreichbaren Compilerprogrammen.
  • Ein kleines VHDL-Projekt ohne FPGA-Fremd-IP für den ersten Integrationsversuch.
  • Dokumentierte Spracheinstellungen, Bibliotheksnamen und tatsächliche lokale Installationspfade.
  • Ein getrenntes Arbeitsverzeichnis für erzeugte Compilerartefakte.

Quellenstand ist der 19.10.2026. Das aktuelle Sigasi-Downloadarchiv führte bei der Recherche 2026.4.1. Das ist ein dokumentierter Quellenstand und keine Behauptung, dass diese Version auf dem vorliegenden Rechner installiert oder für jedes Team bereits freigegeben wäre. Prüfen Sie nach Installation die Versionsanzeige und vergleichen Sie die verfügbaren Task-Eigenschaften mit dem dazugehörigen Handbuch. Sigasi Visual HDL Download Archive.

Editionen und Lizenzrechte müssen zum Einsatz passen. Das Sigasi-Handbuch unterscheidet insbesondere die Verwendung innerhalb der IDE von einer headless CLI im automatisierten Betrieb. Eine für diesen Versuch vorhandene Editorlizenz darf daher nicht ohne Prüfung als Recht zum Betrieb beliebiger CI-Runner interpretiert werden. Auch eine Simulatorinstallation allein bestätigt noch keinen verfügbaren Lizenzzugang. Verbindliche Konditionen ergeben sich aus der jeweiligen Lizenzvereinbarung. Sigasi editions and languages.

Architektur des Ablaufs

Versionierte Quellen + Sigasi-Projekt-Target
            |
            v
Sigasi-Projektanalyse und Task-Konfiguration
            |
            v
Externer Riviera-Compiler -> Compilerdiagnosen
            |
            v
Separater Simulationslauf -> Testbench-Ergebnis

Die zwei Ergebnisarten bleiben getrennt. Der Compiler untersucht den ausgewählten Quellbestand. Eine Simulation benötigt zusätzlich ein Top-Level, Elaborierung, Stimuli, Laufsteuerung und eine definierte Prüfung. Diese Trennung erleichtert auch die Fehlersuche: Ein Analysefehler wird zuerst in der Projektkonfiguration oder Quelle untersucht; eine später fehlgeschlagene Assertion gehört zur funktionalen Prüfung. Ein gemeinsamer grüner Status ohne diese Unterscheidung wäre irreführend.

Schritt 1: Ein kleines Target vorbereiten

Legen Sie in einem neuen Arbeitsverzeichnis die Dateien rtl/counter.vhd und tb/tb_counter.vhd aus der Testbench-Note ab. Erstellen Sie mit der installierten Sigasi-Projektoberfläche ein Target mit dem Namen counter_demo. Ordnen Sie beide Dateien derselben logischen Bibliothek zu und stellen Sie VHDL-2008 ein. Die genaue Projektbeschreibung sollte durch die Oberfläche beziehungsweise den dokumentierten Import der verwendeten Version erzeugt werden.

Kontrollieren Sie danach das Projektmodell, bevor Sie den externen Compiler einschalten. Die Testbench muss ihre DUT-Instanz finden; die IEEE-Packages müssen aufgelöst werden. Nehmen Sie bewusst noch keine Hersteller-IP hinzu. Ein minimales Projekt reduziert die Anzahl gleichzeitiger Ursachen und erleichtert später den Vergleich mit einem automatisierten Test. Speichern Sie die erzeugte Projektkonfiguration gemeinsam mit den Quellen.

Schritt 2: Compiler separat auffindbar machen

Prüfen Sie im vorgesehenen Terminal, welche Riviera-Installation tatsächlich angesprochen wird. In gemischten Entwicklungsumgebungen können mehrere Programme namens vcom im Suchpfad liegen. Ein erfolgreicher Aufruf beweist daher noch nicht, dass das richtige Produkt gestartet wurde. Verwenden Sie bei Unsicherheit den tatsächlichen vollständigen Pfad und dokumentieren Sie die Ausgabe der Versionsabfrage nach dem lokalen Herstellerhandbuch.

Achten Sie auf die Umgebung des Editors. Ein nachträglich geänderter Suchpfad wird in einer bereits laufenden Anwendung möglicherweise nicht übernommen. Starten Sie den Editor mit der vorgesehenen Umgebung neu oder tragen Sie den passenden Installationspfad in die Task-Konfiguration ein. Lizenzvariablen und geheime Lizenzdateien gehören nicht in ein öffentliches Projekt. Die Startanleitung kann ihren Zweck benennen, ohne vertrauliche Werte zu speichern.

Schritt 3: Aufgabe über Sigasi erzeugen

Öffnen Sie die Projects View, wählen Sie das Target und starten Sie im Kontextmenü Automate Designflow. Wählen Sie den externen Compiler Riviera Compile. Lassen Sie Watch-Modus und automatischen Start beim ersten Versuch ausgeschaltet. So bleibt jeder Lauf bewusst ausgelöst. Das Handbuch beschreibt diesen Weg und die erzeugte Datei .vscode/tasks.json. Sigasi: Integrating with external tools.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "EDA: Riviera Compile counter_demo",
      "type": "sigasiRivieraCompile",
      "target": "counter_demo",
      "watch": false
    }
  ]
}

Die gezeigte Datei ist ein eigenes minimales Konfigurationsbeispiel. Der Wert von target muss exakt zum bestehenden Target passen. Der Compiler wird hier über den Suchpfad gefunden. Bei einer abweichenden Installation ergänzen Sie installationPath mit dem wirklichen absoluten Verzeichnis der Programme. Übernehmen Sie keine beispielhaften Pfade ungeprüft und speichern Sie eine persönliche Maschinenkonfiguration nicht versehentlich als allgemeingültige Vorgabe.

Schritt 4: Einen kontrollierten Compilerlauf ausführen

Starten Sie die Aufgabe über die VS-Code-Befehlspalette mit Tasks: Run Task. Lesen Sie das Terminalprotokoll vom Beginn an. Prüfen Sie ausgewähltes Target, analysierte Dateien und die erste Fehlermeldung. Folgefehler sind oft nur Konsequenzen eines zuvor nicht analysierten Packages. Korrigieren Sie zunächst die erste Ursache und starten Sie denselben Lauf erneut, bevor weitere Warnungen unterdrückt werden.

Als Gegenprobe fügen Sie kurz einen eindeutigen Syntaxfehler in einer lokalen Arbeitskopie ein. Der externe Lauf muss fehlschlagen beziehungsweise die passende Diagnose anzeigen. Entfernen Sie den Fehler anschließend und prüfen Sie erneut. Dieser Versuch belegt den Weg zur Quelle und zurück. Er belegt weder vollständige Sprachunterstützung noch die funktionale Korrektheit des Zählers. Halten Sie den Versuch mit tatsächlichen Ausgaben im Teamprotokoll fest.

Schritt 5: Erweiterungen einzeln hinzufügen

Erst nach einem stabilen Minimallauf kommen zusätzliche Bibliotheken und Fremd-IP hinzu. Die dokumentierten Felder libraryCfg, precompiledLibraries und zusätzliche Compilerargumente müssen zur realen Umgebung passen. Eine Bibliothek als vorkompiliert auszunehmen erzeugt sie nicht und kontrolliert auch nicht automatisch ihre Versionskompatibilität. Dokumentieren Sie deshalb Herkunft, Simulatorversion und den tatsächlichen vorbereiteten Bibliotheksstand.

Watch-Modus ist anschließend eine Komfortoption. Prüfen Sie zuerst, wie sich die Aufgabe bei raschem Speichern mehrerer Dateien, beim Wechsel des Targets und bei nicht verfügbarem Compiler verhält. Halten Sie einen manuell auslösbaren Compile-Schritt als klaren Diagnoseweg bereit. Automatische Wiederholung sollte nicht dazu führen, dass wichtige Fehlermeldungen zwischen vielen aufeinanderfolgenden Ausgaben übersehen werden.

Simulation und Fehlerdiagnose

Für eine anschließende Simulation verwenden Sie einen getrennten, dokumentierten Einstieg. Die VUnit-Note zeigt einen solchen Test-Runner. Der dort ausgewählte Simulator muss wiederum zur verfügbaren Installation passen. Compiler- und Simulationskonfiguration sollten dieselben Quellen, Bibliotheken und Spracheinstellungen verwenden; andernfalls prüft der zweite Schritt womöglich einen anderen Stand.

  • Programm nicht gefunden: Suchpfad der tatsächlichen Editor-Sitzung und installationPath prüfen.
  • Bibliothek fehlt: logische Zuordnung, Bibliothekskonfiguration und vorbereitete Abhängigkeiten prüfen.
  • IDE und Compiler widersprechen sich: Sprachversion, Target, Defines und Dateimenge vergleichen.
  • Compiler erfolgreich, kein Testergebnis: Es wurde nur kompiliert; den separaten Simulationsschritt starten.
  • Lizenzfehler: vorhandene Berechtigung und lokale Installation klären; keine Evaluierung stillschweigend aktivieren.

Tatsächlicher Teststatus und Grenzen

Dokumentarisch geprüft, nicht in Sigasi oder Riviera-PRO ausgeführt. Für diese Note stand keine nachgewiesen berechtigte lauffähige Herstellerumgebung zur Verfügung. Das JSON-Beispiel wurde syntaktisch validiert. Die referenzierte eigene VHDL-Testbench wurde separat mit GHDL 6.0.0 unter Windows geprüft; daraus folgt kein Nachweis der Sigasi-Riviera-Integration. Für den Einsatz im eigenen Projekt sind der beschriebene Normal- und Fehlerlauf in der tatsächlich vorgesehenen Umgebung zu protokollieren.

Als nächster Schritt empfiehlt sich die Übertragung auf einen kleinen Ausschnitt Ihres echten Projekts. Bringen Sie dazu Quellstruktur, Bibliotheksliste und die benötigten Werkzeugversionen in eine Beratung zum Entwicklungsablauf ein. Eine konkrete Konfiguration lässt sich gezielter prüfen als eine allgemeine Frage nach der Zusammenarbeit zweier Produktnamen.

Quellen und Stand

Recherche geprüft am 19.10.2026. Sigasi: External compilers, Sigasi: Integrating with external tools, Sigasi editions and languages, Sigasi Visual HDL Download Archive.

Sie möchten diese Vorgehensweise in Ihrem Projekt einsetzen?

Entwicklungsablauf gemeinsam prüfen

EDA PRAXIS / NEWSLETTER

Neue Perspektiven.
Direkt ins Postfach.

Praxiswissen zu HDL, Simulation und Verifikation. Neue Beiträge, Application Notes und Hinweise zu passenden Werkzeugen.