Lets tackle the bull by its horns! So what is a revision control? It is fundamentally a method to keep track of source file changes, such that one can revert to a certain point in the past, combine multiple source changes into a release, fork into a design with different features, aid conflict resolution and provide ease of backup at one place.
Should FPGA designs be revision controlled or not? This is a no brainer for me, for anybody who is serious about delivering quality FPGA designs in a timely manner must use some form of SW tool supported revision control. This is mainly because manual revision control is tedious, time consuming, error prone and requires much storage space.
The key objective of any such support tool has to be to reduce complexity and save time with a little overhead. Therefore, fundamentally, usage or application of such a tool cannot and must not be more difficult, intimidating and time consuming than dealing with the actual FPGA Design!
Now, let us look at how to go about it. For Vivado 2020.2 and greater, AMD has made Vivado project directory structure more revision control friendly. Pre 2020.2, engineers have to be a little bit more creative. The main principle is to revision control anything that is required to generate the same “product” (output i.e. bit file) consistently with given set of sources (input i.e. .v, .vhd, constraints, coefficients etc.).
In addition, Vivado offers multiple design flows and different modes to automate (script) the flow. For example, Vivado supports BD-IPI, RTL, SystemGen, Vitis etc. based design flows. Similarly, Vivado supports flow automation through TCL scripting in different modes such as batch mode, GUI mode, project mode and non-project mode.
The method of automation should remain flexible and should be selected depending on the state of the project. For example, at the beginning, at a prototyping state, at a proof-of-concept state, at a stabilised state or at a released state. This selection, in-turn, impacts the sources required for revision control. For example, in the BD based flow, either the BD & XPR project files or an exported BD & project in the form of TCL should be revision controlled.
Therefore, one way of revision control can not be a fit for all the different states of an FPGA project. For example, at the beginning, when a project is still developing, an engineer implements a non-project based TCL automation. This method of flow automation is amenable to revision control however you can imagine how tedious and time consuming it would be to view and debug the synthesised design in the Vivado GUI.
Then comes the question, which revision control software to use. There are many paid and free ones. Two of the most popular ones are SVN and Git. The main difference as I understood between the two is, SVN is centralized whereas GIT is decentralized. I used to prefer one over the other however each has its pros and cons. As long as the fundamental objective is met without much overhead, it does not really matter!
One of the scary part of revision control for engineers starting out is conflicts i.e. multiple engineers working on the same file and committing different aspects of the functionality. Although this is a common use case, I believe, there is no “silver bullet” when it comes to source file conflict resolution. The revision control system can automatically merge the changes for you. However, I recommend reviewing the conflicts and then merging manually. One can use a SW comparison tool either provided by the revision control system or a third party SW like WinMerge (Freeware) or BeyondCompare (Licensed).
