cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
brainiac
Observer
Observer
10,793 Views
Registered: ‎02-19-2012

project managment in git

Hello!

 

I have a project with ZYNQ, I use block designs, xilinx ip and SDK for writing small programs in baremetal.

 

I use github, but I have vivado creates too many files for my project or when I changing it.

 

Are there any advices to manage project in github?

May be generating project from tcl, but how to clean other unuseful files?

 

Please help me!

15 Replies
jmcclusk
Mentor
Mentor
10,781 Views
Registered: ‎02-24-2014

Gitignore is the answer.   create a file .gitignore that points to the vivado subdirectory where all the compilation is done..  In general, you might only want to save very specific files in Git, like the bitstream and the debug_nets.ltx file from Vivado debugger.

Don't forget to close a thread when possible by accepting a post as a solution.
anunesgu
Moderator
Moderator
10,739 Views
Registered: ‎02-09-2017

Hi @brainiac,

 

Vivado Design provides the write_project_tcl command, which is designed to integrate a Vivado Design Suite project with any version control system. This command exports a Tcl script that recreates the current project.

 

Please take a look at the document Using Vivado Design Suite with Version Control Systems - XAPP1165.

 

Thanks,

Andre Guerrero

Product Applications Engineer

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
brainiac
Observer
Observer
10,715 Views
Registered: ‎02-19-2012

Hello!

 

I changed ip core from xcix file to simple xci file and reduced repo size from 400MB with history to 55MB of initial commit. I had about 150MB of xcix files, and that was terrible.

0 Kudos
anunesgu
Moderator
Moderator
10,682 Views
Registered: ‎02-09-2017

Hi @brainiac,

 

The ideal approach would be to use the  write_project_tcl command.

Check the image below. My example project is 133MB, and the tcl file is only 4KB. Just opening Vivado and running the TCL command source C:/.../lab1.tcl will recreate the whole project and its structures (will recreate the 133MB folder).

 

tcl_zize.JPG

Thanks!

Andre Guerrero

Product Applications Engineer

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
brainiac
Observer
Observer
10,657 Views
Registered: ‎02-19-2012

Hello!

 

I knew that way, but I have one problem - I have a repo with testbenches and I launch it in modelsim. I need ip_cores_files folder in repo.

 

 

0 Kudos
mfryba
Participant
Participant
7,685 Views
Registered: ‎08-09-2018

Vivado has changed a lot since that App Note is written; the directory structures are very different. I made a first crack at it, but had issues where portions of the tcl script still referred to full paths (I have some imported VHDL, and you almost always have custom constraints in a real project). Some meat on this would be really helpful: what options should you provide to the write_project_tcl command...where to place your secondary files relative to the tcl file so that someone can pull the repo and build from there. An example .gitignore for how you can then manage updates would help as well. So far I've manually re-done the write_project_tcl and hand-diffed in the meaningful modifications to preserve the hacks I had to make to the original tcl script.

mfryba
Participant
Participant
7,486 Views
Registered: ‎08-09-2018

Replying to my own post...on further working/reflection, I think Vivado is fundamentally f-d up when it comes to Git or similar source code management integration. write_project_tcl doesn't play well with other files in the project becaues it uses create_project to build the tree, which errors if any of the subdirectories exist. The -force option blows away any existing files, so that doesn't work either. So, by default you have to copy all the files over from wherever you cloned the repo from, which destroys the linkage to push back changes.

From some other discussions, I will have to start all over in building my repository, liberally using .gitignore and still dealing with all the embedded time stamps and crap that will exist in the .xpr file that are "fake differences". Someone who actually understands source control needs to be in the Vivado development team to integrate it into the tool.

mfryba
Participant
Participant
6,786 Views
Registered: ‎08-09-2018

Update on the Vivado and GIT saga:

Got a reasonable baseline established saving the following in the repository:

<project>.xpr (had to hand-modify away some absolute paths into relative paths, and then judiciously not allow those to back-propagate when I commit and push changes)

<project>.srcs/(various): you want to save your contraints (constrs_1/new/<file>.xdc is typical), in sources_1 you want anything from imports (imported RTL blocks) and any custom cores from ip/<core>/<core>.xci (just save the .xci and not the .xcix). For the block design, save  sources_1/bd/<name>/<name>.bd and then hdl/<name>_wrapper.{vhd or v}, then for each core invoked by the block design there is a sources_1/bd/<bd name>/ip/<core name>/<core name>.xci file that you need to capture.

In the <project>.srcs/sim_1 directory there are a few test bench files you should save; I didn't do any Vivado simulation so no real guidance there.

