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 widely used in many fields. Among study participants Status quo (at scale) Agile 2020 [2], only 9% still relied on traditional project management methods.

A central element of the agile method is continuous change. This can only work if the potential problems with the 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, documenting, or even release the release, can be part of what is known as the CI pipeline.

This method offers many advantages such as:

  • early identification of integration problems,
  • minimize the time required to identify and correct errors, and
  • simpler implementation of continuous deployment.

The costs of individual modifications are thus reduced and it is easier to adapt to changing technical conditions or requirements.

Unlike software development, however, CI is not yet a standard part of hardware development processes today. Despite many parallels with software development, so do the digital design of ASICs and FPGAs. There are several reasons for this: CI systems are generally focused on software development because the number of users is significantly higher in that space. At the same time, the reliance on EDA’s commercial software design processes complicates the introduction of IC systems. While in software development, a call to the compiler generally costs “only” computation time, hardware synthesis requires a license (expensive!). In the end, it might just be too expensive to do a full synthesis for every code change. When testing hardware designs, computational expense for simulations is another cost factor alongside licensing costs. The time it takes to work on a test suite can also be problematic here – after all, integration issues need to be identified as early as possible. Another common hurdle in hardware development is GUI-based workflows.

It is essential to coordinate the development process and the CI system in the development of the hardware: test times must be reasonable, tools must be controlled by scripts and workflows must be automatable. Resource management is also required for more in-depth testing with physical hardware (eg, FPGA-based), as the hardware can often only be used in one test at a time. Metrics generated to assess project progress, test coverage, or code quality should be prepared and viewed in an informative manner.

Using an IC system in digital design can certainly pay off. Complex processes can be automated and the integration of hardware and software can be tested on a regular basis. Real hardware can even be used for testing, including with testing scope that would not be achievable with manual testing. For example, individual modifications to the hardware of an SoC can be tested in an automated fashion with associated software on the prototype FPGA. This increases confidence in the quality of development. At the same time, the speed of project progress can be measured more accurately: metrics offer employees and project managers greater transparency and provide the data necessary for the continuation of the development process.

The references



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

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

Christian skubich

(All posts)

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


Comments are closed.