4
\$\begingroup\$

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.

\$\endgroup\$
7
  • \$\begingroup\$ Did the design work correctly in simulation? \$\endgroup\$
    – user16324
    Commented Dec 6, 2013 at 9:38
  • \$\begingroup\$ Yeah works perfectly in simulation. More to the point the identical RTL works perfectly on on a xilinx development board with a daughter card I designed for the vga dac. \$\endgroup\$
    – Doov
    Commented Dec 6, 2013 at 16:51
  • 1
    \$\begingroup\$ So this instance is on your own board. Possibly worth exploring PSUs, I/O bank voltages (are all the failing pins on the same bank?) I/O Vref connections etc. \$\endgroup\$
    – user16324
    Commented Dec 6, 2013 at 18:01
  • \$\begingroup\$ That's a good question -- I will explore further today. The PSUs look good -- very clean/flat. The I/O bank voltages are all the same -- 3.3V, but I'll check the bank issue. That's an interesting point. Thanks \$\endgroup\$
    – Doov
    Commented Dec 6, 2013 at 18:16
  • \$\begingroup\$ This sounds to me like a power orissing ground pin issue. The chances that the FPGA configures wrong are very very small. With your tests, I guess you have some problems on your board. \$\endgroup\$
    – FarhadA
    Commented Dec 8, 2013 at 1:32

1 Answer 1

6
\$\begingroup\$

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.

\$\endgroup\$
7
  • \$\begingroup\$ Does it confirm the CRC when using SPI configuration? I know it verifies when using jtag to directly program the part. I would tend to agree with you, but the same RTL works without issue on a xilinx development board. \$\endgroup\$
    – Doov
    Commented Dec 6, 2013 at 16:51
  • \$\begingroup\$ Doesn't matter where the bitstream comes from - JTAG, SPI, SelectMAP - the startup and configuration sequence is the same and the CRC is always verified as a part of the sequence. \$\endgroup\$ Commented Dec 8, 2013 at 5:58
  • \$\begingroup\$ Also, have you tried resetting just your logic without triggering a reload of the FPGA configuration? Does a reset of your logic fix the problem when it occurs, or only a configuration reload? \$\endgroup\$ Commented Dec 8, 2013 at 7:03
  • \$\begingroup\$ Thanks for the info, @alex.forencich. That's good to know that the CRC is always verified. Unfortunately the logic reset doesn't seem to fix the issue. \$\endgroup\$
    – Doov
    Commented Dec 9, 2013 at 20:28
  • \$\begingroup\$ So based on the CRC info it appears as though you've addressed the answer to this question. I've been debugging more and it looks like there's definitely another issue (put a scope probe on done for a while and it looks like it toggles low occasionally, which I hadn't noticed before). Will investigate further. Thanks for your help. \$\endgroup\$
    – Doov
    Commented Dec 10, 2013 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.