Continuous Integration For Digital Design

By Christian Skubich and Nico Peter

In 2001, the Manifesto for Agile Software Development [1] laid the foundation for many modern software development processes. Today, 20 years later, agile methods are in widespread use in numerous domains. Out of the participants in the study Status Quo (Scaled) Agile 2020 [2], only 9% still relied on classic project management methods.

One core element of the agile method is continuous change. This can only work if potential problems from changes are identified as early as possible. For this reason, Continuous Integration (CI) has become an essential tool in software development. This involves frequent integration of changes and testing with an automated process. Additional steps, such as generating metrics, documentation or even delivering the build, may be part of what is called the CI pipeline.

This method offers a number of advantages, such as:

• early identification of integration problems,
• minimizing the time required for identifying and correcting errors, and
• simpler implementation of continuous deployment.

The costs of individual changes are lowered in this way, and it is easier to adapt to changing technical conditions or requirements.

In contrast to software development, however, CI is not yet a standard part of hardware development processes today. Despite many parallels to software development, the same applies to the digital design of ASICs and FPGAs. There are many reasons for this: CI systems are generally focused on software development since the number of users is significantly higher in that space. At the same time, dependency on the design processes of commercial EDA software complicates the introduction of CI systems. While in software development, a compiler call generally “only” costs computing time, hardware synthesis requires an (expensive!) license. In the end, it might be simply too expensive to perform an entire synthesis for every code change. During testing of hardware designs, the computation expense for simulations is another cost factor alongside the licensing costs. The time required to work through a test suite can also be problematic here – after all, integration problems must be identified as early as possible. GUI-based workflows represent another obstacle that is still commonly encountered in hardware development.

It is essential to coordinate the development process and the CI system in hardware development: Test times must be kept within reason, tools must be controlled by scripts, and workflows must be automatable. Resource management is also required for more extensive tests with physical (e.g. FPGA-based) hardware since hardware can frequently only be used in one test run at a time. Generated metrics for evaluating the project progress, test coverage, or code quality must be prepared and informatively visualized.

Using a CI system in digital design can definitely pay off. Complex processes can be automated, and the integration of hardware and software can be regularly tested. Real hardware can even be used for testing – including with a test scope that would not be feasible with manual testing. For example, individual changes to the hardware of an SoC can be tested in an automated fashion with the associated software on the FPGA prototype. This increases trust in the quality of the development. At the same time, the speed of project progress can be measured more accurately: metrics offer employees and project managers greater transparency and supply the data required for the continued development process.

References

[1] https://agilemanifesto.org/iso/en/manifesto.html

[2] https://www.hs-koblenz.de/en/bpm-labor/status-quo-scaled-agile-2020

Christian Skubich is a member of the Group Smart Multi-Sensor Systems at Fraunhofer IIS EAS.

Nico Peter is a member of the Group Smart Multi-Sensor Systems at Fraunhofer IIS EAS.