Il peut y avoir différentes raisons pour lesquelles la simulation échoue lorsque l’activité commence et que les signaux non définis commencent à se propager à X à travers la conception. En général, il est recommandé de vérifier si tous les blocs de testbench et de DUT ont été correctement réinitialisés et si X ne peut pas être causé par des signaux d’entrée mal pilotés.
L’IP Nios II permet d’exporter debug_req signal dans une configuration. Si cette option est activée, il est de la responsabilité de l’utilisateur de connecter correctement l’interface debug_req et de fournir une connexion valide dans un testbench de simulation fonctionnelle.
L’exécution d’une simulation avec debug_req activée, mais non pilotée, peut entraîner une erreur similaire à celle suivante :
168 ns : ERREUR : nios_nios2_gen2_0_altera_nios2_gen2_unit_180_gro5auy_test_bench/d_readdatavalid est « x » $stop à l’heure 168.000 ns Scope : top_tb.nios.nios2_core.nios_nios2_gen2_0.cpu. Fichier PROTÉGÉ : ./. /.. //.. /.. /ip/nios/nios_nios2_gen2_0/sim//.. Ligne /altera_nios2_gen2_unit_180/sim/nios_nios2_gen2_0_altera_nios2_gen2_unit_180_gro5auy_test_bench.v : 962
Examinez si vous n’êtes pas très en accord avec debug_req option de Nios IP.
Si debug_req est une activité de groupe, poussez-vous à la logique à faible valeur pendant les simulations fonctionnelles.
Si vous n’avez pas besoin d’utiliser cette fonctionnalité, désactivez-la dans Nios configuration IP.
Il est indiqué dans l’interface graphique que l’utilisateur est responsable de se connecter et de piloter debug_req correctement lorsqu’il est activé, et aucun changement de responsabilité n’est prévu lors de l’utilisation de la configuration de simulation générée.