From Chaos to Order: Using Continuous Integration for Hardware Functional Verification

As system complexity grows and tool performance hits the performance wall, the focus shifts towards enhancing productivity using existing tools. This paper will demonstrate how to leverage the CI flow in hardware to boost productivity, making the process more adaptable and smoother.

Wilson Research¹ reports that 24% of time is spent on creating tests and running simulations, and 41% on debugging. Using continuous integration (CI) in functional verification ensures automation and tight integration between various functional verification tools, resulting in reduced time and effort. This paper will cover the process of building a strong integration and its positive effects on time and effort savings.

Continuous Integration

Framework

This section will cover the continuous integration framework which is designed to test code in an automated manner. With modern SoCs comprising multiple subsystems, the CI framework is implemented at both the subsystem and chip levels. This allows the code to be integrated into larger sub-systems and systems. The CI framework involves multiple loops, as depicted in figure 1, where each loop represents a bigger subsystem². The code passes through these loops until it becomes stable enough to be integrated into the main streamline of the chip/SoC.

^{Figure 1. Continuous integration framework loop.}

Unit testing is a software method used in the validation of the smallest parts of the software³. Unit testing offers various benefits, such as detecting bugs at an early stage, improving code quality, aiding in refactoring, accelerating development, and enhancing collaboration.

Next, after the unit testing process comes sub-system level testing, which involves integrating your units into a larger sub-system. To illustrate, if we consider a processor design, we can divide the system into multiple units such as the address unit (AU), execution unit (EU), bus unit (BU), and instruction unit (IU).

Suppose the designer is working on a decoder in the IU; we can perform unit testing on the decoder and then integrate it into the IU for sub-system testing. After that, we can integrate this with all the other units and perform system-level testing. If the processor is part of another system, we can extend the testing loop even further. By adopting this approach, we can automate testing more efficiently and obtain results faster and earlier in the design stage, thus saving ourselves from integration difficulties or what the designers call “integration hell.”