There might be various reasons why simulation fails when activity starts and undefined signals start to X propagate through design. In general it is recommened to review if all blocks in testbench and DUT has been properly reset and if X propagation can't be caused by not properly driven input signals.
The Nios II IP allows configuration where debug_req signal can be exported. If such option is enabled, it is user responsibility to properly connect debug_req interface and provide valid valud in functional simulation testbench.
Running simulation with debug_req enabled, but not driven can lead to an error similar to following:
168 ns: ERROR: nios_nios2_gen2_0_altera_nios2_gen2_unit_180_gro5auy_test_bench/d_readdatavalid is 'x'$stop at time 168.000 ns Scope: top_tb.nios.nios2_core.nios_nios2_gen2_0.cpu.PROTECTED File: ./../..//../../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 Line: 962
Review if you are intentionaly using debug_req option of Nios IP.
If debug_req is intentional, drive to logic low value during functional simulations.
If you do not need to use this feature, disable it in Nios IP configuration.
There is note in GUI about user's responsibility to connect and drive debug_req properly when enabled and there are no plans to change responsibility when using generated simulation setup.