Xilinx project no longer generating good binary - what have I done wrong?

[migry]

Just FYI, I have been playing with both Xilinx and Altera FPGAs for 3 or 4 years now. I have a new PC and re-installed my old FPGA folder on it. Have done work recently with Altera parts, so haven't run the Xilinx software on this PC.

I have a cheap Chinese LED controller board (RV901T). It is based on the Spartan 6 (XC6SLX16) and can be re-purposed as a dev board. A few years ago I wrote my own SUMP logic analyser software to run on this board. I programmed with a genuine Xilinx programmer. It's still wired up to an old breadboarded project.

I bought a new RV901T. There are hacks required to add a pin header and connect up the JTAG pins. I have another Chinese clone Xilix programmer. I want to use as a logic analyser.

So in order to confirm that everything is still working, and that the new "Xilinx" programmer is working, I looked for an old project called "toggle". I implements a 32 bit counter clocked by the 25MHz xtal and outputs to the parallel I/O. Looks like I modifed it too much (back in the day) and it no longer toggles. Spent half an hour stripping out the extra code. Using ISE 14.7 it now compiles OK. Using iMpact I debugged my wiring and got the JTAG working. The "Xilinx" programmer is recognised as a Digilent programmer not a Xilinx USB programmer! Nevertheless it appears to operate the JTAG chain correctly. I downloaded the toggle code, but ... nothing. Played around with the code several times, re-compiled, checked settings, still nothing on the I/O.

So I re-found the Github for the RV901T. I downloaded the bit/binary file. Downloaded using the "Xilinx" programmer and the LED blinks.

Stripped my own code down to be more or less the same as the blink LED code. Compiled, downloaded, nothing. WTF!

From the RV901T Github installed the minimal .v .xise and .ucf files. Made a new project, compiled, downloaded, and the LED flashes.

So why is my blink program not working?

Confirmed the TWO pins in the UCF (xtal and LED). Yep they're the same. The old UCF file should be still correct.
Did a diff of the blink.xise and toggle.xise files. Small differences, nothing stood out.
Checked some FPGA control pins settings (took me ages to find the menu). Same in both projects.
Tried adding ChipScope, but this didn't work. Some messages seem to indicate no clock.

My best guess at the moment is that the clock from the xtal isn't getting through, however one sketch connected an input switch to an output pin. I scoped the output pin and it didn't change when pushing the switch, so perhaps the compiled binary is wrong. I checked carefully the device settings, XC6 SLX16 -2 FTG256. I can't see anything wrong.

I am baffled. I would appreciate any sugestions of things to check.

[migry]

Well I have spent hours trying to figure out what (setting) is wrong, and I still have no answer.

I copied the working blink project folder to a new toggle folder, so that the names matched. It compiles, downloads and blinks the LED. My old toggle folder does not blink the LED.

I added code to the "new" toggle project, to toggle the I/O using a counter clocked by the 25MHz crystal. It works exactly as expected.

Of course I have deleted all re-creatable files (nearly all), but this has made no difference. For a minimal project you just need a XISE, UCF and V (verilog source). So I assume that any setting difference will be in the XISE file.

It's got to be something so obvious it is staring me in the face!

I have attached the differences between the two XISE files. I don't see anything that might explain why one area works and the other doesn't.

[jmelson]

I'd recommend trashing the entire Xilinx directory tree and re-installing ise.  I have never had anything like this happen, and used to do FPGA design on a Windows platform, but now do it on a Linux system.  I'd have to guess one of the support libraries did not install accurately.  There are tons of files that describe the physical architecture of the chips.

Jon

[migry]

Thank you for the suggestion.

TBH I'm reluctant to go through the slow download and re-install process, but it IS an option of last resort.

I do have an install of Vivado, but this does not support the Spartan6 family.

