Qihe: A General-Purpose Static Analysis Framework for Verilog

TL;DR

Qihe introduces the first general-purpose static analysis framework for Verilog, addressing hardware-specific challenges by combining 22 fundamental analyses, an analysis-oriented IR/front end, and an analysis manager. It supports a wide range of client analyses across bug detection, security, and program understanding, validated on real-world hardware projects where it discovers previously unknown bugs and vulnerabilities. The framework enables rapid development of new analyses with large reductions in implementation effort and dramatic improvements in analysis time through hardware-tailored optimizations and bit-level reasoning. Open-sourcing Qihe (over 100K lines of Java) aims to spur a vibrant hardware static-analysis ecosystem, providing a reusable foundation for more sophisticated hardware analysis and cross-domain collaboration.

Abstract

In the past decades, static analysis has thrived in software, facilitating applications in bug detection, security, and program understanding. These advanced analyses are largely underpinned by general-purpose static analysis frameworks, which offer essential infrastructure to streamline their development. Conversely, hardware lacks such a framework, which overshadows the promising opportunities for sophisticated static analysis in hardware, hindering achievements akin to those witnessed in software. We thus introduce Qihe, the first general-purpose static analysis framework for Verilog -- a highly challenging endeavor given the absence of precedents in hardware. Qihe features an analysis-oriented front end, a Verilog-specific IR, and a suite of diverse fundamental analyses that capture essential hardware-specific characteristics -- such as bit-vector arithmetic, register synchronization, and digital component concurrency -- and enable the examination of intricate hardware data and control flows. These fundamental analyses are designed to support a wide array of hardware analysis clients. To validate Qihe's utility, we further developed a set of clients spanning bug detection, security, and program understanding. Our preliminary experimental results are highly promising; for example, Qihe uncovered 9 previously unknown bugs in popular real-world hardware projects (averaging 1.5K+ GitHub stars), all of which were confirmed by developers; moreover, Qihe successfully identified 18 bugs beyond the capabilities of existing static analyses for Verilog bug detection (i.e., linters), and detected 16 vulnerabilities in real-world hardware programs. By open-sourcing Qihe, which comprises over 100K lines of code, we aim to inspire further innovation and applications of sophisticated static analysis for hardware, aspiring to foster a similarly vibrant ecosystem that software analysis enjoys.

Figures (13)

• Figure 1: Workflow of Qihe. It supports both analysis users in executing analyses on Verilog designs and developers in creating new analyses, enabled by the collaboration of its components.
• Figure 2: Analyses and their dependencies in Qihe. Each analysis is represented by its short name. The left section presents fundamental analyses, categorized into five groups, while the right section illustrates application-specific analyses across four domains. Arrows depict dependency relations between these analyses. To maintain clarity, we use short arrows ("", "", and "") to succinctly represent the number of dependencies that an application-specific analysis has on fundamental analyses. These arrows denote dependencies on one, two, or three fundamental analyses within a specific category, with the category identified by the arrow's color (or position in black-white printing). For example, the starred analysis missing-reset has two short arrows "": one top-right and one bottom-right, signifying its dependency on one analysis from the control category and one from the data category. We use the central bar to visualize the relative usage of each category by color and length.
• Figure 3: A properly-reset register example.
• Figure 4: Missing-reset examples and their hardware dependency graphs.
• Figure 5: All analyses that support the missing-reset analysis.