--- Quote Start ---
I've traced the system hangs to DDR calibration failure.
--- Quote End ---
Congrats! Its a pain to track subtle bugs down ...
--- Quote Start ---
The local_init_done signal from DDR stays 0 and ctl_cal_fail, ctl_init_fail are 1 when the boot hangs.
The DDR calibration fails only when deaserting reset too fast (< ~100ms) after FPGA configuration.
--- Quote End ---
So why not take the easy way out then; add a reset component that is enabled at power-on after the external reset is deasserted, and it holds an internal reset asserted for at least 100ms (or resets the DDR for that long anyway).
--- Quote Start ---
The really strange behaviour I've noticed is that when the boot hangs it will continue to hang if FPGA is reset by toggling nCONFIG, if the power is turned on/off quickly it will still hang, turning power off and waiting a minute gets the system a chance to boot normally.
--- Quote End ---
An FPGA starts out 'from scratch' if nCONFIG is pulsed (although it won't go through its power-on-reset sequence). Its unlikely to be the FPGA that is the problem (unless you are violating an I/O voltage or power supply rise time requirement).
I'd guess that you have something external that changes, eg., your DDR or some other device gets into a weird state that is stalling your boot.
Keep in mind that when you configure an FPGA there is a large inrush current (on some of the supplies). If your power supplies are marginal (with respect to the current sourcing ability), then they might work sometimes, and not others.
--- Quote Start ---
How is the local_init_done meant to be used, in example designs I've seen it's left unconnected?
--- Quote End ---
Example designs are not always the best references. Read the DDR controller User Guide, trace the hardware with SignalTap II, try a few things, break things, fix them, ... that is the better way to understand how the IP cores need to be used. If you find something that does not work according to the IP User Guide, then file a Service Request with Altera. You'll get a much better response if you can show you've looked at the problem in detail and identified something that is not documented or is incorrectly documented.
Cheers,
Dave
Honored Contributor
