Sigasi mit KI-Agenten nutzen: HDL-Code im Projektkontext analysieren

Ziel: Ein Agent soll Befunde erklären, nicht Projektwissen erraten

Ein KI-Agent kann einen unbekannten Bezeichner in VHDL sehr schnell durch einen plausiblen Namen ersetzen. Ob dieser Name im richtigen Package existiert, zur verwendeten Bibliothek gehört und im gewählten Target sichtbar ist, muss jedoch aus dem Projekt hervorgehen. Diese Application Note verbindet deshalb eine kleine, überprüfbare Änderung mit einer reproduzierbaren Analyse. Sigasi liefert den Sprach- und Projektkontext; der Agent untersucht Dateien und formuliert eine Korrektur. Ein getrennt aufgezeichneter Werkzeuglauf entscheidet, ob die Analyse danach ohne Befunde der festgelegten Schwere abgeschlossen wurde.

Der Ablauf verwendet ein eigenes Zweidateienprojekt mit einem absichtlich falsch geschriebenen Konstantennamen. Er benötigt weder Kunden-IP noch ein FPGA-Board. Der fachliche Nutzen liegt weniger im Tippfehler als in der Arbeitsweise: Dateimenge festlegen, Diagnose lesen, bestehende Deklaration finden, Änderung begrenzen und erneut prüfen. Damit entsteht eine Grundlage für größere Aufgaben, ohne eine erfolgreiche Namensauflösung mit funktionsrichtigem Hardwareverhalten zu verwechseln.

Dokumentationsstand, Voraussetzungen und Zugangswege

Quellenstand ist der 19.10.2026; das Sigasi-Releaseverzeichnis führt die Generation 2026.4 einschließlich 2026.4.1. Hier wurde keine Sigasi-Version ausgeführt. Die frühere Sigasi AI Chat/SAL-Funktion ist laut Handbuch seit 2026.2 entfernt; alte SAL-Einrichtungsanleitungen bilden diesen Ablauf daher nicht ab. Sigasi release notes; Sigasi AI Chat: historical feature status.

Für die eingebettete CLI beschreibt Sigasi die Nutzung der Enterprise-Lizenz innerhalb des VS-Code-Terminals. Die eigenständige CLI verlangt Enterprise (CI); die gewöhnliche Enterprise-Erweiterungslizenz reicht dafür nicht. Prüfen Sie den tatsächlich vorgesehenen Betriebsweg vor dem ersten Lauf. Eine vorhandene Agentenanmeldung ersetzt diese Werkzeugberechtigung nicht. Sigasi CLI in Sigasi Visual HDL; Sigasi CLI.

• Ein lokal nutzbares Sigasi Visual HDL mit passender Lizenz und ein vollständig geladenes Projekt.
• Python 3 für den mitgelieferten Wrapper; keine zusätzlichen Python-Pakete erforderlich.
• Ein Agent mit bewusst freigegebenem Zugriff auf diesen Beispielordner und das vorgesehene Terminal.
• Ein eigener, nachvollziehbarer Arbeitsstand: Kopie des Beispiels oder Versionsverwaltung, keine vermischten ungespeicherten Änderungen.

Codex CLI kann lokale Dateien bearbeiten und installierte Programme aufrufen. Diese Note nutzt genau diesen Shell-Weg und setzt keine direkte Sigasi-Codex-MCP-Verbindung voraus. Sigasis MCP-Handbuch nennt GitHub Copilot in VS Code sowie VS-Code-Abkömmlinge wie Cursor; daraus folgt keine automatische Kompatibilitätszusage für jeden Agenten. Codex CLI; Sigasi MCP server.

Schritt 1: Das vollständige Miniprojekt bereitstellen

Laden Sie das Sigasi-Agenten-Miniprojekt herunter und entpacken Sie es in einen eigenen Ordner. Lesen Sie zuerst requirements.md und AGENTS.md. Beide gehören zur Aufgabe: Das erste Dokument beschreibt das Verhalten, das zweite begrenzt die erlaubten Änderungen und verlangt echte Werkzeugergebnisse. Die Referenzdatei dient dem späteren Vergleich und gehört absichtlich nicht zum analysierten RTL-Target.

