Shulou(Shulou.com)06/02 Report--

This article will explain in detail how to use Git for Vivado project management, the content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

I don't have to say how good    git is, it's one of the essential skills for programmers. For general software code, only the source files need to be managed by git. But for FPGA engineers, using git is more or less painful, and there are mainly the following problems:

In projects with bd files, it is not possible to add only bd files to git.

Many companies will have some accumulated hdl files, put them in a folder, and all the project directories will have this folder, so there will be many files in this file that are not the current project, so the git file must contain the files list of the current project, otherwise you will have to add the file again.

If you put the whole Vivado project into git, there are too many unnecessary files, which will not only waste the space of the git server, but also slow the speed of Push and Pull.

Many FPGA engineers have their own git process for managing Vivado, but there is a lot of work to be done before and after each push.

   recently I have also been studying the management of Vivado project git, looking up a lot of methods on the Internet, but some operations are a little complicated, and some methods are completely ineffective, but fortunately, I finally sorted out a relatively simple way to carry out, perhaps this way is not the most appropriate, if you have a better way, I hope to share it.

We only talk about Vivado projects, not HLS or Sdk projects, because these two tools are pure C/C++/TCL, and git management is relatively simple.

1. Engineering catalogue

   We adopt the following directory structure, which is also recommended on a tutorial on Xilinx's official website.

Work directory: all Vivado projects are placed in the Work directory, including bd and its related files

Src directory: source files for hdl and IP Core

Doc directory: put the documents related to the project, if not, you can not add them.

Mcs directory: put the bit and mcs files generated by the project. This file also depends on personal use. It doesn't matter if you think the bit file is too large and you don't want to put it on git, but personally, you will often test a bit before debugging.

Scripts directory: also the key to git management, with various Tcl scripts in it

If there is a SDK/HLS/SsyGen in the project, you can add a folder under this directory to place the corresponding project files.

Image

two。 Operation steps

In the open Vivado project, change the directory to the Work directory through Tcl Console:

Cd [get_property directory [current_project]]

Generate the Tcl script for the new project and execute:

Write_project_tcl {. / Scripts/s1_recreate_project.tcl}

Generate the tcl script of the bd file in turn, for example, there are two bd files aa.bd and bb.bd in the project, open aa.bd, and execute:

Write_bd_tcl {. / Scripts/s2_aa_bd.tcl}

Open bb.bd and execute:

Write_bd_tcl {. / Scripts/s3_bb_bd.tcl}

In this way, there will be three more files in the Scripts folder:

Image

To be replaced by:

Image

Change to the Scripts directory

Image

Execute in turn:

Source. / s1_recreate_project.tcl

Source. / s2_aa_bd.tcl

Source. / s3_bb_bd.tcl

OK, the project will be completed by Clone at this point!

Here are some of the problems I encountered in the process of operation:

If it is the MIG IP Core of DDR3, there will be Configuration Files. If we modify the MIG and regenerate it, it will often happen that the Configuration Files cannot be found, like the following:

Image

This requires us to replace this file with the correct file before exporting s1_recreate_project.tcl. If the MIG is placed in the bd, then delete the mig_*.prj file in the modification of the s1_recreate_project.tcl in step 6 above, because it is automatically generated when the new MIG is created.

Some friends like to use wrapper.v files to seal a layer when using bd, this wrapper.v is automatically generated by Vivado, and the default directory is under the project directory of Work, we can ignore the wrapper.v file, wait for the bd file to be added, and then manually generate it; you can also instantiate the bd file directly without using wrapper.v.

The above method is tested on Vivado2017.2. For version 2017.4 or above, the-use_bd_files option needs to be added to the write_project.tcl directive, that is:

Write_project_tcl-use_bd_files {. / Scripts/s1_recreate_project.tcl}

If you do not add this option, the bd file information will also be exported by default, so that there will be no errors found in the bd file at run time.

If you want to open it with a higher version of Vivado after git in a lower version of the project, we can remove the version information of IP when exporting bd, that is:

Write_bd_tcl-no_ip_version {. / Scripts/s2_aa_bd.tcl}

   I have tried many methods on the Internet can not be used directly, but since they put the method on the Internet, it shows that it has been tested, but the test may not be very comprehensive, just like the IP of MIG. If I do not have this IP in my project, then I do not know that this problem will occur in git. I can not guarantee that there will be no problems when using other IP, but the idea is the same, that is, separate the tcl script of the project from the tcl script of bd, first add the contents of non-bd files to the new project, and then add the contents of bd files.

On how to use Git for Vivado project management is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.