Code Coverage beantwortet, welche Teile einer Beschreibung während einer Simulation erreicht wurden. Sie beantwortet nicht allein, ob diese Teile das Richtige getan haben. Ein Test kann jede Anweisung ausführen und dennoch einen falschen Datenwert übersehen, wenn keine passende Prüfung existiert. Coverage ist deshalb besonders nützlich als Suchhilfe: Sie lenkt Aufmerksamkeit auf Lücken und unterstützt die Diskussion darüber, welche Anforderungen noch nicht belastbar geprüft sind.
Mehrere Metriken, unterschiedliche Fragen
Statement Coverage betrachtet ausgeführte Anweisungen, Branch Coverage Entscheidungen und ihre Zweige. Weitere Metriken untersuchen beispielsweise Bedingungen, Signalwechsel oder Zustandsübergänge. Aldec beschreibt für seine Coverage-Werkzeuge diese unterschiedlichen Sichten und für Riviera-PRO die zusammenführbare ACDB-Datenbank. Der tatsächlich verfügbare Umfang und notwendige Instrumentierungsschritte sind für die verwendete Konfiguration zu prüfen. Aldec: Code Coverage und ACDB.
Eine Zahl ohne Metrik ist schwer interpretierbar. Neunzig Prozent ausgeführte Anweisungen sind keine Aussage über neunzig Prozent geprüfte Anforderungen. Auch zwei Werkzeuge können ähnlich benannte Metriken unterschiedlich darstellen oder konfigurieren. Für einen Vergleich braucht es daher dieselbe Messdefinition, denselben Designstand und dieselben Ausschlüsse. Andernfalls erzeugt eine Prozentzahl den Eindruck von Genauigkeit, ohne eine belastbare Grundlage zu besitzen.
Ein kleiner Zähler als Beispiel
Ein Zähler mit Reset und Enable besitzt mindestens drei grundlegende Verhaltensweisen: zurücksetzen, weiterzählen und halten. Ein Test, der nach einem Reset nur dauerhaft zählt, kann viele Anweisungen erreichen. Er prüft aber nicht automatisch, ob der Zähler bei inaktivem Enable hält oder ob ein Reset nach längerem Betrieb dieselbe Wirkung hat wie beim Start. Ein Überlauf ist wiederum eine weitere Anforderung.
-- Eigenes, bewusst verkürztes RTL-Beispiel:
if rising_edge(clk) then
if rst = '1' then
count <= (others => '0');
elsif enable = '1' then
count <= count + 1;
end if;
end if;Die fehlende Zuweisung im Haltefall ist hier absichtlich. Ein Bericht über ausgeführte Zuweisungen erklärt diese Absicht nicht. Eine funktionale Prüfung muss den alten Wert über mehrere Taktflanken vergleichen. Ebenso kann die Addition ausgeführt werden, ohne jemals die maximale Zahl zu erreichen. Daraus folgt eine praktische Regel: Zu jeder relevanten Coverage-Lücke gehört eine Frage an die Spezifikation, und zu jedem geschlossenen Punkt gehört eine aussagekräftige Beobachtung.
| Anforderung | Gezielter Stimulus | Notwendige Beobachtung |
|---|---|---|
| Reset | Reset beim Start und im laufenden Betrieb aktivieren. | Der Ausgang erreicht den spezifizierten Resetwert zum vorgesehenen Zeitpunkt. |
| Zählen | Enable an mehreren relevanten Taktflanken aktivieren. | Innerhalb des Zählbereichs entspricht der nächste Wert dem vorherigen Wert plus eins. |
| Halten | Enable über mehrere Taktflanken deaktivieren. | Der Ausgang bleibt unverändert; eine fehlende Zuweisung allein belegt das nicht. |
| Grenzwert / Überlauf | Den spezifizierten Grenzwert erreichen und weiterzählen. | Das Verhalten am Grenzwert entspricht der Spezifikation. |
Auf schmalen Bildschirmen lässt sich die Tabelle horizontal verschieben.
Code Coverage zeigt je nach Metrik ausgeführte Codeelemente und erreichte Zweige oder Zustände. Der funktionale Prüfer bewertet das beobachtete Ergebnis gegen die Erwartung. Beide Informationen müssen zusammen betrachtet werden.
Code und Functional Coverage verbinden
Code Coverage wird aus der Implementierung abgeleitet. Functional Coverage beschreibt dagegen gezielt interessierende Situationen, etwa Paketlängen, Betriebsarten oder Kombinationen aus Zustand und Ereignis. Ein solcher Messpunkt kann die Testplanung besser abbilden, benötigt jedoch ebenfalls Review. Wenn das Coverage-Modell dieselbe falsche Annahme wie das Design enthält, können beide gemeinsam ein beruhigendes, aber unvollständiges Ergebnis liefern.
Beginnen Sie mit einer überschaubaren Tabelle: Anforderung, Stimulus, Prüfer, Beobachtung und Coverage-Ziel. Für einen FIFO könnten das Schreibzugriff bei leerem Speicher, Lesen bei voller Belegung und gleichzeitiges Lesen und Schreiben sein. Das genaue erlaubte Verhalten muss aus der Spezifikation stammen. Die Tabelle verhindert, dass viele zufällige Transaktionen mit einer klaren, gezielten Prüfabdeckung verwechselt werden.
Lücken systematisch untersuchen
Eine unerreichte Stelle kann auf fehlende Stimuli, ein blockierendes Vorbedingungenproblem, absichtlich deaktivierte Konfiguration oder tatsächlich unerreichbaren Code hinweisen. Prüfen Sie diese Möglichkeiten in einer festen Reihenfolge. Zuerst wird der relevante Test identifiziert, danach werden Eingänge und Vorbedingungen kontrolliert. Erst wenn die Architektur die Nichterreichbarkeit erklärt, ist ein begründeter Ausschluss denkbar. Ein Ausschluss allein zur Erhöhung der Zahl ist keine Verifikationsmaßnahme.
Bei parametrisierten Modulen muss klar sein, auf welche Konfiguration sich ein Bericht bezieht. Ein Zweig kann in einer Instanz unerreichbar und in einer anderen zwingend notwendig sein. Beim Zusammenführen mehrerer Läufe darf diese Information nicht verloren gehen. Bewahren Sie deshalb Konfiguration, Seed und Designstand gemeinsam mit dem Bericht auf. Auch alte Ausschlüsse verdienen nach einer Änderung einen neuen Blick.
Ergebnisse für Entscheidungen nutzbar machen
Ein Review sollte nicht nur die Gesamtquote sehen. Aussagekräftig sind offene Lücken nach Risiko, begründete Ausschlüsse, fehlgeschlagene Tests und Veränderungen seit dem letzten freigegebenen Stand. Wenn eine große Menge trivialer Logik die Gesamtzahl dominiert, kann eine kleine sicherheitsrelevante Steuerung darin untergehen. Betrachten Sie deshalb sinnvolle Funktionsbereiche getrennt und verknüpfen Sie die Bewertung mit den Anforderungen.
Für einen Meilenstein werden Messziele vorab festgelegt. Dabei können unterschiedliche Module unterschiedliche Kriterien benötigen. Ein einfaches Registerinterface und ein komplexer Protokollautomat haben andere Risiken. Eine pauschale Pflicht zu hundert Prozent kann wirkungslose Tests oder ungerechtfertigte Ausschlüsse fördern. Ein angemessenes Ziel enthält immer eine fachliche Begründung und eine Regel für verbleibende Lücken.
Der nächste sinnvolle Schritt
Rüsten Sie zuerst einen kleinen, bereits selbstprüfenden Testbestand mit Coverage aus. Analysieren Sie eine konkrete Lücke und ergänzen Sie einen Test, der sowohl die Situation erreicht als auch das Ergebnis kontrolliert. Führen Sie anschließend einen absichtlich fehlerhaften Designstand aus, um die Wirksamkeit des Prüfers zu untersuchen. So wird die Metrik mit tatsächlicher Fehlererkennung verbunden, statt nur als dekorativer Fortschrittsbalken zu dienen.
Die OSVVM-Application-Note zeigt den Einstieg in strukturierte Prüfungen. Für die Werkzeugauswahl erläutert die Riviera-PRO-Seite den Produktkontext. Dieser Artikel enthält keine eigenen Hersteller-Laufzeitmessungen und keinen behaupteten Coverage-Nachweis eines realen Designs.
Quellen und Stand
Recherche geprüft am 19.10.2026. Aldec: Code Coverage und ACDB, Aldec Riviera-PRO.