Project 02 / Research in progress

Can a processor check
only the work most at risk?

I’m exploring selective fault checks on the SonicBOOMv3 RISC-V core. The idea is to repeat work that may be at risk, compare the results before commit, and recover if they don’t match.

Chipyard · SonicBOOM · RV64GC ● Full M0 regression: Not passing yet

Why check every instruction twice?

Temporal redundancy can catch transient faults by repeating work and comparing the results. Repeating every instruction can cost power and performance. VIGIL asks whether checking only vulnerable work can lower that cost while keeping detection and recovery reliable.

Proposed mechanism

The current design uses a four-class Architectural Vulnerability Factor (AVF) classifier, a single-issue shadow lane, and a comparison before commit. For recovery, it combines branch and fault checkpoints, with a minimum ROB extension and an eight-entry checkpoint ring.

Core research question: Can selective checking lower the cost of temporal redundancy without compromising error detection latency or architectural recovery?

What has been tested

The isolated JAL checker passed 7 of 7 tests, and the comparator passed 2 of 2. Those are unit tests. The full SonicBOOM integration still needs to pass its regression.

What still needs work

The full M0 regression hasn’t passed yet. One run hit an ELF/runtime mismatch, so the current result is inconclusive. I can’t make an end-to-end reliability claim until the baseline is stable.

Next steps

First I need to reproduce the pinned RV64GC baseline and get the regression passing. Then I can compare the guarded core with an unmodified one under controlled fault injections, and report coverage, timing, and area trade-offs.

← Back to all projects