I am configuring a Virtex/-E, Spartan-II/-IIE/-3, or Virtex-II/Virtex-II Pro device. The device configures correctly after power-up and after PROG is pulsed, but does not work after reconfiguration or after a partial reconfiguration. (This problem occurs with devices that are using a DLL, DCM, or DCI.)
This problem occurs because, when a device is reconfigured, the shut-down sequence does not reset the DLL. The shut-down sequence puts the device in a dormant state by asserting GHIGH. When GHIGH is asserted, all interconnect is brought High, which halts the CLKIN to the DLL. Without a CLKIN, the state of the DLL does not change. When CLKIN is again applied, the DLL picks up where it left off.
The problem occurs when GHIGH is deasserted after the last frame is loaded and before the startup sequence begins. If the DLL has external feedback, the DLL sees CLKIN when GHIGH is deasserted, but cannot get the CLKFB until GTS is deasserted during the startup sequence. Since the DLL is seeing CLKIN, it continues to try to optimize phase alignment, but without a valid CLKFB it quickly fails (bringing the LOCKED signal Low). At this point, only a reset will allow the DLL to recover.
A DLL with internal feedback can also be affected. Although the DLL with internal feedback will likely assert the LOCKED signal after reconfiguration, if the chip environment (temperature and voltage) drifted during the time that the DLL clock inputs were held High, then the DLL clock outputs might not be correct when the clock inputs begin toggling again. Any time the clock inputs are halted for > ~100 usec, the DLL should be reset in to ensure reliable operation.
To avoid this problem, all DLLs should be reset after configuration. If a DLL in your design uses external feedback, the DLL cannot be reset until after the GWE and GTS cycle in the startup sequence. If external feedback is not used, the DLL can be reset after the GWE cycle in the startup sequence.
You can reset the DLL externally or through internal logic. If you use an internal reset, the DLL reset logic can be driven off of the CLKIN input. One way to generate an internal reset is to use a counter. The counter should generate a reset pulse for several clock cycles, then deassert the reset signal so the DLL can lock.