Strukturierte VHDL-Verifikation mit OSVVM aufbauen

Problem und Ziel

Eine erste selbstprüfende Testbench kann ihre Ergebnisse mit einzelnen Assertions ausgeben. Wenn viele Tests und wiederverwendbare Komponenten hinzukommen, werden einheitliche Fehlerzählung, Berichtserstellung und Aufbauskripte wichtiger. Diese Note führt OSVVM anhand eines kleinen Zählers ein. Sie trennt die VHDL-Prüflogik vom Werkzeugstart und zeigt einen dokumentierten Einstieg für Riviera-PRO. Der kleine Umfang macht die Ergebnisverwaltung sichtbar, ohne eine komplexe Busarchitektur vorauszusetzen.

Voraussetzungen und Versionsvertrag

Benötigt werden VHDL-2008-Kenntnisse, ein geeigneter Simulator und ein vollständig vorbereiteter OSVVM-Stand. Für den dokumentierten Aldec-Ablauf ist eine berechtigt nutzbare Riviera-PRO-Installation erforderlich. Der Hersteller und OSVVM führen entsprechende Integrationswege; die konkrete Kombination aus Simulatorversion, OSVVM-Stand und Lizenz muss im Projekt bestätigt werden. Diese Note aktiviert keine Evaluierung und setzt keine kostenfreie kommerzielle Simulatornutzung voraus.

Für den tatsächlich ausgeführten freien Vergleichstest wurde die OSVVM-Utility-Bibliothek mit dem Tag 2026.09 und Commit 716d751566b4fb6479f69c38cc01790744c911b7 verwendet. GHDL 6.0.0 unter Windows analysierte die VHDL-2008-Auswahl dieser Bibliothek und führte den eigenen Test aus. Die OSVVM-Downloadseite und das offizielle Repository bilden den Versionsbezug. Ein vollständiger Riviera-PRO-Tcl-Lauf wurde nicht durchgeführt. OSVVM downloads and releases; OSVVM: OsvvmLibraries.

Architektur und Verantwortlichkeiten

Das DUT bleibt der Vier-Bit-Zähler aus der VHDL-Testbench-Note. Die neue Testbench erzeugt Stimuli und ruft OSVVM-Affirmations für den Soll-Ist-Vergleich auf. Der Ergebnisabschluss erzeugt einen zusammengefassten Bericht. Das Projektskript ordnet Quellen einer Bibliothek zu und startet den Test. Diese Aufteilung verhindert, dass Prüfabsicht, Bibliotheksaufbau und Ergebnisbewertung in einem undurchsichtigen Skript vermischt werden.

examples/
  counter/rtl/counter.vhd      # unverändertes DUT
  osvvm/tb_counter_osvvm.vhd  # eigener OSVVM-Test
  osvvm/counter.pro           # Projektbeschreibung
  sim-riviera/               # getrennte erzeugte Arbeitsdaten

OSVVM-Installation außerhalb der eigenen Quellen:
  OsvvmLibraries/            # geprüfter Stand mitsamt Submodulen

Bewahren Sie den verwendeten OSVVM-Stand unverändert auf. Ein spontanes Update während einer Fehlersuche kann das Ergebnis verändern und erschwert den Vergleich. Für das gesamte OsvvmLibraries-Projekt müssen auch Submodule zur gewählten Revision passen. Der Utility-Commit allein beschreibt nicht sämtliche Verification Components und Skripte. Ein Team sollte daher die Revision des übergeordneten Projekts und dessen Submodule gemeinsam protokollieren.

Schritt 1: Den OSVVM-Stand vorbereiten

Verwenden Sie die offizielle Anleitung von OsvvmLibraries und wählen Sie einen freigegebenen Release. Das Repository verweist auf Bibliotheken, Skripte und Dokumentation. Prüfen Sie nach dem Bezug, dass Unterverzeichnisse mit benötigten Komponenten tatsächlich gefüllt sind. Ein oberflächlich vorhandenes Hauptverzeichnis genügt bei einem Projekt mit Submodulen nicht. Das eigene DUT bleibt unabhängig davon im eigenen Projektverzeichnis versioniert.

Legen Sie vor dem ersten Simulatorlauf ein separates Arbeitsverzeichnis an. Damit lassen sich erzeugte Bibliotheken und Ergebnisse von den Eingaben unterscheiden. Für den folgenden Tcl-Einstieg enthält die Umgebungsvariable OSVVM_HOME den tatsächlichen absoluten Pfad zu OsvvmLibraries. Der Wert wird lokal gesetzt und ist kein hier erfundener Installationspfad. Prüfen Sie das Verzeichnis im Terminal beziehungsweise in der Simulatorumgebung vor dem Start.

