google / google/xls

Potential fault injection strategy for "SW DV" test suites

Open
#1,111 0 comments 0 reactions 0 assignees View on GitHub
testing verification
Dominant language
C++
Stars
1.9k
Forks
283
Avg merge
2d 10h
Merged PRs (30d)
135

Description

We were brainstorming angles on fault injection for "SW DV" (software-based design verification) test suites.

Imagine you have a device under test (DUT) that takes input stimulus stream (IS) and produces output stimulus stream (OS), and assume it terminates. In our case the DUT is something like XLS IR running through the IR interpreter.

Imagine we have a fault injection function FI, where we can apply it to the DUT to produce a modified DUT: FI(DUT) -> DUT'

Given DUT', see if there is an IS in the existing corpus that surfaces the fault (by miscomparing to the original OS). If so, it's already covered, and DUT' is not interesting. But if it is not covered, do generative or mutation-based search in the direction of surfacing the known injection into DUT'. Any IS that's found to surface the injection should be (perhaps minimized and) added to the IS corpus.

Notably the random fault injection could be transient or stuck-at. We may be able to solve in concolic style whether the injection is visible in the output at all, or whether there is a particular counterexample in the IS space that can surface it.

For any generative testbench, if we can prove DUT' has a fault that can observably flow to output but the testbench does not surface it, it can serve as a metric that reflects the quality of the testbench.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.