Forum Discussion
Altera_Forum
Honored Contributor
10 years agoReset vector contents got changed - about the first 10 addresses at the bottom of the memory, and a similar number at the top of the memory (the exact number of lines varies). It's also not unique to one board, we have a system of 8 cards and they all exhibited similar behaviour.
I am using the fast Nios core (non ECC though). No interrupts are sent from PCIe to Nios - they communicate via a letterbox scheme using a completely separate dual-port memory. The DDR controller supplies the clock as well as the reset to the user system. The PCIe core is on a separate clock domain. So the user system reset (including the Nios) is driven only from the afi_reset pin. The DDR controller reset (soft_reset) is driven by the PCIe core - so this way the PLL is stable (not reset by global_reset) by the time the PCIe core has been enumerated and Windows has loaded (the soft_reset isn't released until the driver writes to a register in the PCIe BAR). The design fully met timing - the worst case Fmax was ~240MHz and the user system clock was running at only 200MHz. No violations are reported at any corner. But at this point the firmware has grown quite a bit in the last 6 months and the boot copier from flash is taking care of the problem - any corrupted contents is simply overwritten when the Nios processor boots which seems a more sensible approach. Even if corruption was only happening 1/500 times, that's still quite a high chance something could go wrong. I may later on have a look with signaltap later on, but at the moment I am focused on other areas of the project.