If you have an SDK project, then the key bits in the <project>.sdk directory are the platform HDF, your BSP directory .project, .cproject, Makefile, and system.mss (there may be more for a Linux BSP; my first one is a MicroBlaze standalone though I'm working a MB Linux now). Then, you have your project code and Makefiles, etc. in its directory. If you are taking the ELF and compiling back into your BIT file, you will want to capture that even though it's binary and gets rebuilt...the project file will complain if the ELF doesn't exist when you first load the project and then you'd have to re-add that to the Vivado project sources list if you want your ELF to be compiled into your bitstream for you (which if you want to burn it to board flash is the best option).

Hope this helps and appreciate others' lessons learned. One key complaint I have with Vivado (2018.3) is that if you pull down the project and simply rebuild it, it will move around random chunks of the Block Design (.bd) file for no apparent reason. BAD! Why does it even write it back to disk if you aren't changing it (the sticky bit in the Vivado IDE doesn't show a change)?? And even if you are changing to add stuff, you really should preserve the ordering of entities so as to not create meaningless differences in the source. If my C++ environment did that (e.g., moved class members or methods in the list randomly) I would get really ticked.

 

mfryba
Participant
Participant
5,986 Views
Registered: ‎08-09-2018

Further update...you will want to add the .bxml for the Board Design. Also, I think besides the .xci file for each IP block you need the .xml file as well. Maybe more...When I pulled down what I had before from my repository, the design built but Vivado didn't just put the "missing" IP-generated files back in the {sources}/bd/ip subdirectories for each IP block. Instead, it created a new subdirectory with a _1 appended (!!!) with the full IP in it. So again, Vivado really hates git.

gonnella
Visitor
Visitor
3,740 Views
Registered: ‎05-01-2020

I'm encountering the same problem now, how did you solve it?
0 Kudos
mfryba
Participant
Participant
3,724 Views
Registered: ‎08-09-2018

As it stands, it's like what I described above. My special sources/constraints, the .xpr and some of the bd directory files (the .bd and .bxml) and the related IP files (.xci and .xml) in each subdirectory off <project>.srcs/sources_1/bd/<bd name>/ip/<core name>

That seems to do it, though the GUI will mess around with ordering of stuff in the xpr and the .bd files for no good reason.

If you have an embedded processor, you mainly want your sources since anything else you can re-create. Once the base is stable you may wish to capture some of the generated files, but there's stuff in the eclipse directories that I haven't quite figured out what is needed.

Good luck.

 

Heliod
Visitor
Visitor
869 Views
Registered: ‎04-22-2021

Hello all,

I found this https://github.com/barbedo/vivado-git. Maybe you stumbled across this as well. It lets you use Git inside Vivado and it will generate a project generation script with relative paths which then can be pushed and run at any other machine. They offer it for some recent releases.

I tried it in Vivado 2020.1.1. It generates the project script (probably not to full extend) and stages it for commit when running "git commit" but then it makes Vivado stuck at "common::get_param...". I do not know why but maybe you can give it a go as well.

0 Kudos
mfryba
Participant
Participant
825 Views
Registered: ‎08-09-2018

I didn't try that method, but it has the similar problem that it forces the re-creation of the entire project into a clean directory any time you make a change. If I were on a multi-person team working different cores that would drive me nuts (Beyond Compare would help maintain my sanity in that case, but just barely). Vivado really has to manage projects like the software GUIs and respect maintaining the tree.

0 Kudos
pp_12
Visitor
Visitor
358 Views
Registered: ‎05-13-2021

I push .xpr file with the default path (relative to user space. After cloning the repository into another directory(abc3) and starting the projects in Vivado I see a change of two attributes:

from <Option Name="IPOutputRepo" Val="$PCACHEDIR/ip"/> to <Option Name="IPOutputRepo" Val="/home/user/work/abc2/project/code/subproject/mainsystem_sys/mainsystem_sys.cache/ip"/>

from <Option Name="IPUserFilesDir" Val="$PIPUSERFILESDIR"/> to <Option Name="IPUserFilesDir" Val="$PPRDIR/../../../../../abc2/project/code/subproject/mainsystem_sys/mainsystem_sys.ip_user_files"/>

The change is applied to the new project as if it was still located in the old directory (abc2). Probably it looks at the top path of the project file that is in the repository.

<Project Version="7" Minor="55" Path="/home/user/work/abc2/project/project/mainsystem_sys/mainsystem.xpr">

The funny thing is that the path above is changed properly to the following one:

<Project Version="7" Minor="55" Path="/home/user/work/abc3/project/project/mainsystem_sys/mainsystem.xpr">

 

Did anyone has struggled with with issue? It causes problem in propagation of changed in the IP Packaged system.

 

0 Kudos
joancab
Teacher
Teacher
350 Views
Registered: ‎05-11-2015

Gitignore is the answer

Provided you need to know what you can ignore, yes, it is.

0 Kudos