4

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.

Doov
  • 1,138
  • 6
  • 20
  • Did the design work correctly in simulation? –  Dec 06 '13 at 09:38
  • 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. – Doov Dec 06 '13 at 16:51
  • 1
    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. –  Dec 06 '13 at 18:01
  • 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 – Doov Dec 06 '13 at 18:16
  • 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. – FarhadA Dec 08 '13 at 01:32
  • How is your design reset? – Martin Thompson Dec 09 '13 at 11:13
  • Thanks for all the feedback -- the design has a synchronous reset, which is generated by a microcontroller. The micro monitors the state of the done pin as well as a few other peripherals and pulses an i/o to the fpga. The fpga synchronizes the reset pulse to the various clock domains. I will continue to debug the board. So far the supplies look good, but I'll try to see if there isn't ground bounce I haven't found yet. – Doov Dec 09 '13 at 18:44

1 Answers1

6

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.

alex.forencich
  • 40,694
  • 1
  • 68
  • 109
  • 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. – Doov Dec 06 '13 at 16:51
  • 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. – alex.forencich Dec 08 '13 at 05:58
  • 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? – alex.forencich Dec 08 '13 at 07:03
  • 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. – Doov Dec 09 '13 at 20:28
  • 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. – Doov Dec 10 '13 at 21:18
  • Interesting. If the DONE pin is toggling low occasionally, it's possible that the FPGA is getting reset. You might want to check the PROG_B pin and also check the FPGA power supply rails with the scope to make sure there isn't anything funny going on. – alex.forencich Dec 10 '13 at 23:42
  • I thought the same thing. I do have a reset circuit that a button can drive (this in turn drives prog_b). There may have been a cold solder joint on a pull up resistor...it's looking better, but still some stuff to debug. Thanks for your help! – Doov Dec 11 '13 at 00:16