Thats the name of the toplevel vhd file, and this will be the default name of the bitstream
As far as I can tell removing "set_property CONFIG_MODE SPIx4 [current_design]" has solved this issue for me
I'm using your original Arty.xdc file
I made no other change
Okay I'm going to try again from scratch and this time not remove any lines from Arty.xdc just to make sure it's not something else
Because this is completely unrelated to the I/O placement error I suspect that this is not the true reason. Maybe it is a timing problem: When you run make build the whole process runs only one thread, because fusesoc does not configure parallel jobs. When you run make build-gui and start the build interactively it runs multithreaded. I was not able to reproduce your issue with any variant I tested, but my hardware is most likely different than yours
So that it works after changing something may not be caused by the type of the change, it may just run differently, because you have "touched" a few files
That could very well be the cause
As crosscheck I just started a fresh run with make build-gui and just pressing "Generate Bitstream". Normally I work in smaller steps to check the process, but this can be the difference.
As I wrote a few days ago, the tools are a bit "fragile"
Yeah anything in parallel can be problematic
Okay it worked this time so as you guessed it has nothing to do with Arty.xdc
But I think I know what it was now
I deleted the ~/.Xilinx folder which is where it was downloading board files to
I set the "Repository Path:" to "/tools/Xilinx/Vivado/2019.2/data/boards/board_files"
so my guess is it was using board files that I downloaded from the Xilinx repo instead of the ones I installed
Remember those commands I was doing to update board files?
I think they were overriding the ones I installed from the Digilent repo
So all I had to do was make sure it was using those board files and it works now
So all this other stuff was a red herring
It doesn't even seem to matter that it has the Rev C. board
Sorry about the wild goose chase Thomas!
No problem. Such things happen. My test run also just finished, successfully. But I have also seen Vivado failing because of lack of memory. My VMs usually have only 6-8GB allocated. This is in most cases enough for a smaller Xilinx device like the Artix 7-35, but to be on the save side I add the same amount of swap as my physical memory