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.