Reaching an interrupt and debug clash as a core wakes up
A coverage hole in a RISC-V core's controller. We proved one of its conditions can never happen and wrote a test that reaches the other one.
1The issue
Line 399 of the core's controller decides what to do when an interrupt arrives in the first instruction fetch after the core starts or wakes from sleep. Two conditions on that line were never covered: an interrupt while the core is in debug mode, and an interrupt while a debug request is waiting. Both had been waived in earlier versions, with no proof or test behind the waiver.
The points on the issue
2What we did
- 1Found why the debug mode case is impossible. The core only enters this fetch state after reset or after sleep, and it never sleeps while in debug mode.
- 2Proved this with an unbounded formal proof, which checks every reachable state, not only the ones a test happens to try.
- 3Used a formal search to find a path to the other condition: the core sleeps, an interrupt wakes it, and a debug request arrives in that first fetch cycle.
- 4Wrote a test that wakes the core with a timer interrupt and sends a debug request at a different delay each time, over 32 iterations. It hits the condition once, at cycle 13562, and never hits the debug mode case.
3Result
The debug mode case can be waived safely. The waiting debug request case can happen, so it stays in coverage and now has a test that reaches it.
The test shows the condition can be reached, not that the logic around it is covered, and the results apply only to the build without the floating point unit.
Have a coverage hole like this one?
Describe the problem in a few lines. An engineer replies, and we agree the scope together.
Discuss a verification problem