failure cause analysis

Failure Cause Analysis

Concept

Failure cause analysis is the systematic process of identifying the underlying root cause of a test failure so it can be properly handled and fixed. In software testing, it determines how subsequent bugs are treated; in hardware verification, it pinpoints the faulty instruction, library, or implementation responsible for a mismatch. Automating this analysis reduces the manual, time-consuming inspection of logs or simulator output that can otherwise consume a large share of total debugging effort.

First seen 6/10/2026

Last seen 6/10/2026

Evidence 2 chunks

Wiki v1

WIKI

Overview

Failure cause analysis is the activity of determining why a test case failed, and assigning that failure to a specific cause (a buggy instruction, a misused library, a missing check, an incorrect flag, etc.). It is a prerequisite for properly analyzing and fixing failures, because the subsequent handling depends on the identified cause. In practice, manually tracing a failure back to its root cause is tedious and can account for 30–40% of the time needed to fix a problem, which motivates automated prediction of failure causes [arxiv:2405.02922v1].

Importance

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

1 connections

FP-RVVTS ← implements 100% 2e

FP-RVVTS supports improved failure cause analysis through isolation techniques.

LINKED ENTITIES

1 links

FP-RVVTS IMPLEMENTS Extracted graph relationship

CITATIONS

9 sources

9 citations — click to expand

[1] Failure cause analysis determines how subsequent bugs are handled, and manual root cause determination can cost 30–40% of the time needed to fix a problem. Easy over Hard: A Simple Baseline for Test Failures Causes Prediction

[2] NCChecker performs failure cause prediction in three stages: log abstraction, lookup table construction, and failure cause prediction; it was evaluated on an industrial dataset of more than 10K test logs. Easy over Hard: A Simple Baseline for Test Failures Causes Prediction

[3] FP-RVVTS enhances the RVVTS framework with improved failure cause analysis to enable comprehensive floating-point verification across RISC-V simulators and FP libraries (F, D, Zfh) through a novel context-free grammar specification, strengthened automatic single-instruction isolation, and improved failure cause analysis. Late Breaking Results: Float Fight - Verifying Floating-Point Behavior in RISC-V Simulators

[4] FP-RVVTS achieves over 95% functional coverage on generated FP test sets and uses isolated instructions to narrow down the causes of failures. Late Breaking Results: Float Fight - Verifying Floating-Point Behavior in RISC-V Simulators

[5] For fmax.d isolated with RISC-V VP++ SF as DUT, the failure is attributed to incorrect use of the SF library in RISC-V VP++ (Spike SF agrees on the result). Late Breaking Results: Float Fight - Verifying Floating-Point Behavior in RISC-V Simulators

[6] For fcvt.wu.d, RISC-V VP++ FF correctly computes the NaN result as 2^32 − 1 but then incorrectly zero-extends the 32-bit value to 64 bits instead of sign-extending it, violating the RISC-V specification. Late Breaking Results: Float Fight - Verifying Floating-Point Behavior in RISC-V Simulators

[7] For fdiv.s, the mismatch is on the underflow exception flag: Spike sets it as intended whereas Spike FF does not, indicating a bug in Spike FF. Late Breaking Results: Float Fight - Verifying Floating-Point Behavior in RISC-V Simulators

[8] RISC-V VP++ executes FP load instructions when the FP extension is disabled, omitting the required FP-extension-enabled check, whereas Spike correctly raises an exception. Late Breaking Results: Float Fight - Verifying Floating-Point Behavior in RISC-V Simulators

[9] Negative testing is essential to the failure cause analysis: in most cases the number of failures is higher in negative tests compared to the corresponding positive tests. Late Breaking Results: Float Fight - Verifying Floating-Point Behavior in RISC-V Simulators