We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 11778

Virtex/-E/-II/-II Pro, Spartan-II/-IIE/-3 - Device configures correctly after PROG is pulsed, but DLL/DCM/DCI does not function correctly when reconfigured


General Description:

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.

For more information, please see (Xilinx Answer 14425). For more information on how to pulse PROG with JTAG command, please see (Xilinx Answer 16829).

Linked Answer Records

Associated Answer Records

Answer Number Answer Title Version Found Version Resolved
41530 Xilinx Obsolete Device Solution Center - Clocking for devices covered by XCN12026 N/A N/A
AR# 11778
Date 12/15/2012
Status Active
Type General Article