I have a spartan 6 board that I designed and am having some configuration issues. I'm using SPI flash to program the fpga (e.g. I use jtag to write the flash and the flash then writes the fpga). The schematic I used for the configuration can be found on page 42 of UG380 from xilinx. http://www.xilinx.com/support/documentation/user_guides/ug380.pdf
Most of the time I'm able to program the device without issue using either the jtag interface (directly programming the fpga) or the spi flash (indirectly programming the fpga) — everything comes up as expected. There are, however, instances where it seems as though the fpga doesn't configure properly despite the fact that the done pin goes high (I have an LED indicator on the pin and have monitored with a scope). This manifests itself in a few different ways. Among other things this board drives a VGA dac. I wrote a test bench to drive color bars to a monitor. 75% of the time if I reset the board (hard pressing a button that drives program_b low) the color bars come on as expected. 25% of the time I get nothing out of the vga dac. It seems as though some of the pins that drive the dac don't toggle (the 75% of the time everything works correctly they do toggle). In addition to the dac I have a test led that I drive with the msb of a counter, which just divides the 100 MHz system clock so that it blinks ~twice a second. That pin seems to come up without issue every time.
Given these observations I'm wondering if it's possible that sometimes the fpga isn't properly configured — or perhaps is partially configured (e.g. the pin driving the led comes up without issue, the pins driving the dac don't). The xilinx user guides indicate that the configuration routing is pretty sensitive — in particular the configuration clock needs to be properly terminated. I'm wondering if it's possible that the there's a layout issue, which causes the fpga to occasionally botch configuration. I'm not super familiar with the way the configuration actually works (especially with regards to verification) — it's always "just worked" on my previous boards, but it seems odd to me that the done pin goes high every time without a hitch, but I'm still seeing this behavior.
Best Answer
It's not really possible for the FPGA to exit the start up routine with a corrupted configuration as it confirms the CRC of the configuration after the complete configuration is loaded, but before it tries to start up. If it does not match, then the DONE pin stays low and you can check on what happened by reading the status bits over JTAG.
Since it seems like the configuration is always completing with the DONE pin released and your divided clock output is working, my guess is you may have a metastability issue or initialization issue in your design that you haven't caught yet.