--- Quote Start ---
... instead of one reset signal I use two, they assert simultaneousely and deassert
in sequence. The reset signal to deassert first goes to PLLs and the second to CPU, ... What I've found
is that the system instability is somehow related to PLLs reset. If I leave areset fixed to 0 than the system
is less likely to hang and if I increase the second reset time to ~100ms (first reset - PLLs - deaserts after 1ms)
the system doesn't hang. I am not comfortable with this workaround, since according to the datasheet max
PLL resync time is 1ms, beside the PLL locked signals are among my reset sources and I didn't see any
self reset during boot.
--- Quote End ---
Try using SignalTap II to trace your reset signals and any other signals you think are worth checking. SignalTap II has a power-on feature where you can get it to trigger after power-on, and then you can download the traces. I've used this feature to capture PCIe power-on reset signals.
Are you using the PLL locked output as a reset for your downstream logic? If so, look at it with SignalTap using a oscillator clock source, eg., the input clock to the PLL. The locked output should usually be filtered before using it as a reset signal.
There's code for a PLL reset debounce/deglitch in the source code associated with this PCIe thread:
http://www.alteraforum.com/forum/showthread.php?t=35678 Another thing - is your design fully constrained with TimeQuest constraints?
Cheers,
Dave
Honored Contributor
