Introduction/Problem statement

One of the things I have been struggling with at work is getting version control to work well with my FPGA projects. My custom solution has been to include all user files (.vhd, .v, .sv etc.) to exist in the git project and to .gitignore everything else. While this has allowed me to version control the source code, my configurations for each FPGA has to be changed every time I clone the project. This leads to several issues:

  1. Repetitive work/Loss of productivity: I end up spending a lot of time linking my project files with the project, choosing the device configuration, setting the top module and then setting up the synthesis and place and route tools with the correct configuration.

  2. Incorrect configuration: While collaborating with larger teams, the configuration often gets messed up when each of us clones the repository and builds the project separately. There is no way to communicate the chosen options with the team members and a lot of time effort ends up being spent debugging what was essentially a config issue.

  3. Lack of reproducibility: The biggest cause of concern is the lack of reproducibility of the final binary. Since there are no configurations to go off of, we end up having a lot of versions each with a slightly different config change that our build becomes ir-reproducible.

  4. Path issues: The only alternative would be sending the entire project to your team member but that comes with the caveat that the paths for all content would be incorrect and requires correction (especially when you work on Linux).

How does hog fit in?

Hog (Docs) or HDL on Git is a project by CERN where build scripts (tcl), config files describing the structure of the project and the actual source code are all versioned using git. This allows us to keep builds reproducible and tagged with the git hash/version.

Another advantage is that it plays well with CI/CD pipelines, requiring the runner to have just the build tool, git and bash, nothing else. Developing using CI/CD pipelines would also solve the issue with incorrect artifacts from different runs, lack of traceability across runs and differently configured environments on each user machine.

They also support configuring files into libraries (using configs) making multi-library projects easy to build. To change from one vendor to another, we need to change the config file (can recursively call configs, allowing common files to be called together).

There is also versioning of FPGAs i.e., the build script can be suffixed with .1, .2 etc to indicate they are for the same build type but with different targets (something like that)?

We can port non-hog projects to hog through a single command (plus some finagling). This would simplify the hassle of shifting build systems.

My questions and their responses

  1. Q. Does hog also check if config changes have been made in the GUI (say the fanout limits, or vhdl standard for the project etc.) How do we ensure that the reproducibility is maintained then? A. Yes, this is checked every time you launch the synthesis (expect for Quartus and ISE, where they still need to implement this feature).

  2. Q. Is there a recommended way of deploying the IDE for CI? (I know I am asking a lot here, but have you created Dockerfile for common tools)? A. CERN has ci4fpga project for internal use. Can send the hog team an email to get in contact with the CERN guy preparing the Dockerfile.

  3. Q: How can the register with version be read when physical hardware is fused? Are there any primitives preventing it from being pruned during synth/pnr? A: The top file should take the generics as input and the data from those generics should be added to the internal register bus.

  4. Q: Has anyone here used Libero IDE v9.2? I saw there is support for 10 and above. A: As long as there is no big change between versions in terms of commands issues, it should be fine. Need to test on our side.