AR# 8240


Virtex/Virtex-II Configuration - The DONE pin does not go High; the INIT pin does not go Low


Keywords: Virtex, Virtex-II, configuration, startup, sequence

Urgency: Standard

General Description:
On my Virtex/Virtex-II device, the DONE pin does not go high, and the INIT pin does not go Low.


A number of problems can cause the DONE pin to remain Low while the INIT pin remains High. This Answer Record describes the common causes of this condition.

DONE staying Low and INIT staying High can indicate any of the following problems:
1. Configuration has not begun; the device did not see the synchronization word. Please see (Xilinx Answer 7891).
2. Configuration has begun but configuration data has become misaligned (see below).
3. The configuration bitstream has been loaded but the device has not entered the startup sequence.
4. An incorrect stepping level was selected in BitGen (Virtex-II devices only).

If the INIT pin is High after the configuration bitstream is sent, the CRC check has not failed (although this does not necessarily mean that the configuration data were correctly loaded).

1. Configuration has not begun.
The device has not seen the synchronization word (0xAA99556). Please see (Xilinx Answer 7891) for more details.

If you are configuring in SelectMAP mode, note that the Most Significant Bit of each byte goes to the D0 pin. For example, the hexadecimal value 0xAA is represented in a binary byte as: 1010 1010. In this case, the left-most "1" will be fed on to D0, the adjacent "0" will then be on D1, etc. Be sure that you are presenting the data appropriately on the data pin(s).

2. Configuration has begun but configuration data has become misaligned

If a bit (or byte) is added or lost during the configuration of a packet header (perhaps because of clock glitching or noise), the remainder of the bitstream will be misaligned. If a bit or byte is missed or added during an FDRI (frame data register) write (the bulk of a bitstream), the CRC check will fail and INIT will go Low. Please see (Xilinx Answer 13791) for more details.

For Virtex devices, no CRC check is performed unless the device receives an explicit CRC command. During configuration, if the device misses a bit or loads an extra bit (possibly due to SI problems with the CCLK signal, such as double-clocking), the device configuration logic becomes misaligned and does not recognize any further packets. (Data misalignment is discussed at the end of this Answer Record.) Consequently, the device never receives the instruction to perform a CRC check, and the CRC check does not fail. (Note that a CRC check never "passes" -- it can either fail or not fail.)

To reset this condition, an ABORT can be issued in SelectMAP mode (see (Xilinx Answer 8520) for more details), or the PROG pin can be pulled Low in any mode. There is no way to reset the configuration logic through the Serial or JTAG configuration interfaces. Setting the BitGen "-g debugbitstream" option (discussed in (Xilinx Answer 4219)) may be useful for Virtex devices exhibiting this symptom: the "Debug" bitstream will write data to the DOUT pin as long as the configuration data are correctly aligned. If the expected data does not appear on the DOUT pin, it is highly likely that the configuration data are misaligned.

Virtex-II features an AutoCRC check at the end of each frame that may signal a CRC error if the configuration data becomes misaligned, depending upon when the misalignment occurs. For details on AutoCRC, please see (Xilinx Answer 13790). The AutoCRC check will fail if configuration data become misaligned.

An IBIS simulation may be warranted in this situation, depending upon the board configuration. CCLK is an LVTTL 12mA buffer; the configuration signals should be simulated if the data or CCLK traces are longer than 2-3 inches.

The following causes of data misalignment have been seen in actual customer designs:
- Poor bypassing
- A floating FPGA ground plane
- Poor termination on the CCLK or data signals
- Ground bounce on the outputs of the device driving the D0..7 pins on the Virtex/II device.
- Sending corrupted configuration data (especially suspect for custom configuration solutions: microprocessors, etc.)

Another issue can affect setup and hold times on CS_B and RDWR_B for some Virtex-II devices; this problem can result in a failed configuration with DONE not going High, and INIT not going Low. Please see (Xilinx Answer 14528) for further details.

If the CRC check fails on either a Virtex or Virtex-II device, the INIT pin will be pulled Low. More information is available in (Xilinx Answer 13791).

3. The configuration bitstream has been loaded but the device has not entered the startup sequence.

This can occur when the wrong startup clock is specified in BitGen.

The three startup clock options are: CCLK, the JTAG clock (TCK), and a User clock (which is an input to the STARTUP block). The default is CCLK. You can check this option by viewing the BitGen option file (bitgen.ut file) or the BitGen report (design.bgn) to examine the command line options. The syntax appears as follows:

-g StartupClk:CCLK or
-g StartupClk:JTAGClk or
-g StartupClk:UserClk

4. An incorrect stepping level was selected in BitGen. (Virtex-II devices)

Virtex-II devices are available in three silicon versions: stepping ES, stepping 0, and stepping 1. The correct stepping level must be used when the .bit file is generated. Please see (Xilinx Answer 14339) for more information.
AR# 8240
Date 02/09/2003
Status Archive
Type General Article
People Also Viewed