Für FPGA- und ASIC-Teams ist KI besonders nützlich, wenn eine klar begrenzte Änderung mit überprüfbaren Ergebnissen verbunden wird. Ein Assistent kann einen Zähler formulieren, einen fremden Prozess erklären oder aus einer Schnittstellenbeschreibung Testideen ableiten. Ob die Schaltung die vereinbarte Aufgabe erfüllt, ergibt sich daraus noch nicht. Diese Einführung zeigt, welche Arbeitsschritte Sie delegieren können und welche Nachweise jede Änderung begleiten sollten. Ein Register-Transfer-Level-Modell, kurz RTL, beschreibt dabei die Hardwarefunktion zwischen Registern und Taktflanken.
Beginnen Sie mit dem Verhalten, nicht mit dem Prompt
Die Aufforderung „Schreiben Sie einen Zähler“ lässt zentrale Entscheidungen offen: Welche Flanke zählt? Ist der Reset synchron? Hat er Vorrang vor Enable? Läuft der Zähler beim Maximalwert über oder bleibt er stehen? Ein Sprachmodell muss diese Lücken irgendwie schließen. Ein gut lesbarer Vorschlag kann deshalb eine andere Aufgabe lösen als Ihre tatsächliche Anforderung. Schreiben Sie zunächst eine kleine Entscheidungstabelle und markieren Sie unklare Punkte ausdrücklich als offene Fragen.
Ein geeigneter Auftrag lautet beispielsweise: „Vier Bit, steigende Taktflanke, synchroner aktiver High-Reset mit Vorrang, Halten bei deaktiviertem Enable, Überlauf von 15 auf 0.“ Ergänzen Sie den erlaubten Sprachstandard, Bibliotheken und vorhandene Schnittstellen. Die gewünschte Begründung sollte sich auf diese Anforderungen beziehen. So kann ein Reviewer eine Änderung auch dann bewerten, wenn er den vorangegangenen KI-Dialog nicht kennt. Bewahren Sie Anforderungen, Änderung und Test zusammen in der Versionsverwaltung auf.
Drei verschiedene Fragen an denselben Code
Sprachprüfung beantwortet zunächst, ob sich der Code mit den gewählten Spracheinstellungen und Abhängigkeiten analysieren lässt. Eine Simulation führt ein Modell mit bestimmten Eingangswerten aus. Eine Anforderungsprüfung vergleicht beobachtetes Verhalten mit einem zuvor festgelegten Soll. Diese Ebenen bauen aufeinander auf, liefern aber unterschiedliche Aussagen. Auch ein erfolgreicher Compilerlauf entdeckt keinen fachlich falschen Überlauf, wenn die Beschreibung sprachlich zulässig ist.
| Frage | Beispiel | Was offen bleibt |
|---|---|---|
| Ist die Beschreibung analysierbar? | Typen, Bezeichner und Bibliotheken werden aufgelöst. | Die Reset-Priorität kann trotzdem falsch sein. |
| Stimmt beobachtetes Verhalten? | Bei Enable steigt der Wert nach einer Taktflanke. | Ein einzelner Lauf deckt den Überlauf nicht ab. |
| Sind die Anforderungen geprüft? | Gezielte Tests prüfen Reset, Halten und Überlauf. | Physikalisches Timing und unbekannte Anforderungen bleiben außerhalb dieses Tests. |
Nehmen Sie eine Variante, die bei 15 stehen bleibt. Sie kann fehlerfrei übersetzt werden und die Folge 0, 1, 2 richtig simulieren. Erst der festgelegte Test „15 plus ein aktivierter Takt ergibt 0“ deckt den Widerspruch auf. Dafür braucht die Testbench, also die Simulationsumgebung des Prüflings, eine Assertion: eine ausführbare Bedingung mit einer Fehlermeldung. Die vollständige Zähler-Anleitung enthält diese Prüfungen und bewusst eingebaute Fehler, ohne eine angeblich beobachtete KI-Fehlergeschichte zu erfinden.
q = 15
rst = 0 · en = 1
↑ clkDie Anforderung R4 erwartet den Überlauf.
Die Assertion erkennt die Abweichung vom Soll.
Schematische Gegenüberstellung für das eigene Zählerbeispiel, kein Messbild. Die Sprachprüfung und der Vergleich mit dem geforderten Verhalten beantworten unterschiedliche Fragen.
Was Sie sinnvoll delegieren können
Lassen Sie den Assistenten zunächst Dateien und Abhängigkeiten erklären, eine begrenzte Änderung vorschlagen oder die Auswirkungen einer geänderten Breite aufzählen. Gute Aufgaben haben einen kleinen Umfang und einen klaren Abschluss: eine dokumentierte Schnittstelle, ein Patch oder eine Liste konkreter Diagnosebefunde. Bei unbekanntem Projektkontext ist eine Rückfrage hilfreicher als eine frei erfundene Portbelegung. Bitten Sie ausdrücklich darum, Annahmen kenntlich zu machen und vorhandene Konventionen zu erhalten.
Für Verifikation kann KI zusätzliche Randfälle vorschlagen und wiederkehrenden Testbench-Code entwerfen. Anforderungen und erwartete Ergebnisse sollten jedoch unabhängig vom vorgeschlagenen RTL geprüft werden. Wenn derselbe Irrtum sowohl Implementierung als auch Referenzmodell bestimmt, stimmen beide miteinander überein und sind dennoch falsch. Ein einfacher Gegencheck ist eine von Hand hergeleitete Sequenz mit wenigen Takten, einschließlich Reset und Grenzwert. Diese Sequenz bleibt unverändert, während der Assistent die Implementierung korrigiert.
Ein Agent kann Prüfwerkzeuge selbst bedienen
Ein Agent verbindet ein Sprachmodell mit Werkzeugzugriffen. Er kann etwa eine Datei ändern, einen freigegebenen lokalen Befehl ausführen und die Diagnose für den nächsten Schritt lesen. Die offizielle Codex-CLI-Dokumentation beschreibt das Arbeiten an Dateien und das Ausführen von Befehlen. Das macht einen automatisierten Prüfablauf möglich, sofern die benötigten Werkzeuge installiert und berechtigt verfügbar sind. Quelle: OpenAI: Codex CLI.
Die Aussage „Der Agent hat getestet“ reicht für eine Abnahme nicht. Verlangen Sie den tatsächlich ausgeführten Befehl, Werkzeugversion, Rückgabecode, zugehörigen Quellstand und eine überprüfbare Ergebnisdatei. Eine fehlende Lizenz, ein abgebrochener Lauf oder eine nicht gefundene Testbench ist kein erfolgreiches Ergebnis. Auch ein Prozess mit Rückgabecode null kann unzureichend sein, wenn er gar keine Tests ausgeführt hat. Legen Sie daher ein erwartetes Abschlusskennzeichen und einen Zeitrahmen fest.
Projektanalyse und Simulation gezielt kombinieren
Projektkontext umfasst mehr als die gerade sichtbare Datei: Bibliothekszuordnung, Sprachversion, generierte Quellen, Package-Abhängigkeiten und die tatsächliche Konfiguration. Sigasi stellt eine CLI zur Projektanalyse bereit. Welche Variante und Lizenz passen, muss vor der Automatisierung feststehen. Die Sigasi-Anleitung für Agenten behandelt deshalb Projektkonfiguration, Fehlerauswertung und Abbruchbedingungen getrennt von der Simulation. Quelle: Sigasi CLI-Handbuch.
Aldec kann anschließend die Rolle einer Simulations- und Debugging-Umgebung übernehmen; entscheidend ist die für Ihr Projekt passende Edition und Konfiguration. Die Wahl eines KI-Assistenten und die Wahl des Simulators sind dabei getrennte Entscheidungen. Eine generierte Erklärung ersetzt keine gespeicherte Simulation, und ein komfortabler Editor ersetzt keinen Testfall. Unter KI-Assistenten in Aldec finden Sie die aktuell belegten Integrationen mit ihren Voraussetzungen.
Vertraulichen Code und Berechtigungen mitdenken
Bevor ein Agent einen Projektordner lesen darf, klären Sie, welche Dateien er für den Auftrag tatsächlich benötigt. Eine isolierte Beispielstruktur ist häufig ein besserer Einstieg als der vollständige Kundenbestand. Prüfen Sie den gesamten Datenweg: Editor, Erweiterung, Agent, Modellanbieter, Protokollierung und etwaige externe Dienste. Dass ein Compiler lokal läuft, sagt nichts darüber aus, wohin der Assistent Code oder Diagnosen sendet. Konkrete Zusagen hängen von der gewählten Einrichtung und den geltenden Vereinbarungen ab.
Geben Sie dem Agenten nur die benötigten Arbeitsrechte. Eine HDL-Korrektur benötigt beispielsweise keinen Zugriff auf produktive Website-Zugänge. Halten Sie fremde Kommentare und eingelesene Dokumente als Projektmaterial von den eigenen Arbeitsanweisungen getrennt. Für den technischen Ablauf genügt zunächst ein lokaler, nachvollziehbarer Test. Zusätzliche Automatisierung sollte erst folgen, wenn Sie Abbruch, Protokollierung und Rücknahme selbst geprüft haben.
Eine überschaubare Abnahme
Eine praktikable Änderungsschleife lautet: Anforderungen festhalten, Ausgangsstand sichern, kleinen Patch erstellen, Projektanalyse ausführen, unveränderte Tests laufen lassen und das Ergebnis gemeinsam mit dem Diff bewerten. Bei einem Fehler wird die Ursache eingegrenzt; die Abnahmebedingung wird nicht beiläufig herabgesetzt. Eine fachlich notwendige Anforderungsänderung ist ein eigener, sichtbarer Schritt und verlangt entsprechend angepasste Tests.
Für die Auswahl Ihrer Umgebung hilft die Entscheidungshilfe zu freien und kommerziellen Werkzeugen. Bringen Sie zur Werkzeugberatung Sprachversionen, Betriebssystem, vorhandene IP und einen repräsentativen Testfall mit. EDA Praxis ist ein kommerzielles Fachangebot von eVision Systems GmbH. Diese Einführung ist quellenbasiert; konkrete eigene Testergebnisse werden ausschließlich in der verlinkten Application Note mit ihrer tatsächlichen Umgebung ausgewiesen.