arXiv:2605.17290v1 [cs.SE] 17 May 2026
Debug Like a Human: Scaling LLM-based Fault Localization to Processor Design via Block-Level Instruction-Oriented Slicing Zizhen Liu
Xiaoguang Mao∗
Deheng Yang∗
National University of Defense Technology Changsha, Hunan, China [email protected]
National University of Defense Technology Changsha, China [email protected]
Academy of Military Sciences Beijing, China [email protected]
Jiayu He
Yihao Qin
Guangda Zhang
National University of Defense Technology Changsha, China [email protected]
National University of Defense Technology Changsha, China [email protected]
Academy of Military Sciences Beijing, China [email protected]
Yan Lei
Jianjun Xu
Jiang Wu
Chongqing University Chongqing, China [email protected]
National University of Defense Technology Changsha, China [email protected]
Academy of Military Sciences Beijing, China [email protected]
Abstract Fault localization in modern processor design code is a critical yet time-consuming step during processor verification. While recent advances in LLM-based techniques for module-level hardware design have shown promising results, automatically localizing bugs in large-scale, project-level processor designs remains challenging. In this paper, we present BluesFL, a novel block-level LLM-based fault localization framework for processor designs. Inspired by the way engineers debug processors, we first propose a dataflow-based code blockization approach to guide LLMs to focus on critical local code context. We further propose a Block-level Instruction-Oriented Slicing (Blues) algorithm that enables LLMs to mimic human reasoning by analyzing instruction execution paths and processor states. We evaluate BluesFL on a real-world RISC-V processor core comprising 19K lines of SystemVerilog code. Experimental results demonstrate that BluesFL correctly localizes 24 bugs at Top-1, achieving 242.9% improvement over the existing state-of-the-art (7 bugs). Cost analysis shows that BluesFL requires an average of only $0.257 to localize a single bug.
CCS Concepts • Hardware → Functional verification; Methodologies for EDA; • Computing methodologies → Artificial intelligence.
Keywords Fault Localization, Processor Verification, Large Language Model ∗ Co-corresponding authors: Xiaoguang Mao and Deheng Yang.
This work is licensed under a Creative Commons Attribution 4.0 International License. DAC ’26, Long Beach, CA, USA © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2254-7/2026/07 https://doi.org/10.1145/3770743.3804145
ACM Reference Format: Zizhen Liu, Xiaoguang Mao∗ , Deheng Yang∗ , Jiayu He, Yihao Qin, Guangda Zhang, Yan Lei, Jianjun Xu, and Jiang Wu. 2026. Debug Like a Human: Scaling LLM-based Fault Localization to Processor Design via Block-Level Instruction-Oriented Slicing. In 63rd ACM/IEEE Design Automation Conference (DAC ’26), July 26–29, 2026, Long Beach, CA, USA. ACM, New York, NY, USA, 7 pages. https://doi.org/10.1145/3770743.3804145
1
Introduction
Modern processors contain millions of lines of hardware description language (HDL) code to enhance performance and extend functionality. However, this increasing complexity also makes them highly susceptible to design bugs, which can result in severe functional errors [8], degraded performance [9], or even critical security vulnerabilities [15, 16]. Localizing bugs in processor source code is essential for developers to fix them. However, this debugging process remains one of the most time-consuming stages of processor development. According to recent surveys, verification-related tasks account for approximately 60% of the total hardware development effort [10]. Therefore, automatically locating bugs in HDL source code (e.g., Verilog) for large-scale processor designs is crucial for achieving agile development, as inefficient debugging directly impacts design productivity and undermines market competitiveness. Various techniques have been proposed to help verification engineers automatically detect processor bugs [11, 12, 19, 22, 28]. However, most methods primarily focus on detecting, leaving the task of locating them within the source code to developers [18]. Once a bug is detected, engineers typically examine suspicious signals, and manually review the Verilog code to identify the buggy lines. This manual debugging process is both time-consuming and inefficient. To alleviate this burden, numerous fault localization (FL) techniques for hardware designs have been proposed. More recently, large language model (LLM)-based methods [27] directly predict buggy lines from Verilog modules, demonstrating significant
DAC ’26, July 26–29, 2026, Long Beach, CA, USA
Zizhen Liu, Xiaoguang Mao∗ , Deheng Yang∗ , Jiayu He, Yihao Qin, Guangda Zhang, Yan Lei, Jianjun Xu and Jiang Wu
promise. While existing techniques have proven effective at general or module-level hardware designs, FL for real-world, project-level processor design code is still at an early stage currently and has the following limitations: Limitation 1: To the best of our knowledge, no specific FL technique for processor functional bugs has been studied yet. Processors, as instruction-driven hardware, are inherently more complex and distinctive than general hardware modules (e.g., memory controller, ALU). Consequently, FL techniques designed for general hardware may be less effective for processors, as assumptions valid for small-scale hardware may not hold in the processor domain. For example, slicing-based approaches [7, 26] perform dataflow analysis to produce a set of suspicious lines. While this set is small enough for most hardware modules to review manually, it becomes considerably larger in large-scale processor designs, making manual review impractical. Hence, dedicated techniques are required to achieve effective bug localization in processor designs. Limitation 2: Existing hardware FL techniques lack effective utilization of instruction execution coverage. Modern processors use pipelining to execute multiple instructions simultaneously, causing instruction execution to span both spatial and temporal dimensions. The execution of an instruction from the fetch to the commit stage occurs across multiple modules in space and multiple cycles in time. Existing spectrum-based hardware FL techniques [24] typically rely on coarse-grained, range-based coverage collection over simulation intervals. As a result, coverage data for an instruction may be polluted by other in-flight instructions, reducing localization accuracy. Therefore, accurately capturing the execution path of each instruction is crucial. Limitation 3: Existing hardware FL techniques rarely leverage concrete signal values to aid localization. Signal values are essential for human developers to understand hardware behavior [18]. However, current hardware FL techniques seldom utilize this information because doing so requires advanced semantic comprehension. Recent advances in LLMs make it feasible to interpret signal values for reasoning about instruction behavior. Nevertheless, prompting LLMs with processor waveforms remains challenging. Processor simulations generate thousands of signals across thousands of cycles, producing extremely large waveforms. Identifying which signals at which cycles should be provided to LLMs to aid localization remains a nontrivial problem. Limitation 4: LLMs struggle to localize bugs in excessive code context. Modern processor projects typically consist of numerous module files whose combined size exceeds the context window limits of LLMs. When prompted with overly large code contexts, LLMs often lose focus and overlook critical information [17]. Unlike module-level hardware designs, where the entire design can be inspected by the model, processor-scale code introduces substantial noise that hinders the model’s ability to identify subtle bugs. Therefore, providing LLMs with critical and compact code context is essential for enabling accurate fault localization in large-scale processor designs. To address the above limitations, we derive two key insights from developer debug experience: (1) developers primarily focus on local code regions with dataflow relationships, and (2) they trace instruction execution paths for understanding processor behavior. Motivated by these observations, we first propose a dataflow-based
code blockization method that preserves local semantics while maintaining compact code size (Limitation 4). Building upon this foundation, we introduce BluesFL, a LLM-based block-level fault localization framework for large-scale processor designs (Limitation 1). BluesFL mimics human debugging behavior by reviewing instruction execution paths and assigning suspiciousness scores to buggy code blocks. Specifically, a novel Block-Level InstructionOriented Slicing (Blues) algorithm is proposed to guide LLMs to focus on instruction-executed blocks (Limitation 2) and enhance their understanding of instruction behavior by incorporating the values of signals through time-annotated blocks (Limitation 3). In summary, this paper makes the following contributions: • We propose BluesFL, a block-level LLM-based fault localization framework for processor designs. To the best of our knowledge, this is the first approach that applies LLM-based fault localization to real-world processors. • We introduce a dataflow-based code blockization method that preserves local semantics while producing compact blocks for efficient LLM analysis. • We propose a Block-Level Instruction-Oriented Slicing algorithm that helps LLMs understand instruction dynamic behavior. • We evaluate BluesFL on a 19KLoC open-source RISC-V core, where it correctly localizes 24 bugs at Top-1. All source code and results are available at: https://github.com/pointerliu/bluesfl.
2 Background 2.1 Co-simulation-based Processor Verification In co-simulation–based verification, both the HDL-written processor and a software reference model execute the same instructions, and their architectural states are compared to ensure correctness [13]. The two models run in parallel, and their states are checked at each instruction commit stage. Multiple open-source processor cores have adopted this verification framework [2–4]. Accordingly, we build BluesFL on top of this co-simulation–based framework to enable precise fault localization by leveraging fine-grained instruction-level information. After co-simulation, an architectural state mismatch of a signal 𝑠𝑖𝑔 is detected at instruction 𝐼 and time 𝑡, with the expected behavior denoted as 𝐸 in natural language. The final test report for this failing instruction is represented as (𝐼, 𝑠𝑖𝑔, 𝑡, 𝐸). An example is shown in Figure 6.
2.2
Fault Localization for Hardware Designs
Fault localization (FL), which automatically identifies suspicious statements in source code, has been extensively studied in software systems [23]. However, due to the fundamental differences between HDLs (e.g., Verilog) and software languages (e.g., Java), software-oriented FL techniques cannot be directly applied [24]. Consequently, HDL-specific approaches have been developed. Static slicing–based methods [7] identify suspicious signals and then perform dataflow analysis to include all statements related to these signals. However, they often produce excessively large suspicious sets, making manual inspection difficult. Signal transition–based methods [26] use clock timing to exclude uncovered statements, reducing the set size; however, they analyze only the cycle of the failure, limiting effectiveness in multi-cycle instruction executions. Spectrum-based methods [24] collect HDL coverage information from both passing and failing test cases and compute
Debug Like a Human: Scaling LLM-based Fault Localization to Processor Design via Block-Level Instruction-Oriented Slicing
a suspiciousness score for each statement. However, this approach heavily relies on the number of failing tests to distinguish coverage between passing and failing tests. Recently, large language model (LLM)-based methods [27] have been proposed to predict buggy lines in Verilog modules. These static approaches ignore dynamic processor states, which may result in limited accuracy when applied to large-scale processor designs. Furthermore, due to the limited input context of LLMs, providing the entire project code at once is infeasible, making their application in real-world processor projects challenging.
3 Methodology 3.1 Overview BluesFL is a block-level fault-localization approach for processor designs that aims to locate buggy code blocks. As shown in Figure 1, after co-simulation, a test report for the failing instruction is generated. ❶ BluesFL first partitions the processor codebase into a set of disjoint code blocks using dataflow-based code blockization. ❷ Next, we apply a Block-Level Instruction-Oriented Slicing (Blues) algorithm to construct the instruction execution path, which chains blocks covered during instruction execution with time annotations. In this path, each node contains a code block and a timestamp indicating when the block is covered. ❸ BluesFL performs debugging in a human-like manner via tool calls: at each state (𝑏, 𝑡), the LLM analyzes the current code block context to identify suspicious signals, then queries the code blocks driving these signals in the instruction execution graph. The LLM can also leverage the time annotation to read local signal values from the waveform, aiding reasoning. If a block is considered suspicious, it is appended to a suspicious block queue. ❹ This loop runs for multiple rounds until the LLM requests to exit the analysis. BluesFL then ranks all suspicious blocks by score, producing the final localization results. Co-simulation Test Report
Waveform CLK
Signal Values
❸ LLM Reasoning read values
append block
check signals
exit
❹ Ranking Suspicious Blocks
❶ Code Blockization
Repository
Unordered Code Blocks
❷ Blues T=15
T=16
T=17
Instruction Execution Path
signals
Block Ranking
Block Time
Tool Call
Current State
Block ID 1361 528 …
Score 1.0 0.5 …
Localization Results
DAC ’26, July 26–29, 2026, Long Beach, CA, USA
ModOutputBlock, AssignBlock, and AlwaysBlock. For each block, we define an input signal set 𝑉𝑖 and an output signal set 𝑉𝑜 as follows: • ModInputBlock: 𝑉𝑜 contains only this input port signal, while 𝑉𝑖 consists of the signals connected to this input port in a module instantiation. • ModOutputBlock: 𝑉𝑜 consists of the signals connected to this output port in a module instantiation, while 𝑉𝑖 contains only this output port signal. • AlwaysBlock: 𝑉𝑜 includes all signals appearing on the left-hand side of assignments within this always block, and 𝑉𝑖 includes all signals appearing on the right-hand side of assignments and in conditions within the block. • AssignBlock: We first create AssignBlock for each assign statement. 𝑉𝑖 is all right-hand signals in this assign statement and 𝑉𝑜 is all left-hand signals. If 𝑉𝑜 of one AssignBlock block shares a dataflow dependency with 𝑉𝑖 of another AssignBlock block, we merge them by combining their respective 𝑉𝑖 and 𝑉𝑜 . Algorithm 1: Block-Level Instruction-Oriented Slicing Input: Code block set B, initial signal 𝑠𝑖𝑔, time 𝑡 Output: Instruction execution path 𝐺 1 Initialize a queue 𝑆 with (𝑠𝑖𝑔, 𝑡); 2 while 𝑆 is not empty do 3 (𝑠, 𝑡𝑐𝑢𝑟 ) ← Pop(𝑆); 4 if 𝑡𝑐𝑢𝑟 < 0 then 5 continue 6 𝑏 ← FindDrivenBlock(𝑠 ) ; 7 (𝑑𝑟𝑖𝑣𝑒𝑛_𝑠𝑖𝑔𝑛𝑎𝑙𝑠, 𝑡 ′ ) ← IntraBlockAnalysis(𝑠, 𝑏, 𝑡𝑐𝑢𝑟 ); 8 foreach 𝑠𝑖 ∈ 𝑑𝑟𝑖𝑣𝑒𝑛_𝑠𝑖𝑔𝑛𝑎𝑙𝑠 do 9 𝑏 ′ ← FindDrivenBlock(𝑠𝑖 ) ; 10 Add node (𝑏 ′, 𝑡 ′ ) and edge (𝑏 ′, 𝑡 ′ ) → (𝑏, 𝑡𝑐𝑢𝑟 ) to 𝐺; 11 Push (𝑠𝑖 , 𝑡 ′ ) to 𝑆 ; 12 return 𝐺; 13 Function IntraBlockAnalysis(𝑠, 𝑏, 𝑡): 14 𝐼𝑠 ← DataflowAnalysis(𝑠, 𝑏, 𝑡) ; // Get input signals driving 𝑠 15 if 𝑏 is COMB then 16 return (𝐼𝑠 , 𝑡) ; 17 else 18 if assignment to 𝑠 is covered at 𝑡 − 1 then 19 return (𝐼𝑠 , 𝑡 − 1) ; 20 else 21 return ({𝑠}, 𝑡 − 1) ;
Figure 1: Overview of BluesFL.
3.2
Dataflow-based Code Blockization
Definition 1 (Code Block). Let 𝐿 = {𝑙 1, 𝑙 2, . . . , 𝑙𝑚 } denote the set of all code lines in the HDL source code. A code block 𝑏 is defined as a subset of lines 𝑏 ⊆ 𝐿 such that for any two distinct blocks 𝑏𝑖 , 𝑏 𝑗 , we have 𝑏𝑖 ∩ 𝑏 𝑗 = ∅. The set of all code blocks is denoted as 𝐵 = {𝑏 1, 𝑏 2, . . . , 𝑏𝑛 }. Based on Definition 1, we propose a dataflow-based blockization method that clusters together statements with dataflow relationships to preserve more complete local semantics. According to the types of statements in the synthesizable subset [21] of SystemVerilog, we categorize code blocks into four types: ModInputBlock,
3.3
Block-Level Instruction-Oriented Slicing
Even after clustering multiple lines into individual blocks, the number of resulting blocks remains large, making it impractical for LLMs to analyze them one by one. To exclude blocks that are not covered during failing instruction execution, we propose Block-Level Instruction-Oriented Slicing (Blues) algorithm. Blues constructs the instruction execution path as a graph, where each node represents a code block annotated with a timestamp1 . Blues consists of two complementary components: Intra-Block Analysis, which 1 Note that all time values in this paper are measured as the number of posedge clock
cycles since the start of simulation.
Zizhen Liu, Xiaoguang Mao∗ , Deheng Yang∗ , Jiayu He, Yihao Qin, Guangda Zhang, Yan Lei, Jianjun Xu and Jiang Wu
DAC ’26, July 26–29, 2026, Long Beach, CA, USA
analyzes the dataflow of suspicious signals within blocks, and InterBlock Analysis, which excludes code blocks that are not covered during instruction execution. Algorithm 1 summarizes the basic workflow of Blues. Starting from an initial suspicious signal 𝑠𝑖𝑔 and its timestamp 𝑡 obtained from the test report, Blues iteratively traces backward through the blocks that drive this signal. At each step, Intra-Block Analysis identifies the driven signals (i.e., the signals used to compute the suspicious signal) from the input set 𝑉𝑖 of the current block. InterBlock Analysis then finds the driven blocks, which are the blocks whose output sets 𝑉𝑜 contains these driven signals. This process annotates each block with its corresponding timestamp, forming a node (𝑏, 𝑡) and adding dependency edges between nodes in the instruction execution path 𝐺. The recursion continues until no further expansion of 𝐺 is possible. Each node (𝑏, 𝑡) in 𝐺 indicates that block 𝑏 is covered at time 𝑡. Note that the same block may appear in multiple nodes with different timestamps, reflecting repeated coverage during this instruction execution. As AssignBlock Aw AlwaysBlock T = t - 1 T=t always_ff @(posedge clk) begin if (we) begin pc_id_o <= pc_if_o; end end
As Covered
As Aw
Uncovered
we pc_if_o pc_id_o
Aw Aw
Figure 2: An example of Blues. 3.3.1 Intra-Block Analysis. For an output signal 𝑠 ∈ 𝑉𝑜 of block 𝑏 at time 𝑡, Intra-Block Analysis identifies the driven signals within 𝑉𝑖 that drive 𝑠 by performing dataflow dependency analysis (line 14). Each identified driven signal is annotated with a new timestamp 𝑡 ′ , indicating that the value of 𝑠 at time 𝑡 is propagated from the values of the driven signals at time 𝑡 ′ . The timestamp 𝑡 ′ is inferred based on the type of block. For combinational blocks (e.g., ModInputBlock, ModOutputBlock, AssignBlock, or an AlwaysBlock without a clock), assignments are always covered, so 𝑠 at time 𝑡 is driven by the values of the driven signals at the same time 𝑡 (line 15-16). For sequential blocks (e.g., an AlwaysBlock with a clock), if the assignment to 𝑠 is covered at time 𝑡 − 1, indicating that the value of 𝑠 at time 𝑡 is computed by the driven signals at time 𝑡 − 1, then these driven signals at time 𝑡 − 1 are collected for backward analysis (line 18-19). If the assignment is not covered at 𝑡 − 1, the register retains its previous value, so 𝑠 at time 𝑡 holds its own value at time 𝑡 − 1 (line 21). These driven signals and associated timestamps are provided to the LLM when it inspects signal 𝑠 in block 𝑏, ensuring that it focuses only on relevant signals and reducing interference from unrelated ones. 3.3.2 Inter-Block Analysis. After identifying the driven signals of 𝑠 in block 𝑏 at time 𝑡, Inter-Block Analysis determines which blocks actually compute the values of these signals (i.e., driven blocks) and inserts the corresponding predecessor nodes for (𝑏, 𝑡) in the instruction execution path 𝐺 (line 8-11). Specifically, for each driven signal annotated with timestamp 𝑡 ′ in block 𝑏 through Intra-Block Analysis, the block whose output signal set contains this driven signal is identified as a driven block 𝑏 ′ , forming the corresponding node (𝑏 ′, 𝑡 ′ ). Then, this node is inserted into the path 𝐺, adding an edge from (𝑏 ′, 𝑡 ′ ) to (𝑏, 𝑡). When the LLM identifies suspicious
signals (i.e., a subset of driven signals) in block 𝑏 and wants to check code blocks that compute these signals, it can request the instruction execution path 𝐺 to get block 𝑏 ′ . As shown in Figure 2, if the green line is covered at time 𝑡 − 1, driven signals of pc_id_o include both pc_if_o and we at 𝑡 − 1. Then, after Inter-Block Analysis, two AssignBlocks that drive these signals are connected to this AlwaysBlock. If this line is not covered, the register pc_id_o retains its value, meaning it is driven by itself from time 𝑡 − 1 through the same AlwaysBlock.
3.4
LLM Reasoning and Ranking
You are a debugging assistant for a RISCV microprocessor design team. Your task is to provide a step-by-step explanation of whether the current code snippet is the root cause of the fault. # Simulation fault information {test_report} # Code snippet {code_block_context} # Driven signals {driven_signals}
{
}
Signal Representation "name": "res", "time": 15, "width": 16, "value": "0x5fc0"
Tool Calls exit
append_block check_signals read_values
Figure 3: The prompt template of BluesFL. We prompt LLM reasoning and make decisions via tool calls at each state (𝑏, 𝑡). As shown in Figure 3, the LLM evaluates whether current code block context is the root cause of the bug. If this block is deemed suspicious, it calls the append_block tool to append 𝑏 to suspicious block queue. Driven signals obtained by Intra-Block Analysis of Blues are provided in the prompt as a JSON array, with each signal represented in the format shown in Figure 3. If LLM requires further inspection, it queries a set of suspicious signal names via the check_signals tool. All signals selected by the LLM must be chosen from the provided list to ensure the LLM focuses only on blocks within the execution path. Blues maps these signals to their driven blocks via the instruction execution path 𝐺, generating new states for the LLM to inspect. With timestamps annotated for each block, the LLM can retrieve critical signal values from the waveform using the read_values tool, aiding in instruction behavior comprehension. This loop executes for multiple rounds until the LLM confirms that the root cause is in the suspicious queue and calls the exit tool. It then assigns each suspicious block a confidence score between 0 and 1, producing a ranked list of suspicious blocks.
4 Experiment 4.1 Experiment Setup 4.1.1 Benchmark. We adopt a production-quality, open-source RISC-V core Ibex [3] to evaluate BluesFL. It was selected for its wide adoption in the open-source hardware community (1.7K GitHub stars) and its implementation in approximately 19 KLoC of SystemVerilog, providing a realistic scale for evaluating BluesFL’s performance on real-world processor projects. Following prior work [20, 27], we inject bugs into Ibex according to the same mutation rules. The CoreMark [1] test program is executed in a co-simulation framework to trigger the injected bugs. If verification fails, we record the buggy line and save the modified code. In total, 119 bugs are injected to construct our benchmark. 4.1.2 Baselines. We compare BluesFL with state-of-the-art FL techniques for HDLs, including Cirfix [7] (static slicing-based),
Debug Like a Human: Scaling LLM-based Fault Localization to Processor Design via Block-Level Instruction-Oriented Slicing
4.2
Experiment Results
Table 1: Comparison between BluesFL and other FL baselines on benchmark. Approach
Type
Top-1
Top-5
Top-10
Cirfix Strider Tarsel-Jaccard Tarsel-Ochiai Tarsel-Tarantula LiK Agentless
Project Project Project Project Project Module Project
0 0 0 0 3 7 13
0 0 0 0 4 7 16
0 0 0 2 7 7 16
BluesFL ❶ w/o Signal Values ❷ w/o Instruction Path
Project Project Project
24 13 5
28 24 6
28 26 6
4.2.1 RQ1. Effectiveness of BluesFL. Table 1 summarizes the overall effectiveness of BluesFL compared with existing FL baselines. BluesFL localizes 24, 28, and 28 bugs within the Top-1, Top-5, and Top-10 rankings, respectively, outperforming the best existing baseline, LiK, by up to 242.9% in Top-1 accuracy. Slicing-based approaches generate overly large suspicious sets, hindering accurate Top-10 localization. Among spectrum-based FL metrics, Tarantula performs best, but its overall accuracy remains limited. These methods rely on range-based coverage collection
over simulation intervals, causing coverage data for a failing instruction to be polluted by other in-flight instructions. For the LLM-based, hardware-specific FL approach LiK, only 7 bugs are localized, as the long module code in Ibex hinders precise locating buggy lines. Agentless provides entire module file to GPT-4o and also shows limited results compared to BluesFL due to excessively long code context. In contrast, BluesFL employs dataflow-based code blockization to retain compact yet relevant context. As shown in Figure 4, 99% of code blocks parsed by our approach for Ibex contain no more than 200 lines, except for a few special modules such as the instruction decoder. Moreover, Blues guides LLMs to reason only over blocks covered during instruction execution and leverage signal values to comprehensively understand instruction behavior, resulting in the best performance among baselines. 99th percentile
#
102 101 100
400 500 Block Size300 Figure 4: Histogram of Block Sizes in Ibex (Log Y Scale).
# of Checked Blocks
Strider [26] (transition-based), Tarsel [24] (spectrum-based), and LiK [27] (LLM-based). LiK requires both the module code and its specification; therefore, we use GPT-4 to summarize Ibex modules into concise specifications following the LiK dataset construction methodology. As LiK localizes bugs only within a single module, we manually provide the buggy module file for projectlevel evaluations. While this gives LiK additional prior knowledge over BluesFL, it ensures an available comparison. We also implement a LLM-based software-oriented FL approach, Agentless [25], adapted for processors. Following its repositoryoriented workflow, Agentless first uses an LLM to identify potentially buggy module files from the test report and project structure, then provides each suspicious file’s full source code to the LLM to predict bug locations. 4.1.3 Implementation Details. The BluesFL prototype utilizes the sv-parser[5] library to parse the abstract syntax tree (AST) of SystemVerilog files. We employ Verilator[6] to perform simulations and generate waveforms for collecting signal values and code coverage information. BluesFL is implemented in approximately 12 KLoC of Rust, which includes the Blues algorithm and LLM-based reasoning components. BluesFL uses GPT-4o model as default. 4.1.4 Evaluation Metrics. Following prior studies in the FL field [14, 24], we evaluate BluesFL using the Top-𝑁 metric, which counts the number of bugs for which at least one buggy block appears within the top 𝑁 positions of the ranked list. Slicing-based approaches output only sets of statements without suspiciousness scores. Following [24], we assign each statement an expected rank of |𝑆 |/2, where |𝑆 | is the set size. LiK outputs a single buggy line, so its Top-𝑁 results remain constant across 𝑁 . For fair comparison, all baseline results are aligned to the block level.
DAC ’26, July 26–29, 2026, Long Beach, CA, USA
0
175 150 125 100 75 50 25 0
100
=15.4
200
BluesFL w/o instruction path w/o signal values Mean Median =27.3
=88.3
Figure 5: Distribution of the number of checked blocks across different settings. 4.2.2 RQ2. Effectiveness of Blues. Blues guides LLMs to exclude irrelevant code blocks by following the instruction execution path and helps them understand processor behavior through signal values. We conduct an ablation experiment to evaluate the contribution of signal values and execution paths in localizing bugs. In setting ❶, we remove read_values from tools given to BluesFL, preventing the LLM from accessing waveform. In setting ❷, we remove the instruction execution path obtained by Blues, allowing the LLM to freely access any code blocks. As shown in Table 1, both ❶ and ❷ show a performance drop compared with BluesFL, indicating that both signal values and instruction execution paths are necessary for effective processor debugging. Specifically, without the instruction execution path, LLMs often access blocks not covered during instruction execution, focusing on irrelevant blocks and producing false positives. Interestingly, we observe that without signal values, LLMs tend to access more code blocks. As shown in Fig. 5, the average number of blocks checked by BluesFL increases to 88.3, compared to 15.4 for BluesFL, resulting in a 609% increase in cost per bug ($0.257 → $1.821). This indicates that, without signal values, LLMs require more code context to fully reason about the bug. 4.2.3 RQ3: Performance on Other LLMs. We evaluate BluesFL across three LLM backends: GPT-4o-mini, GPT-4o, and Claude-3.5Sonnet. GPT-4o-mini provides a low-cost option, whereas GPT-4o and Claude-3.5-Sonnet offer stronger code capabilities. As shown in
DAC ’26, July 26–29, 2026, Long Beach, CA, USA
Zizhen Liu, Xiaoguang Mao∗ , Deheng Yang∗ , Jiayu He, Yihao Qin, Guangda Zhang, Yan Lei, Jianjun Xu and Jiang Wu
Table 2, BluesFL performs competitively even with the inexpensive GPT-4o-mini, and achieves higher performance with Claude-3.5Sonnet at increased cost. Table 2: Performance of BluesFL on Different LLMs. Base Model GPT-4o-mini GPT-4o Claude-3.5-Sonnet
Top-1
Top-5
Top-10
Avg Cost
17 24 30
25 28 33
26 28 33
$0.015 $0.257 $0.263
Test Report Suspicious Signal: rvfi_pc_wdata Failed Time: 19 Expected: Instruction jmp pc + 0xa0c0 incorrectly jumps to address 0x000F5FC0, whereas it should jump to 0x0010A140. Ibex 19KLoC
Code Blockization
fifo
prefetch
As
Out
5.2
Limitation of BluesFL
Evaluation of existing FL techniques on real-world processor designs indicates that fault localization for processors is still at an early stage. We analyzed cases in which BluesFL failed to localize bugs within the Top-10 across different models. As shown in Figure 7, for approximately 70% of these bugs, buggy blocks were never checked by LLMs because the debugging process terminated too early. To further improve FL performance, future work could explore methods that encourage LLMs to inspect more code blocks within a project, enabling long-distance, cross-block reasoning and more comprehensive localization.
5.3
Threats to Validity
LLMs are trained on large-scale codebases from GitHub and may have been exposed to the correct processor design code used in our
As
Out
Out
357 Blocks In Path
LLM 22 Checked Blocks
if_stage
pc_if_o
if_id_pipe_reg_we
Out
As
Unchecked Blocks in the instruction execution path
5 Discussion 5.1 How BluesFL works To better understand BluesFL’s debugging behavior, we visualize how it localizes a bug in Ibex. We injected a bug in alu module. Test report showed that the instruction j jumped to 0x000f5fc0 instead of the expected 0x0010a140. Without prior knowledge of the processor, linking this symptom to the alu module is not obvious. As shown in Figure 6, BluesFL first applies code blockization to partition the Ibex project into 1,329 blocks. Then, after running Blues, the instruction execution path contains only 357 blocks. Despite this significant reduction, the result remains challenging for humans to review. With LLM integration, BluesFL inspected only 22 blocks to pinpoint the bug, as shown in Figure 6. Specifically, BluesFL begins its analysis from the Top module at time 19. For clarity, we visualize only the LLM’s behavior when inspecting an AlwaysBlock in the if_stage module. After IntraBlock Analysis of Blues, the LLM knows that pc_id_o@18 is driven by pc_if_o@17 and if_id_pipe_reg_we@17. Without additional information, either signal could be the source of the bug. However, after examining these driven signal values, the LLM notices that pc_if_o@17 matches the incorrect jump address. Consequently, it prioritizes checking pc_if_o@17, leaving the blocks that drive if_id_pipe_reg_we@17 unchecked. After inspecting all fetch related modules under Blues’s guidance and finding no bugs, the LLM returns to the Top module and continues into the executionstage modules, where it locates the bug in an AssignBlock within the alu module. By combining the test report with code context, the LLM pinpoints the buggy block and provides a natural-language explanation. Overall, BluesFL traces long-distance signal propagation across space and time, behaving like a human debugger as it gathers debugging information and reasons about the root cause.
1329 Blues Blocks
Aw
Top Out
Aw
Out
always_ff @(posedge clk) begin if (if_id_pipe_reg_we) begin // ... pc_id_o <= pc_if_o; end end
pc_if_o@17 = 0x000F5FC0 Read Waveform: pc_id_o@18 = 0x000F5FC0 rvfi_pc_wdata …The incorrect address 0x000F5FC0 appears to be generated by T=19 pc_if_o signal, so I need to dive into it first for further investigation .…
Aw As
In
In
As
As
alu As
Exit
Aw
As
In
Start
ex_stage Out
As
Aw
Out Explanation
Buggy Code Block
assign adder_result_ext_o = … This bug is caused by $unsigned(adder_in_a) - $unsigned(adder_in_b); using the wrong adder assign adder_result =adder_result_ext_o[32:1]; operator here; it should be the assign adder_result_o = adder_result; addition operator instead … Out : ModOutputBlock
In : ModInputBlock
As : AssignBlock
Aw : AlwaysBlock
Figure 6: A case to show how BluesFL works.
claude-3-5-sonnet gpt-4o gpt-4o-mini 0.0
27.7 23.5 21.8
6.7 14.3 6.7 0.2
In Top-10
65.5 62.2 71.4 0.4 Ratio (%) 0.6
Checked (Not in Top-10)
0.8
1.0
Unchecked
Figure 7: Ratio of Buggy Blocks Checked by BluesFL. evaluation, potentially causing data leakage. To mitigate this, we inject bugs to ensure that the LLM has not encountered these test cases before. And the poor performance of the default GPT-4o (i.e., the baseline Agentless) indicates that the model has not simply memorized the correct code, while the significant improvement of BluesFL over Agentless demonstrates the effectiveness of our approach.
6
Conclusion
We present a novel LLM-based fault-localization framework for processor designs. Inspired by human debugging, BluesFL analyzes instruction execution paths, inspects processor states, and identifies the most suspicious code blocks. Our dataflow-based blockization reduces code context, allowing LLMs to focus on local dataflow. We further introduce a block-level instruction-oriented slicing algorithm (Blues) that chains instruction-covered blocks with time annotations. Blues enables LLMs to efficiently trace instruction execution and read signal values from large waveforms to reason about instruction behavior. Experimental results on a real-world RISC-V processor core show that BluesFL localizes 24 bugs at Top1, achieving a 242.9% improvement over the best existing baseline.
Acknowledgments This work was supported by the National Natural Science Foundation of China (No.62474196, No.62402515, and No.62504255).
Debug Like a Human: Scaling LLM-based Fault Localization to Processor Design via Block-Level Instruction-Oriented Slicing
References [1] 2025. CoreMark. https://github.com/lowRISC/ibex/tree/master/examples/sw/ benchmarks/coremark. [2] 2025. cva6. https://github.com/openhwgroup/cva6. [3] 2025. Ibex. https://github.com/lowRISC/ibex. [4] 2025. Rocket Chip Generator. https://github.com/chipsalliance/rocket-chip. [5] 2025. sv-parser. https://github.com/dalance/sv-parser. [6] 2025. Verilator. https://github.com/verilator/verilator. [7] Hammad Ahmad, Yu Huang, and Westley Weimer. 2022. CirFix: Automatically repairing defects in hardware design code. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems. 990–1003. [8] Desire Athow. 2014. Pentium FDIV: The processor bug that shook the world. https://www.techradar.com/news/computing-components/processors/ pentium-fdiv-the-processor-bug-that-shook-the-world-1270773. [9] Erick Carvajal Barboza, Sara Jacob, Mahesh Ketkar, Michael Kishinevsky, Paul Gratz, and Jiang Hu. 2021. Automatic microprocessor performance bug detection. In 2021 IEEE International Symposium on High-Performance Computer Architecture (HPCA). IEEE, 545–556. 2024-siemens-eda-and-wilson-research-group-ic-asic[10] Harry Foster. 2024. functional-verification-trend-report. https://verificationacademy.com/topics/ planning-measurement-and-analysis/wrg-industry-data-and-trends/2024siemens-eda-and-wilson-research-group-ic-asic-functional-verificationtrend-report/. Last accessed: Feb 2025. [11] Xiaolong Guo, Raj Gautam Dutta, Yier Jin, Farimah Farahmandi, and Prabhat Mishra. 2015. Pre-silicon security verification and validation: A formal perspective. In Proceedings of the 52nd annual design automation conference. 1–6. [12] Jaewon Hur, Suhwan Song, Dongup Kwon, Eunjin Baek, Jangwoo Kim, and Byoungyoung Lee. 2021. Difuzzrtl: Differential fuzz testing to find cpu bugs. In 2021 IEEE Symposium on Security and Privacy (SP). IEEE, 1286–1303. [13] Nursultan Kabylkas, Tommy Thorn, Shreesha Srinath, Polychronis Xekalakis, and Jose Renau. 2021. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation. In MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture (Virtual Event, Greece) (MICRO ’21). Association for Computing Machinery, New York, NY, USA, 667–678. doi:10.1145/3466752.3480092 [14] Sungmin Kang, Gabin An, and Shin Yoo. 2024. A Quantitative and Qualitative Evaluation of LLM-Based Explainable Fault Localization. Proc. ACM Softw. Eng. 1, FSE, Article 64 (July 2024), 23 pages. doi:10.1145/3660771 [15] Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, et al. 2020. Spectre attacks: Exploiting speculative execution. Commun. ACM 63, 7 (2020), 93–101. [16] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, and Mike Hamburg. 2018. Meltdown. arXiv preprint arXiv:1801.01207 (2018). [17] Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. 2024. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics 12 (2024), 157–173. doi:10.1162/tacl_a_00638 [18] Jiacheng Ma, Gefei Zuo, Kevin Loughlin, Haoyang Zhang, Andrew Quinn, and Baris Kasikci. 2022. Debugging in the brave new world of reconfigurable hardware. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems. 946–962. [19] Samit Shahnawaz Miftah, Amisha Srivastava, Hyunmin Kim, Shiyi Wei, and Kanad Basu. 2025. SymbFuzz: Symbolic Execution Guided Hardware Fuzzing. In Proceedings of the 58th IEEE/ACM International Symposium on Microarchitecture®. 1477–1490. [20] Sangeetha Sudakrishnan, Janaki Madhavan, E James Whitehead Jr, and Jose Renau. 2008. Understanding bug fix patterns in verilog. In Proceedings of the 2008 international working conference on Mining software repositories. 39–42. [21] Stuart Sutherland and Don Mills. 2013. Synthesizing systemverilog busting the myth that systemverilog is only for verification. SNUG silicon valley 24 (2013). [22] Ilya Wagner, Valeria Bertacco, and Todd Austin. 2005. StressTest: an automatic approach to test generation via activity monitors. In Proceedings of the 42nd annual Design Automation Conference. 783–788. [23] W. Eric Wong, Ruizhi Gao, Yihao Li, Rui Abreu, and Franz Wotawa. 2016. A Survey on Software Fault Localization. IEEE Transactions on Software Engineering 42, 8 (2016), 707–740. doi:10.1109/TSE.2016.2521368 [24] Jiang Wu, Zhuo Zhang, Deheng Yang, Xiankai Meng, Jiayu He, Xiaoguang Mao, and Yan Lei. 2022. Fault Localization for Hardware Design Code with Time-Aware Program Spectrum. In 2022 IEEE 40th International Conference on Computer Design (ICCD). 537–544. doi:10.1109/ICCD56317.2022.00085 [25] Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2025. Demystifying LLM-Based Software Engineering Agents. Proc. ACM Softw. Eng. 2, FSE, Article FSE037 (June 2025), 24 pages. doi:10.1145/3715754
DAC ’26, July 26–29, 2026, Long Beach, CA, USA
[26] Deheng Yang, Jiayu He, Xiaoguang Mao, Tun Li, Yan Lei, Xin Yi, and Jiang Wu. 2023. STRIDER: Signal value transition-guided defect repair for HDL programming assignments. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 43, 5 (2023), 1594–1607. [27] Bingkun Yao, Ning Wang, Jie Zhou, Xi Wang, Hong Gao, Zhe Jiang, and Nan Guan. 2025. Location is Key: Leveraging LLM for Functional Bug Localization in Verilog Design. In 2025 62nd ACM/IEEE Design Automation Conference (DAC). 1–7. doi:10.1109/DAC63849.2025.11133280 [28] Yanhong Zhou, Tiancheng Wang, Huawei Li, Tao Lv, and Xiaowei Li. 2015. Functional test generation for hard-to-reach states using path constraint solving. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 35, 6 (2015), 999–1011.