Actually I'm migrating some mature projects from Xilinx ISE to Xilinx PlanAhead. I need to take advantage of TCL scripting and partitioning of PlanAhead.

This ISE projects are under version control in a SubVersion repository, so I need to define the files that must be under version control but in PlanAhead projects.

On one hand, this question talks about the files needed to put under version control to exactly re-create the implementation results. Even in PlanAhead 13.2 exist the command "File->Archive Project..." that save the sources and other project and option files in a ZIP archive, allowing us identify the files that must be under version control. This is the first choice.

But on the other hand, it is not clear that use this collection of files is the right way to manage a version control for a PlanAhead project. This xilinx forum conversation talk about using a tcl script to re-create the full project, but this script must be maintained apart when a new change is introduced in the PA project

Vivado (son of PlanAhead) have the XAPP1165 application note that talk about version control and recommend put the re-creation TCL script under version control, but Vivado can generate automatically this TCL script.

I would to know which is the best way to version control PlanAhead projects. Identifying needed files or maintaining a re-creation TCL script?

Thank you very much for your responses. Best regards.


1 Answer 1


My personal workflow (I mention planAhead, but vivado is similar), with goal to add as little as possible to source-control:

  • Files exist outside the planAhead project directory. Take care since if you use the GUI to add/create files, it will likely be inside the project directory.
  • IP cores exists in my source directories, one sub-folder by IP core.
  • Every HDL source is source-controlled, as well as every .xco/.xci, *.xmp, *.mhs, constraints files, etc
  • Simulation sources are located in a separate folder than synthesize sources to set up her properties easily.
  • The planAhead project directory/.ppr is not source controlled.
  • The IP core/microblaze generated files are not source-controlled. This is up to debate, I think if you add *.ngc, *.vhd, *.v, *.xise you won't have to regenerate the cores every time you checkout from source-control, which can save you a large amount of time. I barely use IP cores at all in my own projects, but if you use a lot you may want to look into this.

Then, I add a script to create the project in source-control:

# Obtain the script directory and pass to a variable
set projDir [file dirname [info script]]
# Change active directory to directory of the script
cd $projDir

# Define directories labels
set hdlDir ./src/hdl
set simDir ./src/sim
set ipsDir ./src/IPs
set conDir ./src/constrs

# Define other labels
set projName projectname
set topName toplevel
set device partname

# Create project in prj directory
create_project -force $projName prj -part $device

# Add simulation files from sim directory and disable synthesis property
# Do it before adding any other source!!
add_files -fileset sim_1 $simDir
set_property used_in_synthesis false [ get_files -of_objects [get_filesets sim_1] -filter {FILE_TYPE == VHDL || FILE_TYPE == Verilog} ]

# Add HDL sources
add_files $hdlDir

# Add IP cores
add_files $ipsDir/ip0/ip0.xco
add_files $ipsDir/ip1/ip1.xco
add_files $ipsDir/mb/system.xmp 

# Add constraints
add_files -fileset constrs_1 $conDir

# Set VHDL libraries
set_property library awesome_lib [get_files $hdlDir/awsome_library/*]

# Set top module
set_property top $topName [current_fileset]

make_wrapper -files [get_files *.xmp] -top -fileset [get_filesets sources_1] -import

If you organize your sources files appropriately, the script should need a minimal amount of lines and not need to change when you add source files. Since the script is in source-control, it should stay in sync anyways (you do have to maintain it, since I expect you will use the GUI in your everyday use).

You should be able to start from there and add what you need. If you are not aware, most of what you do in planAhead GUI is a TCL command. You can see what commands were executed by going File->Open Journal.

  • \$\begingroup\$ I agree, this workflow is the same I use in Vivado and it is very flexible, even for very complex projects. One note to add in the latest versions of Vivado (> 2014.3 I think) it is actually possible to use the .xpr file (equivalent to PlanAhead's .ppr) to recreate the project; that feature was explicitly added to allow version control of it. \$\endgroup\$ Commented Apr 8, 2015 at 17:51
  • \$\begingroup\$ Francesco, do you have a link talking about version control of .xpr projects? \$\endgroup\$ Commented Apr 9, 2015 at 7:27
  • \$\begingroup\$ In my projects I need to create several runs with differents parameters, so to maintain the re-creation script I must record all the set_property TCL commands logged in the .jou file. That's right? Also, what happen with promoted partitions? I'm just starting to work with them, but I think they are some AREA_GROUP constraint and the resulting netlist. Can be the promoted partition version controlled? \$\endgroup\$ Commented Apr 9, 2015 at 7:45
  • \$\begingroup\$ Yes, you will have several set_property and create_run if you want something else than default settings. The AREA_GROUP constraint goes into your .ucf, AFAIK this is all there is to it. \$\endgroup\$ Commented Apr 9, 2015 at 12:43
  • \$\begingroup\$ Yes, that script come from a 14.7 project, it may not work as is on older versions. Xilinx stopped working on ISE/planAhead, 14.7 is the final version, if you can, I suggest you upgrade! \$\endgroup\$ Commented Apr 9, 2015 at 15:24

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.