Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Thomas Hornschuh
    @ThomasHornschuh
    Yes
    Thats the name of the toplevel vhd file, and this will be the default name of the bitstream
    headkaze
    @headkaze
    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
    Thomas Hornschuh
    @ThomasHornschuh
    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
    headkaze
    @headkaze
    That could very well be the cause
    Thomas Hornschuh
    @ThomasHornschuh
    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"
    headkaze
    @headkaze
    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?
    headkaze
    @headkaze
    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
    Screenshot from 2020-04-25 17-30-18.png
    headkaze
    @headkaze
    Sorry about the wild goose chase Thomas!
    Thomas Hornschuh
    @ThomasHornschuh
    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
    headkaze
    @headkaze
    Thomas Hornschuh
    @ThomasHornschuh

    It doesn't even seem to matter that it has the Rev C. board

    As long as the board package does not contain the board file for this revision it should not matter (at least for build..)

    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...

    headkaze
    @headkaze
    I'll try to add more screenshots
    Okay Thomas thanks for your help on this
    Thomas Hornschuh
    @ThomasHornschuh
    I have written some commetns on your install.md per mail, it was a bit long for gitter
    headkaze
    @headkaze
    Thanks Thomas I'll try to go through it today
    headkaze
    @headkaze
    I'm just going through and changing a few things like making the GCC RISCV toolchain cross-compile
    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
    Thomas Hornschuh
    @ThomasHornschuh

    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
    headkaze
    @headkaze
    minicom_flowcontrol.png
    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>
    headkaze
    @headkaze
    For some reason this means it does not display
    Thomas Hornschuh
    @ThomasHornschuh
    Newer versions of minicom default to Alt as meta key instead of ctrl-a. In older you can use the option -m to switch to alt. In addition the it may be good to save the settings after changing
    Thomas Hornschuh
    @ThomasHornschuh

    One other thing I noticed is whenever you refer to a key you write it as <return>

    Sorry, I don’t understand what you are mean

    headkaze
    @headkaze
    If you search the install.md file for <return> you will see it doesn't display in the parsed version
    headkaze
    @headkaze
    Have you checked out the iCEBreaker board? I just ordered one. It has a couple of Pmod connectors and a totally open source toolchain
    headkaze
    @headkaze
    They did have a Gitter channel but have since moved to Discord https://discord.gg/sC54vsA
    They have a very active community and I think it would be great to have bonfire support for this FPGA board
    headkaze
    @headkaze
    The soft CPU they seem to be using is the Picorv32 https://github.com/cliffordwolf/picorv32/