Hello, all.
.
For a while, I was able to avoid issues with the way that Qsys uses reset circuitry. Im hitting a wall now, however (probably a silly thing Im overlooking). Attached are screenshots of a (somewhat trivial) system. working_top.jpg and working_subsystem.jpg show a Qsys system that I can synthesize and fit in Quartus. After seeing that there are no setup/hold/recovery/removal violations, I test this system with Eclipse by using the Memory Test Small template running as Nios II Hardware.
.
When adding more subsystems, I get to a point where I get recovery timing violations with the afi_clk. I attempted to solve this by adding a reset bridge to the DDR3 side as seen in nonworking_top.jpg. In doing so, however, I run into the popular problem (despite no listed setup/hold/recovery/removal violations) while downloading the program:
.
---------------------------------------------------------------------------------
Using cable USB-Blaster [USB-0], device 1, instance 0x00
Pausing target processor: not responding.
Resetting and trying again: FAILED
Leaving target processor paused
Downloading ELF Process failed
---------------------------------------------------------------------------------
.
Theres some nuance Im missing, an unintended consequence of placing the reset bridge on the DDR3 side of the system. Im not quite sure how to fix this. Any help would be appreciated.
.
Other things that I have tried/could try in the future:
.
1) Using the Create Global Reset Network command in Qsys This didnt work, downloading the ELF Process failed. (it also breaks the working_top system in the same way if I use that there)
.
2) I speculated that the Nios processor needs to come out of reset at the same time or later than the DDR3 circuitry and that this doesnt happen because it takes time for the afi_clk to achieve lock. nonworking2_top.jpg shows this system. As suggested by the image name, downloading the ELF Process failed.
.
3) I noticed that the Nios processor has the option to have cpu_resetrequest and cpu_resettaken signals. These conduits would need to be exported to the top level. Would manually interfacing with these signals be worthwhile?
.
For a while, I was able to avoid issues with the way that Qsys uses reset circuitry. Im hitting a wall now, however (probably a silly thing Im overlooking). Attached are screenshots of a (somewhat trivial) system. working_top.jpg and working_subsystem.jpg show a Qsys system that I can synthesize and fit in Quartus. After seeing that there are no setup/hold/recovery/removal violations, I test this system with Eclipse by using the Memory Test Small template running as Nios II Hardware.
.
When adding more subsystems, I get to a point where I get recovery timing violations with the afi_clk. I attempted to solve this by adding a reset bridge to the DDR3 side as seen in nonworking_top.jpg. In doing so, however, I run into the popular problem (despite no listed setup/hold/recovery/removal violations) while downloading the program:
.
---------------------------------------------------------------------------------
Using cable USB-Blaster [USB-0], device 1, instance 0x00
Pausing target processor: not responding.
Resetting and trying again: FAILED
Leaving target processor paused
Downloading ELF Process failed
---------------------------------------------------------------------------------
.
Theres some nuance Im missing, an unintended consequence of placing the reset bridge on the DDR3 side of the system. Im not quite sure how to fix this. Any help would be appreciated.
.
Other things that I have tried/could try in the future:
.
1) Using the Create Global Reset Network command in Qsys This didnt work, downloading the ELF Process failed. (it also breaks the working_top system in the same way if I use that there)
.
2) I speculated that the Nios processor needs to come out of reset at the same time or later than the DDR3 circuitry and that this doesnt happen because it takes time for the afi_clk to achieve lock. nonworking2_top.jpg shows this system. As suggested by the image name, downloading the ELF Process failed.
.
3) I noticed that the Nios processor has the option to have cpu_resetrequest and cpu_resettaken signals. These conduits would need to be exported to the top level. Would manually interfacing with these signals be worthwhile?