3013 - What should I do when the LatticeECP3<i> </i>Delay-locked loop (DLL) is not getting locked?
If the LatticeECP3 Delay-locked loop (DLL) is not locked with the DLL's LOCK signal de-asserted, it means that the DLL's CLKI and CLKFB are not in phase.
For example, the DLL input clock may not be stable at that time. It is recommended that the DLL is reset during its unlocking state in order to start the re-lock process properly.
If the DLL is not reset when its LOCK signal is de-asserted, its output signals will not work as expected even if the DLL input clock gets back to be normal.
When the DLL input is stable during the re-lock process, the DLL will enter the lock state after the DLL lock time (tLOCK). Otherwise, the DLL should be reset again after the maximum tLOCK and re-start the re-lock process.
In addition, it is recommended that if the DLL ouput is used as the FPGA logic clock, the DLL reset should not be the same as the FPGA logic reset. Typically, logic requires that a clock is running during a reset condition. If the data path reset also resets the DLL, the source of the logic clock will stop and this may cause problems in the logic. Another thing that needs to be checked is the DLL frequency is within the supported range in the datasheet. For DLL input and feedback signals, their frequency should be between 133 MHz and 500 MHz.
Refer to the TN1178-"LatticeECP3 sysCLOCK PLL/DLL Design and Usage Guide" for the details about the DLL.