9

I have a JTAG chain connecting 4 Spartan 6 FPGAs that I program using ISE iMPACT. The software can program any strict subset of the 4 FPGAs in a row successfully, and in any order. However, when I attempt to program all four FPGAs, the DONE pin of the last FPGA does not go high, and the programming fails.

What could be causing this strange behaviour?

Notes:

  1. After programming three of the FPGAs, the INIT_B bit of the status register for the fourth FPGA is 0, although the INIT_B pin is high. Right before programming the third FPGA, that bit was 1. This suggests the fourth FPGA has locked up.
  2. When programming with SelectMap, I can program all four FPGAs without any problem.
  3. When I program three of the FPGAs using SelectMap, the fourth one still cannot be programmed using JTAG.
  4. Each of the four done pins are pulled-up to 3V3 through 4.7K Ohm resistors, and then tied together.

Things I have tried:

  1. Disconnecting one of the FPGAs from the chain allows for the remaining 3 FPGAs to still be programmed.

  2. Swapping the 4.7K Ohm pull-up resistor of the last FPGA for a 330 Ohm resistor doesn't solve the problem.

Randomblue
  • 10,953
  • 29
  • 105
  • 178
  • 2
    What do you mean by "last FPGA"? Because in the User Guide is says `"The first device in a serial daisy chain is the last to be configured."` Do you mean last in the chain or last to be configured (first in the chain)? Could you provide a schematic? – embedded.kyle Jun 27 '12 at 13:19
  • 2
    This statement on p59 makes me think otherwise, `"If the Spartan-6 device is configured via JTAG, the configuration instructions occur independent from the mode pins."` – embedded.kyle Jun 27 '12 at 14:14
  • After familiarizing myself with the User Guide (it's been about 6 months since I've done FPGA work), I'm a bit confused by your terminology. Daisy Chain is used in conjunction with serial programming. In which case, the `DONE` pins are tied together. For JTAG, multiple device programming is called Boundary-Scan Chain. In `Chapter 3: Boundary-Scan and JTAG Configuration`, the only mention of the the `DONE` pin is `"If JTAG is the only configuration mode, then PROGRAM_B, INIT_B, and DONE can be tied High to a 330 resistor."` So is the `DONE` pin low the only problem? Does it program correctly? – embedded.kyle Jun 27 '12 at 14:20
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/3902/discussion-between-embedded-kyle-and-randomblue) – embedded.kyle Jun 27 '12 at 14:30
  • I think the fact that you can get 3 but not 4 is a clue. Check out Chapter 4 of the JTAG Programmer Guide on Designing Boundary-Scan Systems: http://www.xilinx.com/support/sw_manuals/2_1i/download/jtag.pdf – embedded.kyle Jul 06 '12 at 13:00
  • @embedded.kyle: The fact that the status register is not being refreshed to reflect the correct status of `INIT_B` suggests that the fourth FPGA freezes: `Spartan (not the SpartanXL) devices freeze if data errors occur during boundary-scan configuration` (taken from Chapter 4). – Randomblue Jul 06 '12 at 13:35
  • It doesn't specifically mention the Status register, though I do agree with you. Have you tried a verify or an EXTEST as it suggests? – embedded.kyle Jul 06 '12 at 18:16

2 Answers2

6

The DONE pin in not used during JTAG programming and can be tied high:

If JTAG is the only configuration mode, then PROGRAM_B, INIT_B, and DONE can be tied High to a 330Ω resistor. (p57)

However, if Serial programming is used, then all the DONE pins should be tied together and the DriveDone should be disabled for all devices except the first:

It is important to connect the DONE pins for all devices in a serial daisy chain. Failing to connect the DONE pins can cause configuration to fail. (p135)

All devices except the first should disable the driver on the DONE pin. (p135)

If both are to be used, there are two options:

Alternatively, the driver can be disabled for all DONE pins and an external pull-up resistor can be added to pull the signal High after all devices have released it. (p135)

For debugging purposes, it is often helpful to have a way of disconnecting individual DONE pins from the common DONE signal, so that devices can be individually configured through the serial or JTAG interface. (p135)

In your case, I think connecting them and tying them all high while disabling the DONE pin is the best way to go.

All page numbers reference the User Guide

embedded.kyle
  • 8,411
  • 2
  • 26
  • 44
  • Hmmm...If you tied `INIT_B` high and the `INIT_B` bit in the status register is 0, that would indicate a hardware failure to me. Unless you can program that chip independently which I think you said you could. The `DONE` pin goes High-Z while programming so I don't know what the status register does during that point. If the previous FPGA status register's LSB is 1, then that indicates a CRC error in that device which may prevent programming of the next. – embedded.kyle Jun 27 '12 at 17:11
  • Problem found (see my solution). Thank you for your help. – Randomblue Jul 19 '12 at 12:20
3

It turned out the culprit was the INIT_B pin. Although pulled high, as the first few FPGAs were programmed, the INIT_B pin was gradually pulled lower and lower because of an internal pull-down.

After three FPGAs were programmed, the INIT_B pin was pulled low enough for the fourth FPGA to interpret INIT_B as a logic low, thereby preventing the fourth FGPA to be programmed with JTAG.

Randomblue
  • 10,953
  • 29
  • 105
  • 178
  • Thanks for sharing the root cause. I kept checking this question for an answer since it was such odd behavior. What was the solution to the problem? A stronger pullup than the 330 \$\Omega\$? – embedded.kyle Jul 19 '12 at 13:19
  • It turns out there are bitgen options to specify that the `INIT_B` pin be pulled up instead of pulled down after programming. – Randomblue Jul 19 '12 at 13:44