11-28-2018 01:12 PM
Spartan 6 XC6LS4-2 custom board 144pin TQFP. All resistor values are per spec except that 2.4K in CSO_B is 2.2K rather than 2.4K. VCC_io is 3.3 volts for all banks. Using Xilinx programmer. JTAG to FPGA is fine, programs FPGA no problem. SPI core download is fine. Chip is Winbond W25Q16JV. Can erase the chip, blank check the chip. Programming hangs at 27% or so, fails with "done line did not go high".
Done line works fine when programming the FPGA directly (330 ohms with about 5K to ground. Could always reduce 330 ohm resistor if needed). 5K is two resistor base transistors to drive done LED and inform processor that FPGA is ready.
Design has ground plane under line from clock pin on FPGA to clock pin on SPI flash, 100 ohm resistors are close to SPI chip, total length is roughly 1 cm. Chip bypass capacitors on SPI memory and FPGA (lots).
Similar design (only difference is a non-inverting buffer from CSO_B to CS in SPI memory in working design.
Tried programming chip as either W25Q16V or W25Q16BV/CV; do not get "chip not recognized". SPI memory is connected as 1 wide SPI bus, no other connections from FPGA to SPI memory, no other SPI devices on that output. JTAG programming of FPGA.
ISE 14.7 used, both the old version (using win-10 with patch), also tried ISE 14.7VM with the hope that the programming algorithms are different and the chip choices are different.... no.
Also tried programming a Winbond W25Q64JV with an immediate fail, not even trying to program, blank check, or anything.
Chips *ought* to be similar enough, although the 64 additional connections could be argued (same package, some pins may have been redefined.)
So my options are:
1) fix this somehow
2) go and use a Spartan 3AN and hope that the programming fits (maybe.... not)
3) try to figure out why one design works and the other doesn't. (almost carbon copies).
4) Patch in an Atmel equivalent chip and rewire that part of the board to get it working, make next board with Atmel equivalent. Atmel equivalent did work on previous (different design) board, but then again, so did the Winbond W25Q16JV.
5) add in direct SPI programming access to the SPI memory and hope that Impact can somehow handle that without having to download an SPI core.
Application is an embedded processor driving an FPGA for hardware outputs, SPI input to FPGA (different pins completely), processor NOT present when programming, although it could be. Do not want to have to have the processor try to program the FPGA, problem where to keep the program for the flash memory (another flash memory, now how to program that....)
Comments are welcome.
11-28-2018 10:42 PM
can you share the impact.log file ?
you mentioned tried with old version of impact, have you tried 14.1 impact tool?
are you using x1 mode or quad mode? is the bitgen settings and promgen settings for mcs file creation matches?
11-29-2018 08:12 AM
OK, I have it fixed. Simple fix, but I'll go through what I saw and why so that someone else may get a better hand on the problem if it happens to them:
Short answer: Mode pins were wrong and were in slave serial, not master serial.
So, what did I see?
downloading core to FPGA is fine. Indicates JTAG is ok, cable is ok. JTAG mode overrides mode pins, so that gives no clues to mode pins.
RED HERRING (false trail....), Reading register of SPI chip came up with 0x0200, indicating quad mode. System programmed at X1, after resetting the bit. Hardware was designed for X1. Winbond chips come in two varieties depending on what the default bit is for quad. However, the bit acts the same way regardless of chip variety. Chip was programmed in X1 mode, however.
Looking at the memory pins with a scope showed activity on the appropriate pins, so data was getting to the chip, and being read back.
So the programming went to about 26%, then hung, then gave the error message "done fails to go high".
What this really means is that (in this case): 26% was the active memory area in the chip (16 megabit programming an LX4). Programming worked just fine. After programming, the FPGA is allowed to boot. In slave serial mode (not what was needed), the FPGA wants a clock. It won't get one. The system times out because the FPGA is not programmed at that point, hence the "done fails to go high, since the FPGA is not going to self program in slave serial. However, the flash memory IS.
Grounding the appropriate pin (an earlier design gave the option of slave serial), allowed the FPGA to boot up properly.
Thanks for the time.
11-29-2018 09:17 PM
Good to know issue is resolved. JTAG configuration takes priority though the mode pins are set for other configuration mode and in spartan-6 there is no mode pin setting for JTAG. So for spi flash programming JTAG mode will be used and will override any other mode pin setting. After flash programming, impact tool will initiate the configuration from flash due to the default setting this is where the mode pins are considered and was failing configuration.