Ein Simulator wird selten nur von einer Person für ein einziges Design verwendet. Er muss zu bestehenden Bibliotheken, Testumgebungen, Betriebssystemen und Arbeitsweisen passen. Eine gute Evaluierung bildet deshalb den späteren Alltag ab. Diese Checkliste lässt sich als Arbeitsplan verwenden: Anforderungen sammeln, Musskriterien prüfen, typische Fehler untersuchen und den Betrieb unter realistischen Bedingungen bewerten. Ein Produktname allein ist dabei noch keine überprüfbare Konfiguration.
1. Den Umfang der Entscheidung festhalten
Beginnen Sie mit dem nächsten konkreten Projekt und ergänzen Sie absehbare Anforderungen. Notieren Sie verwendete Sprachen, Sprachstände, Zielbausteine, Fremd-IP und Testframeworks. Unterscheiden Sie sicher benötigte Funktionen von denkbaren späteren Erweiterungen. Diese Trennung verhindert sowohl eine zu kleine Auswahl als auch den Kauf auf Vorrat ohne nachvollziehbaren Bedarf. Eine kurze, priorisierte Liste ist meist nützlicher als ein umfangreicher ungeordneter Fragenkatalog.
Definieren Sie außerdem, wer den Simulator nutzt: RTL-Entwickler, Verifikationsspezialisten, Integratoren oder ein automatisierter Runner. Eine grafische Oberfläche und ein nächtlicher Batchlauf haben unterschiedliche Betriebsanforderungen. Halten Sie fest, welche Aufgaben parallel stattfinden und welche Ergebnisse zwischen Personen übergeben werden. Erst damit lässt sich eine passende Lizenz- und Arbeitsplatzkonfiguration anfragen.
2. Sprach- und Bibliothekskompatibilität belegen
- Repräsentative RTL-Quellen mit der vorgesehenen Sprachversion analysieren.
- Die tatsächlichen Testbench-Konstrukte einschließlich Assertions oder Klassen prüfen.
- Herstellerbibliotheken und verschlüsselte IP in freigegebenen Versionen einbinden.
- Mixed-Language-Grenzen mit Breiten, Parametern und Resetwerten untersuchen.
- Einen vollständigen Aufbau in einem neuen Ausgabeverzeichnis wiederholen.
Notieren Sie zu jeder Abweichung ein kleines Reproduktionsbeispiel. Die Aussage „SystemVerilog funktioniert nicht“ ist zu breit, um eine Lösung zu finden. Eine konkrete Datei mit einem bestimmten Konstrukt, dem tatsächlichen Aufruf und der Fehlermeldung ist dagegen verwertbar. Das gilt ebenso für Bibliotheksprobleme, deren Ursache häufig in Pfad, Zuordnung oder Version liegt.
3. Debugging an einem echten Fehler bewerten
Ein sauberes Demonstrationsdesign zeigt selten die schwierigen Seiten der täglichen Arbeit. Wählen Sie einen bekannten Fehler oder erzeugen Sie gezielt eine falsche Datenfolge. Prüfen Sie den Weg von der fehlgeschlagenen Assertion zur ursächlichen Logik. Können relevante Signale und Instanzen schnell gefunden werden? Lässt sich ein später Fehler ohne unkontrolliert große Wavedateien untersuchen? Sind Quellstand und Ergebnis eindeutig zugeordnet?
Lassen Sie zwei Personen dieselbe Diagnose durchführen und notieren Sie Hindernisse. Entscheidend ist nicht, dass ein Experte die richtige Tastenkombination kennt, sondern dass das Team einen wiederholbaren Diagnoseweg besitzt. Bei transaktionsbasierten Testbenches sollte außerdem der Zusammenhang zwischen Transaktion und Signalverhalten sichtbar werden. Eine reine Wellenformansicht kann dafür allein zu wenig Kontext liefern.
4. Automatisierung einschließlich Fehlerfälle testen
Ein Batchlauf muss einen eindeutigen Status liefern. Testen Sie einen erfolgreichen Fall, eine absichtlich fehlschlagende Prüfung, einen Compilerfehler und einen nicht endenden Test. Der übergeordnete Runner muss diese Situationen korrekt unterscheiden und relevante Logs aufbewahren. Eine Meldung im Terminal ist kein ausreichender Nachweis, wenn das umgebende System den Prozess trotzdem als erfolgreich bewertet.
Prüfen Sie anschließend Testauswahl, parallele Prozesse und getrennte Ausgabeverzeichnisse. Ein gemeinsamer beschreibbarer Arbeitsordner kann Ergebnisse gegenseitig überschreiben. Bei begrenzten Lizenzen ist außerdem wichtig, wie wartende Prozesse behandelt werden und wann eine Zeitgrenze greift. Diese Bedingungen gehören in die Betriebsplanung, nicht erst in die Fehlersuche nach einer unzuverlässigen Nachtregression.
5. Ergebnisse und Messwerte sinnvoll vergleichen
Für Laufzeitvergleiche müssen Quellstand, Test, Hostsystem, Optimierung und Aufzeichnungseinstellungen gleich bleiben. Erfassen Sie Compilezeit, Elaborierung und Simulation möglichst getrennt. Auch der Speicherbedarf und die Größe erzeugter Dateien können praktisch relevant sein. Ein einzelner sehr kleiner Test erlaubt keine allgemeine Aussage über die Leistungsfähigkeit bei umfangreichen Designs. Benennen Sie deshalb den Geltungsbereich jeder Messung.
Coverage und Ergebnisexport benötigen ebenfalls einen praktischen Versuch. Prüfen Sie, ob Berichte nach mehreren Tests korrekt zusammengeführt werden und wie Ausschlüsse dokumentiert sind. Kontrollieren Sie mindestens eine bekannte Lücke manuell. Eine Zahl ohne nachvollziehbare Herkunft hilft dem Review wenig. Die Grenzen dieser Metrik erläutert der Beitrag Code Coverage: Nutzen und Grenzen.
6. Angebot und Betrieb konkret abgleichen
Klären Sie erforderliche Editionen, Nutzungsrechte, gleichzeitige Prozesse, Betriebssysteme und Wartung anhand des konkreten Angebots. Die offiziellen Seiten von Active-HDL und Riviera-PRO liefern die Produkteinordnung; verbindliche Konditionen und Ihre genaue Ausstattung ergeben sich daraus nicht automatisch. Fragen Sie außerdem nach dem Weg für reproduzierbare Fehlerberichte und nach verfügbaren Installationsständen.
7. Eine nachvollziehbare Entscheidung ablegen
Das Abschlussprotokoll enthält Musskriterien, Testergebnisse, offene Einschränkungen und die ausgewählte Konfiguration. Kennzeichnen Sie ungetestete Punkte deutlich. Eine Einschränkung kann akzeptabel sein, wenn ein tragfähiger Umgang vereinbart ist; sie darf nicht hinter einer Gesamtpunktzahl verschwinden. Benennen Sie auch, welche Änderungen eine erneute Evaluierung auslösen, etwa ein neues Betriebssystem, eine andere IP-Version oder eine anspruchsvollere Testmethodik.
Mit diesem Protokoll kann eine Beratung zur Simulatorauswahl direkt an den Anforderungen ansetzen. Für einen ersten Vergleich ordnet Active-HDL und Riviera-PRO typische Einsatzsituationen ein. Dieser Artikel ist eine eigene Evaluierungshilfe und enthält keine erfundenen Benchmarkwerte oder pauschalen Siegerempfehlungen.
Quellen und Stand
Recherche geprüft am 19.10.2026. Aldec Active-HDL, Aldec Riviera-PRO.