Schritt 2: Skriptumgebung in Riviera-PRO initialisieren

# In der Tcl-Konsole von Riviera-PRO ausführen.
if {![info exists ::env(OSVVM_HOME)]} {
    error "OSVVM_HOME muss auf die lokale Installation zeigen"
}
set osvvmRoot [file normalize $::env(OSVVM_HOME)]
source [file join $osvvmRoot Scripts StartUp.tcl]
build $osvvmRoot
# Anschließend aus examples/sim-riviera:
build ../osvvm/counter.pro

OSVVM dokumentiert für Riviera-PRO die Initialisierung über StartUp.tcl. Für Active-HDL beschreibt das Projekt einen anderen Einstieg mit aktivierter Tcl-Skriptumgebung. Die Produktnamen sind deshalb keine austauschbaren Aufrufparameter. Folgen Sie beim Übertragen der aktuellen Anleitung des jeweiligen Adapters und vermeiden Sie gleichzeitig aktive alte Skriptstände im Suchpfad. OSVVM simulation scripts.

Das erste build bereitet den gewählten Bibliotheksstand vor; das zweite verarbeitet das eigene Projekt. Ein fehlgeschlagener Bibliotheksaufbau muss zuerst behoben werden. Ein nachfolgender Versuch mit teilweise vorhandenen alten Bibliotheken kann einen irreführenden Eindruck von Erfolg erzeugen. Protokollieren Sie deshalb den ersten sauberen Aufbau und wiederholen Sie ihn nach einem wesentlichen Versionswechsel in einem neuen Ausgabeverzeichnis.

Schritt 3: Eigene Testbench mit Affirmations

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
library osvvm;
context osvvm.OsvvmContext;

entity tb_counter_osvvm is
  generic (INJECT_FAILURE : boolean := false);
end entity;

architecture test of tb_counter_osvvm is
  signal clk : std_logic := '0';
  signal rst : std_logic := '1';
  signal enable : std_logic := '0';
  signal q : unsigned(3 downto 0);
