# Which is the best way to version control Xilinx PlanAhead projects?

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.

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_files $hdlDir # Add IP cores add_files$ipsDir/ip0/ip0.xco
add_files $ipsDir/ip1/ip1.xco add_files$ipsDir/mb/system.xmp

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.

• 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. – Francesco Conti Apr 8 '15 at 17:51
• Francesco, do you have a link talking about version control of .xpr projects? – David Quiñones Apr 9 '15 at 7:27
• 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? – David Quiñones Apr 9 '15 at 7:45
• 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. – Jonathan Drolet Apr 9 '15 at 12:43
• 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! – Jonathan Drolet Apr 9 '15 at 15:24