I just stated using Vivado in a new project and would like to put the project files under SVN.

Vivado seems to create all the project files under the project name (say proj1):

/<path to the project>/proj1/

My question is what are the files I need to put under SVN other than the XDC and the XPR file?

  • 1
    \$\begingroup\$ Why do you think that you don't need all if them? \$\endgroup\$ Mar 1, 2013 at 12:30
  • 7
    \$\begingroup\$ I don't understand what you mean here. Vivado creates a shit loads of files that do not need to be controlled since they are generated. My source files are somewhere else, i just need to save the files that are important for Vivado. \$\endgroup\$
    – FarhadA
    Mar 1, 2013 at 13:46
  • \$\begingroup\$ I'd say that since the only input is the source code, that's the only file to put under SVN. But I've never used it, just guessing \$\endgroup\$
    – clabacchio
    Mar 1, 2013 at 15:06
  • \$\begingroup\$ Is there a clean option? You could Clean then check everything in. \$\endgroup\$ Mar 1, 2013 at 15:39
  • 2
    \$\begingroup\$ I'm creating a TCL script to regenerate the Vivado project. And put that one under version control. When building the project (with make), it will create the files Xilinx needs. That prevents me to have to checkin the full project directory and files of Xilinx. \$\endgroup\$
    – vermaete
    Mar 1, 2013 at 17:34

4 Answers 4


Xilinx create a YouTube video (sigh) to deal with this. Here is the link to the video


Here is my summary of the video (8 minutes)

Before you start

If you really like full control, Xilinx suggests that you forgo the GUI entirely and do everything on the command line, and then you know what is source and what is not.

Otherwise, Xilinx realizes that Vivado projects are not designed for version control. DON'T CHECK IN THE ENTIRE PROJECT. But read on for hints...


Of course, anything you write outside of the Vivado tool should be checked in.

Check in the the following files

*.v, *.vh, *.vhdl, *.edif  - HDL and Netlist
*.xdc - Constraints
*.xci - IP Core
*.bd  - IP Integrator Block Diagram
*.xmp - Embedded Subsystem
*.sgp - System Generator Subsystem
*.cdc - Chipscope

IP blocks

If you use IP blocks, generate the IP in a unique folder, and check in everything.


If you want to be able to rerun parts of the flow without running everything, check in the checkpoint files.

*.dcp - Design Checkpoints

My Addendum

If Xilinx tools were efficient, I wouldn't recommend checking in the dcp files, but they take so many hours to run, it might be worthwhile at the cost of an ugly version control system.

The video doesn't say squat about the Vivado project files (*.xpr) so here is my suggestion:


The alternative that Xilinx recommends (which is really a hack, not suitable for version control) is to run the File -> Write Project Tcl command each time you want to commit, and then commit that TCL file to version control. When you update your local folder, you need to rerun that TCL file to create all of the project files. Yuck.

  • \$\begingroup\$ Great, that was really helpful. I no longer use SVN, but GIT, but this helps me get the right files into the repository. \$\endgroup\$
    – FarhadA
    Mar 15, 2014 at 21:14
  • 1
    \$\begingroup\$ I use the tcl files and it actually works really well. The tcl scripts only need to be updated when a file is added to a project, and usually I generate the tcl when all files are in. They aren't nearly as yucky or hacky as you make them out to be. \$\endgroup\$
    – stanri
    Jul 3, 2014 at 18:52
  • \$\begingroup\$ The TCL solution would be ideal if Vivado automatically created the TCL file after every project change AND it read the TCL file as the "project" file instead of the xpr file. In others words, if Xilinx got rid of the xpr file and replaced it with the tcl file. \$\endgroup\$ Jul 3, 2014 at 21:40
  • \$\begingroup\$ There's a slight issue with committing the xpr file: it changes every time, even when you only open Vivado... \$\endgroup\$
    – Piedone
    Mar 24, 2015 at 22:46

Vivado 2014.1 allows for the usage of .tcl scripts to regenerate projects.

To do this, with your project open, go File -> Write Project tcl.

Basic Projects

I usually store my sources and .tcl script in a location outside of the project directory. The xilinx IP cores generated within the project may be copied elsewhere by right clicking on the core and selecting "Copy IP". And deleting the original. When the tcl script is generated, it creates relative links to these files. This is usually what my directory structure looks like:


