Hello guys,I am experiencing an interesting problem, where the Nios CPU, that has been working on Quartus 12.1 now resynthesized on Quartus 13.0sp1 doesn't work. I've also made a QSYS system regeneration using new components, that came with the new Quartus version. I am starting Nios from on-chip memory, which has initialization hex already assigned. The vectors are set up correctly, everything shows into on-chip memory as it was before in Q12.1. I don't have any ideas what could be wrong, but now, when generating QSYS system, I get hundreds of these warnings:
Warning (12251): Qsys_system: "No matching role found for rst_controller:reset_out:reset_req (reset_req)"nios2-download says, that the system is not running, so probably Nios stays in reset. I've double checked the reset signal also tried manually set the reset_n to '1', but the situation is the same. There are no timing problems shown in TimeQuest analyzer, so I am pretty sure, that I am not experiencing system bus stalls. Maybe someone could point me out what I am missing? Thanks.
Hi,You are not alone! I am having this exact problem with my qsys component (not using NIOS). I ported my design from 12.1 to 13 and 13sp1. I also regenerated the qsys with the 13.1 components and I also get hundreds of warnings when generating: No matching role found for rst_controller:reset_out:reset_req (reset_req)The closest I have come to an answer is from: http://www.altera.com/support/kdb/solutions/spr371633.html Where is states that these warnings can be ignored, however I am not convinced that can be ignored and that its not having a detremental effect on my image! I dont know if its a bug with porting a system or what but it seems to only have appeared due to upgrading Quartus. I hope we can get some help with this issue! Regards James
Seems like You can ignore it. I did and the design works. The problem of non-working design was elsewhere.Altera on-chip memory parameter GUI has a bug, where the bath to the HEX file is processed incorrectly, that's why You have to set the relative, not absolute path.
I seem to be having a problem identical to the one described here. My Nios system which runs from internal RAM isn't starting on power-up. This was working fine until I switched to 13.0sp1.In my case it appears that the hex file was properly loaded into the internal RAM. I can connect the debugger to the Nios processor and start it without loading anything. The processor is simply failing to start on power-up. Any ideas?
I have the same problem in 13.1. if I checked the "reset the system" in "run config" tab, the niosII program will not run. as the same reason, when I programmed the sof and elf to the EPCS, the NiosII don't run.