User Tools

Site Tools



The purpose of this technical note is to enumerate the steps to upgrade a Vivado project directory from some earlier version of Vivado to some more recent version, in the process allowing Vivado to generate warnings about any IP that might have been adjusted or ignored during the process due to the upgrade.


This process requires some fairly obvious components:

  • Two installed versions of Vivado.
  • A Vivado project directory compatible with the earlier version of Vivado, which will be upgraded.

In this example, we will upgrade a Vivado 2018.2 project directory to 2018.3

The structure of a Vivado project directory

Minimally, a Vivado project directory should have a structure something like this:

$ tree
├── docs
│   └── holder
├── loads
│   └── holder
├── scripts
│   ├── bd.tcl
│   └── project_all.tcl
└── vivado
    ├── constraints
    │   ├── 00_debug.xdc
    │   ├── 10_timing_clock.xdc
    │   ├── 11_timing_external.xdc
    │   ├── 12_timing_internal.xdc
    │   ├── 13_timing_multicycle_path.xdc
    │   ├── 14_timing_false_path.xdc
    │   ├── 15_timing_others.xdc
    │   ├── 20_physical_external.xdc
    │   └── 21_physical_internal.xdc
    └── projects
        └── holder

There is no need for the directory to contain any generated artifacts from a previous Vivado run.

The project can comment out the final several steps for the 2018.2 processing in the project_all.tcl file – there is no need to do any of that in the first phase, and it will all be done manually in the second phase, anyway. See below to appreciate what can be commented out so that it is not performed in the first phase of the processing.

#Compile Project
# reset_run synth_1
# set_property strategy "Vivado Synthesis Defaults" [get_runs synth_1]
# launch_runs synth_1
#wait_on_run synth_1

#Implement Project
# set_property strategy "Vivado Implementation Defaults" [get_runs impl_1]
# launch_runs impl_1
# wait_on_run impl_1

#Generate Bitstream
# launch_runs impl_1 -to_step write_bitstream
# wait_on_run impl_1

##Create SDK HDF
# file mkdir ./projects.sdk
# write_hwdef -force  -file ./projects.sdk/DMA_PCIe_EP.hdf


Processing 2018.2 project

Source 2018.2 Vivado environment:

$ source .../

cd to the underlying projects/ directory (you must be in that directory if the project Tcl file uses silly ../../ references), and start Vivado 2018.2:

$ cd .../vivado/projects/
$ vivado

At this point, run project_all.tcl, then exit Vivado.

  • Tools→ Run Tcl Script → project_all.tcl
  • Exit

The result of this is to generate, among other things, the 2018.2 version of the .xpr project file that will be used in the second phase of the upgrade.

Upgrading the project by running Vivado 2018.3

From exactly the same directory as in the previous section, source the environment for Vivado 2018.3, then execute Vivado:

$ vivado

At this point, open the project file produced in the previous section, and upgrade it via the operations:

  • Open Project → .xpr file → Upgrade
  • “Report IP Status” → “Upgrade Selected”

It is entirely possible that you will get warnings about IP that can't properly be upgraded, so look for warnings or errors along the lines of:

[Coretcl 2-1279] The upgrade of 'DMA_PCIe_EP_xdma_1_0' has
identified issues that may require user intervention. Please
review the upgrade log '.../vivado/projects/ip_upgrade.log',
and verify that the upgraded IP is correctly configured.

At this point, you can use Vivado to complete the upgrade of the project as normal:

  • Synthesis
  • Implementation
  • Generate bitstream
  • Export hardware (hdf)

Provided that all of the above runs successfully, you can import the newly-generated .hdf and .bit files into the corresponding newer version of PetaLinux as normal.

xilinx_upgrading_vivado_project.txt · Last modified: 2019/05/30 12:49 by rpjday