ai-sigasi/
  project.sigasi
  requirements.md
  AGENTS.md
  rtl/design_config.vhd
  rtl/event_counter.vhd
  reference/event_counter.fixed.vhd
  run_analysis.py
  test_wrapper.py
  TEST_RESULTS.json
  README.md

Der Zähler besitzt eine Breite von vier Bit. An der steigenden Taktflanke hat der synchrone, aktive High-Reset Vorrang; andernfalls erhöht ein aktives Enable den Wert um die vorhandene Schrittweite. Ohne Enable bleibt der Wert erhalten. Ein Überlauf soll modulo 16 erfolgen. Diese Festlegung stammt aus unserem Beispiel und ist keine Aussage über ein Herstellerdesign. Die Fehlerkorrektur darf diese Anforderungen nicht verändern.

Das Package design_config enthält COUNT_WIDTH und INCREMENT_STEP. Der Zähler importiert dieses Package bereits, verwendet aber an einer Stelle INCREMENT_STPE. Ein Agent soll deshalb zuerst die existierende Deklaration suchen. Eine zusätzliche gleichnamige lokale Konstante würde den Schreibfehler nur verdecken und die zentrale Konfiguration umgehen.

{
  "name": "eda_ai_sigasi",
  "targets": {
    "rtl": {
      "libraryMapping": {
        "rtl": "work"
      },
      "languageMapping": {
        "vhdlVersion": "vhdl-2008"
      }
    }
  }
}

Die Projektbeschreibung legt VHDL-2008 fest und ordnet nur rtl der Bibliothek work zu. Die Sigasi-Dokumentation beschreibt diese manuellen Target-Zuordnungen. Prüfen Sie nach dem Öffnen, dass tatsächlich beide RTL-Dateien zum Target gehören. Ein fehlerfreier Bericht über die falsche oder leere Dateimenge wäre für diese Aufgabe wertlos. Sigasi modular project description.

Schritt 2: Werkzeug und Ausgangszustand sichtbar machen

Öffnen Sie das Terminal, in dem der Agent später arbeiten soll. Prüfen Sie dort die Versions- und Hilfeausgabe der tatsächlich aufgelösten CLI. Unter Windows heißt der dokumentierte Einstieg sigasi-cli.bat, unter Linux sigasi-cli. Wenn die eingebettete CLI nach Installation oder Update nicht erreichbar ist, beschreibt Sigasi ein erneutes Öffnen des Terminals. Tragen Sie keine erfundenen Installationspfade ein. Sigasi CLI; Sigasi CLI in Sigasi Visual HDL.

sigasi-cli.bat --version
sigasi-cli.bat --help
python test_wrapper.py
python run_analysis.py

Die ersten beiden Befehle sind die Windows-Variante; unter Linux entfällt .bat. Führen Sie alle Python-Befehle im entpackten Projektordner aus. Bei einer abweichenden Installation kann --cli dem Wrapper den realen vollständigen Programmpfad übergeben. Halten Sie vor dem Agenteneinsatz Version, Target und vorhandene Änderungen fest. Ein Agent darf einen nicht gefundenen Befehl nicht durch die Behauptung ersetzen, die Analyse sei wahrscheinlich sauber.

Der Verify-Aufruf verwendet JSON und --fail-on-warning: Sigasi dokumentiert Exit 16 für erreichte Befundschwellen und Exit 7 für fehlende Lizenzrechte. Unser Wrapper übersetzt diese Prozesswerte in eigene Ergebniszustände. Sigasi CLI.

sigasi-cli.bat verify --target=rtl --json --fail-on-warning --out=diagnostics.json .

Der direkte Befehl zeigt die zugrunde liegende Schnittstelle. Für den eigentlichen Versuch verwenden Sie den Wrapper: Er legt für jeden Lauf ein neues Unterverzeichnis in build an. Dadurch kann ein alter Bericht nicht versehentlich als Ergebnis einer fehlgeschlagenen neuen Ausführung dienen. Standardausgabe, Fehlerausgabe, Aufruf und Prozessstatus bleiben dem jeweiligen Lauf zugeordnet. Geben Sie einem Agenten das Protokoll des aktuellen Laufs, nicht eine beliebige Datei mit passendem Namen.

