Es kann verschiedene Gründe geben, warum die Simulation fehlschlägt, wenn die Aktivität startet, und undefinierte Signale beginnen, sich über das Design zu verbreiten. Im Allgemeinen wird überprüft, ob alle Blöcke in Testbench und DUT ordnungsgemäß zurückgesetzt wurden und ob X nicht durch nicht korrekt betriebene Eingangssignale verursacht werden kann.
Die Nios II IP ermöglicht die Konfiguration, wo debug_req Signal exportiert werden kann. Wenn diese Option aktiviert ist, ist es für den Benutzer verantwortlich, debug_req Schnittstelle korrekt anzuschließen und gültige Valud in funktionellem Simulationstestbench bereitzustellen.
Die Ausführung von Simulationen mit aktiviertem debug_req, aber nicht angetrieben kann zu einem ähnlichen Fehler wie folgt führen:
168 ns: FEHLER: nios_nios2_gen2_0_altera_nios2_gen2_unit_180_gro5auy_test_bench/d_readdatavalid ist "x" $stop zum Zeitpunkt 168.000 ns Umfang: top_tb.nios.nios2_core.nios_nios2_gen2_0.cpu. GESCHÜTZTE Datei: ./.. /.. //.. /.. /ip/nios/nios_nios2_gen2_0/sim.. /altera_nios2_gen2_unit_180/sim/nios_nios2_gen2_0_altera_nios2_gen2_unit_180_gro5auy_test_bench.v Zeile: 962
Überprüfen Sie, ob Sie debug_req Option Nios IP vorsätzlich verwenden.
Wenn debug_req beabsichtigt ist, fahren Sie bei funktionellen Simulationen auf einen niedrigen Logikwert.
Wenn Sie diese Funktion nicht verwenden müssen, deaktivieren Sie sie in Nios IP-Konfiguration.
In der GUI wird die Verantwortung des Benutzers für die korrekte Verbindung und das Laufwerk der debug_req bei Aktivierung vermerkt, und es ist nicht geplant, die Verantwortung bei der Verwendung eines generierten Simulations-Setups zu ändern.