I just go to program the .bit file after "Generate Bitstream" and there is no bit file
You have to navigate to it manually in hardware manager, it does not show it automatically in most cases
Thats the name of the toplevel vhd file, and this will be the default name of the bitstream
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
As I wrote a few days ago, the tools are a bit "fragile"
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?
So all this other stuff was a red herring
It doesn't even seem to matter that it has the Rev C. board
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
Did you check out the updates I did @ https://github.com/headkaze/bonfireprocessor.github.io/blob/master/install.md
Did you check out the updates I did @ https://github.com/headkaze/bonfireprocessor.github.io/blob/master/install.md
Thanks for the work, will look into detail tomorrow, I'm to tired now...
Okay Thomas thanks for your help on this
I also think we should include the instructions to disable flow control for minicom
Otherwise you get no response from the monitor and it feels like it has failed when it hasn't
I also think we should include the instructions to disable flow control for minicom
Maybe we can deliver a minicom configuration file as described here https://cris.bytesnblades.net/2009/03/24/managing-minicom-settings/
Describing the interactive flow to change this settings will increase the length of the quick setup guide a lot
Unfortunately there is no command line option to switch of flow control
The flow control is the only config change you need to get output
Even if it's mentioned that both settings need turning off
One other thing I noticed is whenever you refer to a key you write it as <return>