1. 01Target und Quellen

   rtl → work; VHDL-2008. Die Dateimenge bleibt nachvollziehbar.

2. 02Sigasi CLI

   verify mit Warnungsschwelle ausführen; echten Prozessstatus aufzeichnen.

3. 03Frischer JSON-Bericht

   Projekt, Befunde und Laufzuordnung prüfen; keine alte Ergebnisdatei übernehmen.

4. 04Begrenzte Agentenänderung

   Deklaration finden, nur den erlaubten RTL-Abschnitt korrigieren und Diff zeigen.

↶ Danach zurück zu 01: dieselbe Analyse erneut ausführen. Anforderungen, Target und Schwellen bleiben unverändert.

Abbruchpfad

Werkzeug oder Lizenz fehlt, Zeitgrenze erreicht, Bericht unlesbar: blockiert melden. Kein positiver Analysestatus ohne auswertbaren aktuellen Lauf.

Ablauf des eigenen CLI-Beispiels. Die Sigasi-Integration ist dokumentationsbasiert; dies stellt keine direkt getestete Codex-MCP-Anbindung dar.

Schritt 3: Die Diagnose in eine begrenzte Agentenaufgabe übersetzen

Beim fehlerhaften Ausgangscode ist eine Diagnose zum nicht auflösbaren Namen zu erwarten. Der genaue Sigasi-Wortlaut wurde hier nicht gemessen. Verlangen Sie vom Agenten eine Untersuchung der tatsächlichen Meldung und der importierten Packages. Eine brauchbare Begründung nennt die gefundene Deklaration, ihre Datei und den Zusammenhang mit dem betroffenen Ausdruck. Das ist stärker als die bloße Ähnlichkeit zweier Wörter.

Read requirements.md, AGENTS.md and project.sigasi first.
Run python run_analysis.py and inspect this run's real diagnostics.
Find the existing declaration for the unresolved identifier.
Change only rtl/event_counter.vhd; preserve behavior and interfaces.
Do not edit requirements, thresholds, project mappings or reference files.
Run the same analysis again. Report the exact command, exit status,
changed lines and remaining findings. Stop if the tool or license is unavailable.
Do not claim simulation, synthesis or timing verification.

Dieser eigene Arbeitsauftrag ist bewusst enger als „repariere das Projekt“. Er verhindert nicht jeden Fehler, macht aber Abweichungen sichtbar. Vor der Änderung soll der Agent den bestehenden Zustand beschreiben; danach vergleichen Sie den Diff mit der erklärten Absicht. Für dieses Beispiel genügt der Austausch eines Bezeichners. Änderungen an Reset-Priorität, Datentypen, Breite oder Portnamen wären zusätzliche Aufgaben und müssten separat begründet werden.

-- Before: deliberately incorrect identifier
value <= value + INCREMENT_STPE;
-- After: use the package constant already present in the project
value <= value + INCREMENT_STEP;

Führen Sie anschließend denselben Analyseweg erneut aus. Erzeugen Sie keine Ausnahmeregel für den ursprünglichen Befund und schwächen Sie die Warnungsschwelle nicht ab. Wenn die Korrektur neue Meldungen sichtbar macht, bleiben diese im Ergebnis stehen. Ein Agent soll ihre Ursache erklären oder die Aufgabe mit einem offenen Befund beenden; er soll nicht die Erfolgskriterien so lange verändern, bis eine grüne Anzeige entsteht.

Schritt 4: Ergebnisse eindeutig auswerten

Wrapper-Ergebnis	Bedeutung für diesen Ablauf
analysis_passed, Exit 0	Ein lesbarer Bericht für das erwartete Projekt enthält keine Fehler oder Warnungen.
findings, Exit 1	Die festgelegte Schwelle wurde erreicht oder der Bericht enthält entsprechende Befunde.
blocked_*, Exit 2	Werkzeug, Lizenz, Laufzeit oder Bericht erlauben keine verlässliche Analysebewertung.

