I haven’t touched this project in a while, and I don’t plan to start spending more time maintaining it.
If someone reports a bug, I’ll try to find time to look at it. But, consider this project mostly abandoned.
Vivado projects can be difficult to version control. Vivado generates a lot of files and constantly touches files to add time stamps. Tracking changes in these files can be difficult.
This project provides tcl scripts, wrapped in cmake functions, that interface with vivado and place the generated files in a build directory that need not be tracked by version control.
This enables the developer to have a reproducible build process that only relies on source files.
viv-prj-gen can also generate a vivado project, so that users can develop using vivado’s gui without tracking a xpr file.
viv-prj-gen provides cmake functions in an includable cmake file, which makes it easy to extend without forking.
Viv-prj-gen does not directly support automated simulation. Viv-prj-gen does not support tools other than vivado. That said, wrapping python frameworks that support simulation of vhdl and verilog in cmake is possible. Two of the demos in https://github.com/TripRichert/cmake_fpga_demos (blinky and blinky2) show two different approaches for invoking edalize to simulate from cmake.
To use this tool, you need vivado installed on your system. vivado provides a script either settings64.sh or settings64.bat, that you need to source so that your commandline can use it.
Vivado has a built-in distribution of cmake. You can follow the tutorial here:
The documentation of the api is here
To see what the syntax looks like, you can look in the Examples section. To see working demos, https://github.com/TripRichert/cmake_fpga_demos
Before digging too far into my stuff, there are some good alternatives out there that try to do similar things.
All of them use tcl under the hood, but when interfacing with the developer, some take different approaches.
- Edalize
-
python based, vendor agnostic, supports synthesis and simulation
- hdlmake
-
python based, vendor agnostic, supports synthesis and simulation
- fuseSoC
-
python based wrapper around edalize, is a package manager
- Ruckus
-
a makefile based tool with similar goals to viv-prj-gen
- rules_vivado
-
a bazel based tool for managing verilog projects with vivado. Uses a socket to control vivado from the build tool, rather than a tcl script.
- ttask
-
tcl based, vendor agnostic, supports building bits files and simulation
- HOG
-
tcl and bash based, supports synthesis
- IPbus builder
-
I don’t understand this enough to summarize
If Edalize or hdlmake support your needs, they interface with more tools and work better with simulation frameworks like VUnit. I strongly recommend you check them out.
I think the main benefits of viv-prj-gen are that it is simple, cmake based (has benefits and drawbacks, python based is better for simulation), supports vivado block diagrams for zynq projects, and is easy to extend. The main downsides are that its not python based, only supports vivado (writing cmake functions to support other vendors would not be difficult, though), doesn’t have organization backing (might not be as well maintained), and isn’t as widely used as these other projects.
Let’s say you’ve got a directory tree that looks like this:
.
├── build
├── CMakeLists.txt
├── hdl
│ ├── DFlipFlop.v
│ └── ShiftReg.v
├── tb
│ ├── tb_DFlipFlop.sv
│ └── tb_ShiftReg.sv
├── constraints
│ ├── system.xdc
└── viv-prj-genwhere viv-prj-gen could be retrieved using git clone https://github.com/TripRichert/viv-prj-gen
you could set up a vivado project to develop in like this.
cmake_minimum_required(VERSION 3.3)
project(prjgen)
set(CMAKE_DISABLE_SOURCE_CHANGES ON)
set(CMAKE_DISABLE_IN_SOURCE_BUILD ON)
include(viv-prj-gen/vivgen_functions.cmake)
file(GLOB hdlfiles hdl/*.v)
file(GLOB tbfiles tb/*.sv)
file(GLOB xdcfiles constraints/*.xdc)
set(mypartname "XC7Z020-1CLG484")
#specify project to develop in
add_vivado_devel_project(
PRJNAME test
PARTNAME ${mypartname}
VERILOGSYNTHFILES ${hdlfiles}
SVSIMFILES ${tbfiles} ${hdlfiles}
UNSCOPEDLATEXDC ${xdcfiles}
)If you want to build a bit file, you can set up a nonproject mode build recipe like this.
cmake_minimum_required(VERSION 3.3)
project(prjgen)
set(CMAKE_DISABLE_SOURCE_CHANGES ON)
set(CMAKE_DISABLE_IN_SOURCE_BUILD ON)
include(viv-prj-gen/vivgen_functions.cmake)
file(GLOB hdlfiles hdl/*.v)
file(GLOB tbfiles tb/*.sv)
file(GLOB xdcfiles constraints/*.xdc)
set(mypartname "XC7Z020-1CLG484")
#use nonproject mode to specify recipe for bit file
add_vivado_nonprj_bitfile(
PRJNAME test
TOPNAME ShiftReg
PARTNAME ${partname}
VHDLFILES ${hdlfiles}
UNSCOPEDLATEXDC ${xdcfiles}
BITFILE_OUTPUT test_bitfile
)
# create target that depends on output bitfile
add_custom_target(testnonprj_target
DEPENDS ${test_bitfile}
)If you need to customize the build process, there are hooks for that, too.
If you are interested in seeing more of the capabilities, go through the tutorial:
