Xilinx’s tools seems to always come with their fair share of problems.

I installed the latest version, Xilinx Vivado 2016.4, hoping that I could avoid hacky fixes to get it running (and playing nice with Windows 10, too!)

I was wrong.

(Turns out that this is normal, just look at the sample projects in “Zynq SoC Training” from EmbeddedCentric.com!)

Current grievances:

  • Bad workflow when developing a custom IP.
  • Plenty of “Vivado Internal Exception” messages popping up every now and then.
  • Vivado crashing / all windows suddenly close. This frustratingly happens again and again and again. (>Angry react here<)
  • Other small things
  • Having to re-create the entire project again (and block diagram) – I started writing a simple tcl script.
  • Xilinx SDK errors, needing to re-create the entire project even more times.
  • Xilinx SDK ‘Internal error’ dialogs popping up.
  • Xilinx SDK ‘Out of memory’ errors when generating BSPs.

Apart from the crashing, the solution for most problems can usually be found on the Xilinx community forums.

For crashing, the solution is to simply restart the program (Vivado / Xilinx SDK).

Having used ISE in a previous course, I expected to migrate to Vivado just as a “real-life” working engineer would. But maybe – just maybe – as a student I perhaps am doing something terribly wrong…

If this is truly the state of FPGA system design software, I (and my classmates) admire those who use this software “for real” full-time.

😥😪😢

Some quick fixes:

Vivado doesn’t actually start, gets stuck on Microsoft Visual C++ 2012 Redistributable (x64) installer

Solution: Find `xvcredist.exe` in `C:\Xilinx\Vivado\2017.1\tps\win64` and delete it.

“Launch SDK” doesn’t actually start the SDK, gets stuck on Microsoft Visual C++ 2012 Redistributable (x64) installer

Solution: Find `xvcredist.exe` in `C:\Xilinx\SDK\2017.1\tps\win64` and delete it.

2016.4: Debugging by “Launch on Hardware (GDB)” fails

The following error appears:

No Elf file associated with target

This is a Xilinx bug!!!

Solution: https://www.xilinx.com/support/answers/68503.html

SDK: “No Target with ID 64 in the System”

Open the “XMD Console” and run the following commands

connect arm hw
rst -debug_sys

In 2016.4, XMD was changed to something else, so the above doesn’t work.

Turn the board off and on again. Then restart the SDK and try again.

Other general advice:

1. Check the known issues

With regard to working with any of Xilinx’s tools ~~ seriously, you can literally save hours! ~~ if you find and check the webpage of KNOWN ISSUES for your version of Vivado. Whenever you get stuck, it is actually quite possible that you’ve simply run into a bug for that release.

2. If your simulation waveforms are showing a heap of unexpected “Undefined” UUUUUUUU values, check that the Simulation box is checked for each design file.

This one got me so many times. Under Design Sources, ensure that the checkbox for Used in Simulation is ticked.

Screenshot

3. Re-adding sources didn’t work? Check the Tcl console

As I sometimes mess up the design flow in Vivado (e.g. forgetting to press ‘merge file changes’ or something before hitting ‘Package IP’) I often need to re-add the source VHDL files back again. But, it’s really important to untick the “Copy sources into IP” checkbox because the files are already where they should be. The operation failure happens silently, and I only found out why from staring at the Tcl console. You should too.

Screenshot Untick this box!

4. Save early, save often

Dead serious, the VHDL code editor can be super buggy.

5. Delete stuff to fix makefiles in the SDK

Importing C code files into the Xilinx SDK can break the *.mk files used to Make the executable.

For example, subdir.mk does not get auto-re-generated.

To fix this, delete the Debug folder and then run a “Clean project”. This forces the mk files to be re-generated. Excellent.

6. When “Edit in IP Packager” asks you to select a directory, don’t go with the default.

If you simply accept the default path, Vivado picks one with *.tmp

``This means exactly what it looks like – a temporary directory. This directory gets completely overwritten the next time you “Edit in IP Packager” if you again accept the default path, potentially loosing any unsaved work if had forgotten to “Package” the IP before closing the project.

Don’t do this! Select your own path when you click “Edit in IP Packager”.

After doing so, you can open the IP project directly as its own Vivado project the next time you wish to resume working on the IP project.

Well, that’s about it for now.

Good luck.

 

 

Update: I also tried Vivado 2017.1, and unfortunately managed to crash it pretty quickly, and then again later that night, and again late during the night, and then much later into the early morning… 🙁 🙁 🙁

The UI changed a bit in the 2017.1 release, watch the walkthrough video if you’re interested in UX stuff. Still has a few UI quirks though:

Screenshot