Der Wrapper ist eine eigene konservative Integrationshilfe. Er kontrolliert den Projektnamen, die Liste der Befunde und bekannte Schweregrade. Ein fremdes JSON-Dokument, ein abgeschnittener Bericht oder ein unerwartetes Format führt zum Abbruch. Diese Kontrolle deckt nicht das vollständige Herstellerschema ab. Bei einer neuen CLI-Version muss daher zunächst die Ausgabe mit einem kleinen kontrollierten Lauf verglichen werden, bevor Sie den Wrapper als Automatisierungsschritt übernehmen.

Die eingebaute Zeitgrenze beträgt 120 Sekunden für den gestarteten Prozess. Sie ist keine allgemeine Prozessbaum-Isolation und kein Ersatz für die Jobgrenzen einer CI-Umgebung. Auch die konkrete Windows-Batch-Anbindung wurde ohne Sigasi-Installation nicht ausgeführt. Bei einem hängen gebliebenen Herstellerprozess muss die Betriebsumgebung dessen Bereinigung regeln. Berichten Sie einen solchen Fall als blockierten Lauf und bewahren Sie die verfügbaren Diagnosedaten auf.

MCP als zusätzliche Oberfläche, Datenfreigabe als eigene Entscheidung

Die dokumentierten Sigasi-MCP-Werkzeuge liefern unter anderem Diagnosen, Dateikontext und Symbolsuche. Voraussetzung ist ein eingerichtetes, geladenes Projekt. Bei einem passenden Editor kann dies die manuelle Übergabe von Berichten erleichtern. Prüfen Sie trotzdem, ob der Agent das Werkzeug tatsächlich aufgerufen hat und auf welchen Projektstand sich die Antwort bezieht. Eine sichtbare Werkzeugregistrierung belegt noch keinen erfolgreichen Analyseaufruf. Sigasi MCP server.

Trennen Sie dabei den lokal laufenden Analyseprozess vom verwendeten Sprachmodell. Ein lokal erzeugter Befund kann anschließend zusammen mit Quelltext an einen externen Modellanbieter gehen. Legen Sie vor der Nutzung fest, welche Dateien und Diagnoseausschnitte freigegeben sind. Für den Einstieg reichen unser Beispiel, die betroffene Zeile und das kleine Package. Bibliotheken mit vertraulicher IP, Zugangsdaten und unbeteiligte Projektordner gehören nicht automatisch zum Kontext. Ein lokaler Editor ist allein kein Nachweis eines vollständig lokalen KI-Datenflusses.

Was tatsächlich geprüft wurde und was anschließend fehlt

Hersteller-Tooltest ausstehend. Die Sigasi-Integration und Agenten-MCP-Nutzung sind dokumentationsbasiert. Separat wurden unter Windows mit Python 3.12.14 dreizehn synthetische Wrapperfälle, der fehlende Programmaufruf sowie die JSON-Projektstruktur geprüft. GHDL 6.0.0 wies den absichtlichen Bezeichnerfehler mit Exit 1 zurück und analysierte die korrigierte Referenz mit Exit 0. Das vollständige Ergebnis steht in TEST_RESULTS.json. Synthetische Berichte sind dort ausdrücklich keine Sigasi-Ausgaben.

Es fand für diesen Download keine Simulation, Synthese oder Hardwareprüfung statt. Die erfolgreiche GHDL-Analyse bestätigt lediglich die hier untersuchte Namensauflösung und Übersetzbarkeit. Für das Verhalten brauchen Sie eine unabhängige Testbench mit Reset, Enable, Halten und Überlauf. Die Application Note zum KI-VHDL-Simulationstest führt diesen nächsten Prüfbereich aus. Eine vorhandene Simulatoranbindung behandelt die Note zur externen Sigasi-Riviera-Kompilierung.

Übertragen Sie den Ablauf erst danach auf ein echtes Target: überschaubare Dateimenge, dokumentierte Bibliotheken, unveränderte Qualitätsregeln und ein präzises Änderungspaket. Für eine passende Kombination aus Editor, CLI und automatisiertem Betrieb können Sie eine Sigasi-Evaluierung für Ihr Projekt anfragen.

Quellen

Sigasi CLI · Sigasi CLI in Sigasi Visual HDL · Sigasi MCP server · Sigasi AI Chat: historical feature status · Sigasi modular project description · Sigasi release notes · Codex CLI