begin
  clk <= not clk after 5 ns;
  dut : entity work.counter(rtl) port map (clk, rst, enable, q);

  stimulus : process
    procedure step(r, e : std_logic; expected : natural) is
    begin
      wait until falling_edge(clk);
      rst <= r;
      enable <= e;
      wait until rising_edge(clk);
      wait for 1 ns;
      AffirmIfEqual(std_logic_vector(q),
        std_logic_vector(to_unsigned(expected, q'length)), "Zaehlerwert");
    end procedure;
  begin
    SetAlertLogName("eda_counter");
    step('1', '0', 0);
    for n in 1 to 20 loop
      step('0', '1', n mod 16);
    end loop;
    step('0', '0', 4);
    step('1', '1', 0);
    AffirmIf(not INJECT_FAILURE, "Negativtest darf im Normallauf nicht aktiv sein");
    -- Funktionsvariante liefert die Fehleranzahl als Abschlussstatus.
    std.env.stop(EndOfTestReports);
    wait;
  end process;

  watchdog : process
  begin
    wait for 2 us;
    Alert("Watchdog: Test nicht rechtzeitig beendet", FAILURE);
    std.env.stop(EndOfTestReports);
    wait;
  end process;
end architecture;

Die Prozedur step arbeitet wie im einfachen Beispiel: Eingänge an der fallenden Flanke, Vergleich nach der steigenden Flanke. AffirmIfEqual übernimmt die Ergebniszählung für den Vergleich. SetAlertLogName gibt dem Test einen verständlichen Namen. Das ist nützlich, sobald mehrere Testfälle in einer größeren Ausgabe zusammenkommen. Die verwendeten Aufrufe wurden mit den offiziellen Package-Deklarationen abgeglichen. OSVVM AlertLogPkg source.

Der Abschluss verwendet bewusst die Funktionsvariante EndOfTestReports. Ihr Rückgabewert fließt in std.env.stop. Im überprüften GHDL-Ablauf wurde damit aus einer fehlgeschlagenen Affirmation auch ein Prozessstatus ungleich null. Ein parameterloses stop hätte im ersten Erprobungsschritt trotz FAILED-Bericht Exit-Code 0 geliefert. Diese Beobachtung zeigt, warum eine schöne Ergebniszusammenfassung und ein korrekter Maschinenstatus getrennt geprüft werden müssen. OSVVM ReportPkg source.

Schritt 4: Projektdatei erstellen

# Vom OSVVM-build-Befehl relativ zu dieser Datei ausgewertet.
library eda_counter
analyze ../counter/rtl/counter.vhd
analyze tb_counter_osvvm.vhd
TestName counter_basic
simulate tb_counter_osvvm

Die Datei counter.pro liegt neben der OSVVM-Testbench. Relative Quellpfade beziehen sich im OSVVM-Projektablauf auf die betreffende Projektdatei. Der Bibliotheksname eda_counter trennt das Beispiel von anderen Designs. Die Referenz work.counter in der Testbench bezeichnet dann die Bibliothek, in der sie selbst analysiert wird. Ein anders benannter physischer Simulatorordner ändert diese logische Bedeutung nicht.

Schritt 5: Ergebnis und Gegenprobe auswerten

Der tatsächlich ausgeführte Normaltest mit GHDL meldete bei 236 ns 24 geprüfte Affirmations, 24 bestanden und Exit-Code 0. Der Gegenversuch mit INJECT_FAILURE=true meldete eine fehlgeschlagene Prüfung, 23 bestandene Affirmations und Exit-Code 1. Diese Angaben beschreiben den eigenen kleinen Test unter der genannten freien Umgebung. Sie sind keine Aldec-Testausgabe und kein Nachweis über die gesamte OSVVM-Testsuite.

Im Riviera-Projekt muss derselbe Normal- und Fehlerfall noch ausgeführt werden. Prüfen Sie dabei Ergebnisbericht, Testabschluss und die Weitergabe des Status an einen übergeordneten Batchprozess. Eine funktionierende grafische Simulation beantwortet noch nicht, wie der aufrufende Prozess beendet wird. Verwenden Sie für einen automatisierten Lauf außerdem eine äußere Laufzeitbegrenzung; ein Simulationszeit-Watchdog schützt nicht vor jeder Endlosschleife ohne Zeitfortschritt.

Fehlerdiagnose und Ausbau

Wenn osvvm.OsvvmContext nicht gefunden wird, kontrollieren Sie Bibliotheksaufbau und Zuordnung. Meldungen über fehlende Package-Funktionen weisen häufig auf einen gemischten Versionsstand hin. Ein Bericht ohne ausgeführte Prüfungen ist kein erfolgreicher Test. Prüfen Sie, ob der Stimulusprozess wirklich läuft und die erwarteten Affirmations erreicht. Bei einem Timeout sollten zuerst Takt und wartende Bedingungen untersucht werden, bevor die Grenze vergrößert wird.

Das Beispiel verwendet absichtlich keine Zufallsstimuli und keine Functional Coverage. Diese Funktionen können später sinnvoll hinzukommen, sobald Anforderungen und Beobachtungspunkte klar sind. Für einen Protokolltest lohnt sich dann die Trennung von Treiber, Monitor und Referenzmodell. Ein Seed muss gemeinsam mit dem Ergebnis gespeichert werden. Coverage sollte gezielt interessante Situationen erfassen und darf nicht als Beweis für Korrektheit missverstanden werden.

Tatsächlicher Teststatus und nächster Schritt

Ausgeführt: eigener VHDL-Test gegen OSVVM Utility 2026.09 mit GHDL 6.0.0; positiver und negativer Fall. Nicht ausgeführt: Riviera-PRO-/Active-HDL-Adapter, vollständiger OsvvmLibraries-Aufbau, Aldec-Berichte und Lizenzbetrieb. Die zugehörigen Hersteller-Schritte sind anhand der Dokumentation beschrieben; ihre Ausführung in einer Aldec-Umgebung ist nicht nachgewiesen.

Als nächster Schritt sollte ein kleiner vorhandener Modultest nach derselben Struktur übertragen werden. Der Beitrag über OSVVM, VUnit und UVM hilft bei der Einordnung; die Regression-Note zeigt einen ergänzenden Ansatz für automatisierte Ergebnisbewertung.

Quellen und Stand

Recherche geprüft am 19.10.2026. OSVVM: OsvvmLibraries, OSVVM simulation scripts, OSVVM downloads and releases, OSVVM AlertLogPkg source, OSVVM ReportPkg source, GHDL simulation runtime options.