Only the IP .xml and .xci files need to be committed. (And even this isn't necessary, technically, see notes at end).

This is what gets committed to git, note the lack of project.xpr or project directories.

When I run genproject.tcl, it creates another directory for the project.


This new folder is completely disposable. In order to create this structure, I modify the tcl script in the following way.

I change the first 3 lines as follows:

# Set the reference directory for source file relative paths (by default the value is script directory path)
set origin_dir [file dirname [info script]]

# Set the directory path for the original project from where this script was exported
set orig_proj_dir "[file normalize "$origin_dir/projectdir"]"

# Create project
create_project project $projectdir/project

This creates a new project directory and the new project in that dir.

Then I modify the paths to point to the correct places. You may need to change these paths in other places in the script.

# Set 'sources_1' fileset object
set obj [get_filesets sources_1]
set files [list \
 "[file normalize "$origin_dir/srcs/project.v"]"\
 "[file normalize "$origin_dir/ip/ip1/ip1.xci"]"\
add_files -norecurse -fileset $obj $files

I also modify the design runs for IP cores as seen in this answer.

The .wcfg files can be included in a similar way to the ip and srcs.

This is where the processing ends for more simple projects (containing only sources and IP, no block diagrams). The following needs to also be done in order to store the block diagram data.

Block Diagram Projects

In order to save the block diagram, with the block diagram open, go File -> Export -> Block Diagram to Tcl, and save it in the same dir as the other tcl file.

Then I made a Generate_Wrapper.tcl script which creates the block diagram wrapper files so you don't need to do that manually. The project/project.srcs folder is used to store the bd data, but it's still completely disposable, since the bd is stored in the tcl script. Save this with the other two.

set origin_dir [file dirname [info script]]

make_wrapper -files [get_files $origin_dir/project/project.srcs/sources_1/bd/design_1/design_1.bd] -top
add_files -norecurse -force $origin_dir/project/project.srcs/sources_1/bd/design_1/hdl/design_1_wrapper.v
update_compile_order -fileset sources_1
update_compile_order -fileset sim_1

At the end of my genproject.tcl I add the following lines to generate the block diagram and wrappers:

source $origin_dir/Create_bd.tcl
source $origin_dir/Generate_Wrapper.tcl

For projects with no source (just block diagram), my git commit is just the following:


In order to generate everything, run genproject.tcl.

You can even combine all of these into one if you are particularly efficient, I haven't got round to that yet.

Custom Components: The component project

Another quick note on creating a custom component. If you have a component.xml, add that to your tcl sources list:

  "[file normalize "$origin_dir/component.xml"]"\

And then also add the following section:

set file "$origin_dir/component.xml"
set file [file normalize $file]
set file_obj [get_files -of_objects [get_filesets sources_1] [list "*$file"]]
set_property "file_type" "IP-XACT" $file_obj

This includes the component design into the project for easy customisation.

Custom Components: Referencing your component

You can spacify your custom component repo path like this:

# Set IP repository paths
set obj [get_filesets sources_1]
set_property "ip_repo_paths" "[file normalize "$origin_dir/path/to/repository"]" $obj

In my repo folder, there are individual folders containing .xml files. So you're not referencing the folder containing the .xml, but the parent of that one. Eg:


How do we run these tcl scripts?

Open Vivado, and without opening any projects, select Tools -> Run TCL script, and navigate to your script.

Extra TCL notes

Every command you run in Vivado is shown in the tcl console as a tcl command. For example, when I generated a new Xilinx IP using the GUI, this came up in the tcl console:

create_ip -name floating_point -vendor xilinx.com -library ip -module_name floating_point_0
set_property -dict [list CONFIG.Operation_Type {Fixed_to_float} CONFIG.A_Precision_Type {Custom} CONFIG.C_A_Exponent_Width {38} CONFIG.C_A_Fraction_Width {0} CONFIG.Result_Precision_Type {Custom} CONFIG.C_Result_Exponent_Width {8} CONFIG.C_Result_Fraction_Width {16} CONFIG.Flow_Control {NonBlocking} CONFIG.Has_ARESETn {true}] [get_ips floating_point_0]

This means a couple of things:

  • You don't really even need to save xilinx ip cores - once they're the way you want them, copy the commands to the tcl script and you don't need to commit ip/ anymore.

  • specify the IP directory with the -dir argument after -module_name to put it wherever you'd like (in default it's in project.srcs).

  • Mostly anything you do in the GUI can be done in tcl, the easiest way to see how xilinx does stuff is to do it in the GUI and then look at what's in the TCL console afterwards.

  • This humongous pdf details all the vivado tcl commands.


There is a Xilinx training video which explains how to use version control systems with Vivado. Basically, the list of files depends on the features you are using.

If you use a scripted approach (as vermaete does), you can have Vivado write all intermediate / temporary files to a separate directory (see here), so you can easily separate them.

Otherwise, you can cleanup the build folder by Vivado, and anything which is left might be put under version control.

  • 1
    \$\begingroup\$ Thanks, I will look into it, it is just astonishing that Xilinx can come up with a tool so expensive but doesn't even bother giving proper support for revision control with it. \$\endgroup\$
    – FarhadA
    Apr 6, 2013 at 10:51
  • 1
    \$\begingroup\$ There was an interesting comment in the Xilinx forums (from 2009 IIRC): the tools were intended for hardware engineers. And hardware engineers don't know about, and don't care about revision control. But I suppose that attitude has changed, and there are more and more SW engineers using these tools. So now revision control matters more than in the past. \$\endgroup\$
    – hli
    Apr 6, 2013 at 11:43
  • 3
    \$\begingroup\$ Well that is a pure insult who ever said those words. HW engineers use various type of revision control, many tools support that, many engineers do that using standard RC, and others use tools like Mentor HDL designer with built in RC. Sadly, FPGA vendors like Xilinx and Altera don't seem to care about these issues, and that is where the main problem is. \$\endgroup\$
    – FarhadA
    Apr 6, 2013 at 11:54

Please have a look at this thread on the Xilinx forums:


  • 2
    \$\begingroup\$ Your answer would be much more helpful if you could include some interesting content from that discussion, also because it would survive to eventual dead links (being a forum it can happen that it gets archived) \$\endgroup\$
    – clabacchio
    Apr 25, 2013 at 18:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.