The following table compares the two methods of revision controlling a Vivado project.
| Script-based | Source-based | |
|---|---|---|
| Files to check in | A script to regenerate the project
|
Project XPR and .srcs directory |
| Size | Small | Medium |
Compile time
|
Slow Must be rebuilt Must be regenerated 1 |
Medium Available immediately Must be regenerated 1 |
| External sources | Revision control separately | Revision control separately |
Read-only capable
|
Must be writable Can be locked |
Must be writable Can be locked |
|
||
Comparing the files that need to be revision controlled, the script based is much smaller. No matter if you auto generate the build script or manually create it, the only thing that needs to be revision controlled is the script. Using the source based method, the XPR file and the .srcs directory both need to be managed. These are much bigger than a text script. The benefits to using the source-based methodology is that the project is available immediately. Once you check out the XPR file and the .srcs directory, you can open the project. Using the script-based methodology, the script needs to run to completion before you can open the project. In both cases, Xilinx does not tend to revision control output products, and therefore to recompile the designs, there will be considerable compute time spent recreating the output products. In both cases, if an external cache is maintained, the compile time can be reduced significantly.
The remaining items are similar between the two flows. In both cases, all external sources need to be revision controlled separately from the project. Also, in both cases, Xilinx does not fully support having BDs or IPs completely read-only. BDs must be writable to run validation. Running validation updates XCI files under the BD directory structure even if there are no design changes. IP can be read-only, but if they are in this state the IP will be locked and unable to upgrade.