Ein Design kann syntaktisch korrekt sein und trotzdem die falsche Hardware beschreiben. Es kann alle Stilregeln erfüllen und einen seltenen Resetfall falsch behandeln. Es kann einen Test bestehen, der die entscheidende Situation nie erzeugt. Syntaxprüfung, Linting und Simulation beantworten deshalb verschiedene Fragen. Ein sinnvoller Entwicklungsablauf ordnet ihre Ergebnisse so, dass schnelle Rückmeldungen früh entstehen und spätere Prüfungen auf einem verständlichen Projektstand aufbauen.
Syntax und Semantik: Ist die Beschreibung zulässig?
Die Syntaxprüfung untersucht, ob der Quelltext zur Grammatik der eingestellten Sprache passt. Die semantische Analyse betrachtet zusätzlich Namen, Typen, Deklarationen und weitere Sprachregeln. In der Praxis erscheinen beide häufig gemeinsam als Compilerdiagnosen. Ein fehlendes Semikolon ist anders zu behandeln als ein unbekanntes Package: Im zweiten Fall kann die Ursache eine fehlerhafte Bibliothekszuordnung sein, obwohl die Datei selbst korrekt ist.
Diese Unterscheidung verhindert unnötige Codeänderungen. Wenn nach einem Projektimport viele Namen fehlen, kontrollieren Sie zuerst Abhängigkeiten, Compilerreihenfolge und Spracheinstellung. Eine lokale Ersatzdeklaration kann die Meldung kurzfristig beseitigen und gleichzeitig eine neue Inkonsistenz schaffen. Ziel ist eine einzige nachvollziehbare Definition jeder gemeinsamen Schnittstelle, nicht die möglichst schnelle Reduktion der Meldungszahl.
Linting: Welche Konstruktion ist verdächtig?
Ein Linter prüft Regeln, die über die reine Sprachzulässigkeit hinausgehen. Manche betreffen Stil und Wartbarkeit, andere typische Designrisiken. ALINT-PRO beschreibt statische RTL-Analyse sowie je nach Regelpaket unter anderem Clock- und Reset-Domain-Prüfungen. Deren Aussage hängt von Projektmodell, Constraints und gewählter Konfiguration ab. Aldec ALINT-PRO.
Eine Lintmeldung ist ein Arbeitsauftrag mit Kontext. Bei einer absichtlich ungenutzten Schnittstelle kann eine begründete Ausnahme angemessen sein. Bei einer unbeabsichtigten Breitenreduktion ist meistens eine Designentscheidung nötig. Ein pauschales Abschalten der gesamten Regelklasse verliert zukünftige Hinweise. Legen Sie deshalb fest, wie Ausnahmen begründet, überprüft und bei einer Änderung erneut bewertet werden.
Simulation: Was passiert unter diesen Stimuli?
Simulation führt ein elaboriertes Modell mit konkreten Stimuli aus. Eine selbstprüfende Testbench vergleicht beobachtetes und erwartetes Verhalten. Das ist stärker als die bloße Sichtprüfung einer Wellenform, bleibt aber auf die tatsächlich geprüften Situationen begrenzt. Wenn ein FIFO nie voll wird, sagt ein erfolgreicher Lauf wenig über sein Verhalten bei Überlauf aus. Testplanung und Beobachtungspunkte sind deshalb genauso wichtig wie der Simulator.
-- Eigenes Beispiel innerhalb einer Testbench:
assert received = expected
report "Datenwert stimmt nicht mit dem Referenzmodell ueberein"
severity error;
-- Der Runner muss severity error als fehlgeschlagenen Test behandeln.Die letzte Zeile des Kommentars ist Teil des Prüfvertrags. Ein Werkzeug kann eine Fehlermeldung ausgeben und dennoch einen Prozess mit einem für das umgebende Skript unauffälligen Status beenden. Daher müssen Fehlerschwere, Abbruchverhalten und Ergebnisübernahme zusammen geprüft werden. Ein bewusst falscher Erwartungswert ist ein einfacher Gegenversuch: Die gesamte Automatisierung muss diesen Lauf als fehlgeschlagen melden.
- Syntax & SemantikIst der Code sprachlich zulässig und sind Namen, Typen und Bibliotheken auflösbar?Beispiel: unbekanntes Package
- Statische RegelnWelche Konstruktionen und Strukturen sind unter den gewählten Annahmen verdächtig?Beispiel: unbeabsichtigte Breitenreduktion
- Simulation & PrüferEntspricht das beobachtete Verhalten bei diesen Stimuli der Erwartung?Beispiel: Zähler hält bei Enable = 0
Kompilierung ist kein Simulationstest. Ein bestandener Simulationstest erfasst nur die tatsächlich ausgeführten und ausgewerteten Fälle.
Ein Beispiel über alle Stufen
Angenommen, ein Zähler soll bei aktivem Enable um eins steigen und sonst halten. Ein Schreibfehler im Signalnamen wird häufig schon durch die Sprachprüfung sichtbar. Eine implizite Breitenverkürzung kann eine statische Regel melden. Ob der Zähler während einer Enable-Pause tatsächlich hält, muss die funktionale Prüfung gezielt beobachten. Der Reset mitten im laufenden Betrieb ist nochmals ein eigener Testfall. Kein einzelnes grünes Symbol beantwortet alle vier Fragen.
Auch die Reihenfolge sollte bewusst gewählt werden. Häufig ist es wirtschaftlich, zuerst schnelle, lokale Prüfungen auszuführen und erst danach umfangreiche Regressionen zu starten. Eine Ausnahme kann die Fehlersuche an einem bereits bekannten funktionalen Problem sein. Dann hilft ein kleiner gezielter Test schneller als eine vollständige Wiederholung sämtlicher Projektprüfungen. Der verbindliche Integrationslauf bleibt dennoch für die Übernahme einer Änderung erforderlich.
Regeln als Teamentscheidung pflegen
Ordnen Sie Befunde nach Auswirkung: sprachlich nicht analysierbarer Code, potenzieller Funktionsfehler, unklare Designabsicht oder reine Formatfrage. Die Kategorien sollten nicht blind den voreingestellten Farben eines Werkzeugs entsprechen. Ein fehlender Reset ist beispielsweise je nach Architektur korrekt oder kritisch. Die Bewertung benötigt die Anforderung und darf nicht allein von einer generischen Regelbezeichnung abhängen.
Für bestehende Projekte bietet sich eine dokumentierte Ausgangsbasis an. Neue Fehler dürfen nicht in einem großen Altbestand verschwinden; zugleich muss nicht jede ältere Formatabweichung sofort die Weiterentwicklung blockieren. Trennen Sie begründete Altbefunde von neu hinzugekommenen Problemen und planen Sie die Bereinigung nach Risiko. Eine solche Einführung braucht klare Verantwortlichkeit, damit die Ausgangsbasis nicht zu einer dauerhaften Freistellung wird.
Eine nachvollziehbare Kette schaffen
Halten Sie für jeden Lauf Quellstand, Konfiguration und Ergebnis zusammen. Der Entwickler sollte von einer Meldung zur Quelle und von dort zur zugehörigen Anforderung gelangen können. Sigasis dokumentierte externe Compileranbindung kann eine frühe zusätzliche Prüfstation bilden; ihre erfolgreiche Ausführung ist noch kein Simulationsergebnis. Sigasi: External compilers.
Ein guter Einstieg ist ein kleines Modul mit drei bewusst getrennten Fehlern: einer Analyseabweichung, einer problematischen Konstruktion und einem funktionalen Fehler. Damit lässt sich überprüfen, ob jede Stufe den erwarteten Beitrag leistet. Weiterführend erläutert Code Coverage, welche zusätzlichen Fragen aus einem erfolgreichen Simulationstest entstehen.
Quellen und Stand
Recherche geprüft am 19.10.2026. Aldec ALINT-PRO, Sigasi: External compilers.