Some thoughts on CI in FPGA and embedded development

Continuous Integration (CI) has become a major part of modern software development, and it is just as valuable for FPGA projects. A stable, working codebase is important for any FPGA project, and CI makes that possible by automatically building and testing every commit: whenever someone pushes new code to the shared repository, the pipeline compiles, runs tests, and checks for errors. And if a build fails, the team is alerted immediately, so the problem can be fixed before it grows more complicated.

A big reason why CI is so helpful is that it promotes small, frequent integrations. Rather than letting large batches of changes accumulate in separate branches, leading to “merge hell” at the end, you merge small updates on a regular basis. This is especially useful for FPGA design, where a single synthesis can be time-consuming and certain issues only become visible after simulation. Running these tasks automatically and often avoids those unwanted last-minute surprises.

We have developed HDLRegression to manage and automate HDL testbenches, and HDLRegression fits perfectly into a CI workflow because it can handle all relevant simulations and report pass/fail back to the pipeline. If something fails, it flags the build as broken, and this level of automation is important for consistently catching mistakes.

Another tool we have developed is the UVVM (Universal VHDL Verification Methodology), which fits perfectly into a CI environment. For a testbench to run effectively in CI, it must be self-checking, automatically verifying its results without any manual involvement. This means the automated system can immediately detect when a test case fails and alert the pipeline. It is easy to build self-checking testbenches that quickly catch design errors with UVVM, which improves the overall reliability of the CI process.

To get the most out of CI, I recommend using merge requests (or pull requests) for every change. A merge request packages your changes, triggers the pipeline, and includes a code review step before merging. This ensures your new commits are automatically built and tested, and any failures block the merge until resolved. Team members can also comment on the code, suggest improvements, and catch potential issues early. Once everyone is satisfied and the pipeline is green, the changes are safely merged into the main branch.

A practical approach to CI can be summarised by these 10 rules:

1. Always run tests locally before committing. Even simple checks can catch obvious errors, do not rely on the CI system to catch them.
2. Wait for pipeline results and pay attention. If your commit causes a failure, address it right away. Do not commit and disappear.
3. Fix or revert failures within ten minutes. A red build blocks the entire team. If you do not have a quick fix, revert the commit to restore a clean main branch.
4. If someone breaks the build, revert their commit. It may sound harsh, but leaving a broken main branch only delays the needed fix and slows everyone down.
5. Monitor your changes through the entire pipeline. In FPGA flows, a green result on a basic test does not always mean success; regression testing or synthesis steps might fail later.
6. Treat a broken build as a major issue. Until it is fixed, it is the top priority. Nobody should be merging new changes on top of a failed build.
7. Commit often, in small steps. Large, infrequent merges can hide all sorts of problems. Smaller commits are simpler to review and revert.
8. Keep feedback loops fast and parallelise tests if possible. Developers need feedback while the changes are still fresh.
9. Automate everything you can - automation prevents human error and saves time.
10. Take responsibility for failures. If your commit caused the break, own it, and do not wait for someone else to step in; fix or revert so the team can move on.

Following these principles keeps the codebase reliable and helps uncover issues before they turn into major problems. Merge requests combined with an automated CI pipeline ensure that every change undergoes proper review as well as thorough testing. This can lead to fewer integration problems for both FPGA and embedded projects, and by using a development methodology like this can build trust in your design, speed up the development process, and reduce the risk of unexpected setbacks.

#embedded #FPGA #ASIC #UVVM #HDLRegression #CI #methodology

Inventas