Actions
Forum Thread Details
  • State Verified Answer
  • Replies 12 replies
  • Subscribers 331 subscribers
  • Views 9543 views
  • Users 0 members are here
Related

Vivado 2021.1 default location of board files?

Andrew J

I've done something stupid.  In following a Xilinx tutorial for simulation, it was setting up a project using a specific board which for some reason I couldn't select.  When I went to the Vivado Store to install the board, it was already installed.  But I couldn't select it when creating a new project.  Only later did I find out that this particular board is not useable with the Webpack version, hence why it wasn't appearing.

 

Before finding that out, I ran a tcl command in order to try and find it:

set_param board.repoPaths /toos/Xilinx/Vivado/2021.1/data/boards/board_files

 

Now, I can't even find my Ultra96v2 board definition when I create a project, although that board is installed.

 

I tried:

 

reset_param board.repoPaths

 

in the hope that it would then start picking up from some default location.  No dice.

 

I don't have a board_files subdirectory and never have, yet after installing the Ultra96-V2 board it could be selected so there must be a default location for board files that isn't the directory I mention above.  Can someone tell me how to get this back to how it was?  E.g. what the default location for board_files is on Linux?  Anyone who hasn't set that param could try the following in the Tcl console:

 

get_param board.repoPaths

Parents
  • 0

    Ok....shortly after posting this I thought I'd try installing the ultra96-v1 board and see where that put stuff, with:

     

    locate ultra96v1

     

    to find anything related to that name.

     

    Pre-install, that command pointed to a board_store directory under a convoluted structure in my home folder which also contained the ultra96v2 files.  Presumably for when one selects the Vivado Store from the startup screen.

     

    When I installed the ultra96v1 board, I could see the set_param board.repoPaths parameter get set automatically to this directory structure.  Following the install of that board, my Ultra96V2 board reappeared.  So, the default value for this parameter is:

     

    /home/andrewjohnson/.Xilinx/Vivado/2021.1/xhub/board_store/xilinx_board_store

     

    i.e. set_param board.repoPaths /home/andrewjohnson/.Xilinx/Vivado/2021.1/xhub/board_store/xilinx_board_store

     

    I hope this is the answer: if anyone with a default install of Vivado 2021.1 could confirm I'd appreciate it.

  • 0 in reply to Andrew J

    I was going to bet that /toos/Xilinx/Vivado/2021.1/ should be /tools/Xilinx/Vivado/2021.1/

Reply Children
  • 0 in reply to Jan Cumps

    My spelling mistake!! 

     

    Even spelt correctly, that directory doesn't exist.  Having played around with this today, my second post is correct.  After working further with it this morning, I found two critical warnings referring to the ultra96v2 part after generating bitstream so I gave up and I rolled back my VM.  The get_param command confirms that the directory should be as I state.  Plus, it seems to be a bug in Vivado to report those two critical warnings so I didn't need to rollback the VM after all image.  No work lost so no foul fortunately.

     

    I suspect, but aren't willing to try, that if I set_param board.repoPaths to the 'typical' ...data/boards/board_files directory and put a board definition in there, then other boards already installed will stop working (not that I have any of them.)  It's not clear as Xilinx only talks about the board_files directory but makes no mention of the 'new' path for 2021.1 installs.  Again, I presume it's a change in 2021.1 but who knows??

  • 0 in reply to Andrew J

    I'm not using Linux at the moment, but I was back when I wrote these blogs. There might be some helpful info there, although I was using 2020.2.

     

    How to Leverage Board Presets to Accelerate Your Vivado Design

    Xilinx BoardStore to Automate Vivado Board Definitions for Avnet Boards

     

    Bryan

  • 0 in reply to bhfletcher

    Thanks Bryan, the second link is useful in pointing out the tools settings.  My set up is the same as you describe and the install of Vivado no longer creates and populates the board_files directory.

     

    Do You by any chance still have a simple design in Vivado for the Ultra96 created in session 2 of the workshops with the generated bitstream?  Could you open the design and check in messages if you have 2 critical warnings related to the part no?  According to Xilinx this is a legacy warning fixed in 2020 version but I’m still seeing it.  I suspect it’s a non-issue related to a missing board descriptor entry used for the board/part selection dialogue, similar to all the missing vendor entries that default to “user_grp” (or something).

  • 0 in reply to Andrew J

    Here's a screenshot from that Workshop #2 Vivado project -- no critical warnings. I think it is likely worth investigating what else is going on for you. Errors and critical warnings need addressing.

    image

     

    Bryan

  • 0 in reply to bhfletcher

    Thanks, interesting.  And this was after generating the bitstream?  I’m not the only one who has seen these warnings judging by a message I’ve seen on the Xilinx website. I wonder if it’s a Linux version thing.

  • 0 in reply to Andrew J

    Yes, bitstream generation completed successfully.

    image

     

    I talked about a strange issue I had when trying to install the MiniZed board definition when I didn't have Zynq-7000 devices installed into Vivado. The tools allowed me to install MiniZed, which appeared to succeed, but then neither the MiniZed nor my previously installed Ultra96-V2 showed up in the list. The analysis that I got from Xilinx was that it was likely a GUI issue.

     

    Most of the time, I just install every possible device because I don't care about the extra space it takes. I expect many of the Xilinx developers are the same way, which means some of these corner cases are never tested.

     

    What are your critical errors? Is your version of Linux explicitly on the supported list? Having a slightly off-version of Linux can also do strange things.

     

    Please share the Xilinx Forum link of others experiencing the same error.

    Bryan

  • 0 in reply to bhfletcher

    [Board 49-67] The board_part definition was not found for avnet.com:ultra96v2:part0:1.2. This can happen sometimes when you use custom board part. You can resolve this issue by setting 'board.repoPaths' parameter, pointing to the location of custom board files. Valid board_part values can be retrieved with the 'get_board_parts' Tcl command.

     

    The board.repoPaths is set as I mention above.  I have a reasonably complicated application that uses both the PS and PL and it works fine, even with that critical warning.  However, the warning appears irrespective of how simple the PL is, once the bitstream is generated.  I am on a supported Linux version.

     

    Here's a Xilinx forum link - I posted at the end with steps to re-create. It specifically says it can be ignored and they will be removed in 2020.1, but I still see them.  Just wondered if it was the same for yourself.

  • 0 in reply to Andrew J

    I think you jinxed me image. Now I am getting a Critical Warning.

     

    [Common 17-741] No write access right to the local Tcl store at 'C'. XilinxTclStore is reverted to the installation area. If you want to use local Tcl Store, please change the access right and relaunch Vivado.

     

    It completed, so I think I'll just ignore it at this point. I do see this AR for this particular error.

    https://www.xilinx.com/support/answers/63253.html

  • 0 in reply to bhfletcher

    can you try it this way:

    Create a new project with the board, connect the clocks, create the HDL wrapper, then.... Run Synthesis, Run Implementation, Generate Bitstream.  Don't Generate Bitstream and allow it to run synthesis and implementation.

     

    I've found that taking the three steps individually results in 2xcritical warnings, as above, and running the three steps starting with Generate Bitstream results in 0 critical warnings!