Some time ago I downloaded the Xilinx Win10 Virtual Machine for ISE 14.X. It was supposed to fix some problems with this version running under Windows10, and ironically I have had a problem with "Bitgen" when running ISE 14.7 (still good for syntax checking) in native Win10. So after the usual head scratching and googling to get the damn thing to work and see my network, I was able to copy over the good and bas "toggle" projects. I was pleasantly surprised to see that ISE was able to see the programmer without me having to jump through hoops. I compiled and downloaded the "bit" files for both the good and bad ISE projects, and for good the LED blinked and for bad the LED didn't blink.

Now this VM contains binaries "installed" by Xilinx so should be of a known good quality. So hopefully this confirms that my current Windows10 install is ISE is also working correctly (apart from the "other" known bugs).

Since my last posting I have been working on modifying some old code. For whatever reason this IS working correctly in native Windows10, and does not suffer from the issue I am seeing with the "bad"  "toggle" project. The annoying issue is that Bitgen sometimes won't generate a binary, however the work-around is to add unnecessary code to the source and re-compile. Sometimes it takes an iteration or two, but you can get Bitgen to work after a few tries/changes. I did try an experiment, and in the ISE14.X VM, the problem with Bitgen does not appear to occur, however I prefer to work in native Win10.

Just FYI, the ISE14.X VM runs a Linux distro, which can give some advantages as compared to Win10, although I have installed all my favourite Unix tools in Win10 anyway. YMMV.

[jmelson]

Wow, sounds like a mess.  The place and route tools use random seeds and genetic algorithms to optimize routing to meet timing constraints.  So, every generated bitfile will be different, and sometimes the timing results will also be quite different.  If you are not constraining timings, the tools can get lost.  At least makes sure to specify the clock frequency on all clocks.
Also, watch out for important logic that gets eliminated when the tools do not see that the output of that logic is not being used.
Jon

[migry]

I have been busy doing work on other project areas which didn't appear to suffer from this problem.

OK I finally figured it out. I put all the files into a single project area, and then copied over two XISE files, a good and bad. A "diff" of the XISE showed few differences. I edited them to get them closer to make the differences easier to see.

Extract from good.ucf:

Code: [Select]

  <files>
    <file xil_pn:name="../src/toggle.v" xil_pn:type="FILE_VERILOG">
      <association xil_pn:name="BehavioralSimulation" xil_pn:seqID="1"/>
      <association xil_pn:name="Implementation" xil_pn:seqID="1"/>
    </file>
    <file xil_pn:name="../src/rv901t.ucf" xil_pn:type="FILE_UCF">
      <association xil_pn:name="Implementation" xil_pn:seqID="0"/>
    </file>
  </files>
Extract from bad.ucf:

Code: [Select]

  <files>
    <file xil_pn:name="../src/rv901t.ucf" xil_pn:type="FILE_UCF"/>
    <file xil_pn:name="../src/toggle.v" xil_pn:type="FILE_VERILOG">
      <association xil_pn:name="Implementation" xil_pn:seqID="1"/>
    </file>
  </files>

I finally noticed that when the "bad" project was loaded the UCF did not show up in the file list. This was a surprise as it is mentioned in the UCF (as seen above). It appears to be caused by the missing "association" tag.

So it is understood. I have no idea why the UCF went bad, as I assume it was originally OK. Seeing the UCF file mentioned in both the XISE led me to not look deeper.

Moral of the story. If your Xilinx project is doing weird things, don't forget to check that the UCF is loaded into the project.

[jmelson]

I
Moral of the story. If your Xilinx project is doing weird things, don't forget to check that the UCF is loaded into the project.

OK, I have been bit by this a couple times.  But, I fairly quiclky compared the PAD report to the UCF and found that it had randomized the pad assignment.  This will, of course, completely foul everything up if you have already created the PC board.  So, I went back in and told the software to use the UCF file again, and then checked that the pad report now showed the required pin assignment.  I always check the pad report to make sure at least a few pins are right.
Jon