Reproducing a decoder bug that rejected zext.h as illegal
A closed bug report on a RISC-V core: the zext.h instruction was rejected as illegal with the B extension on. We reproduced it and proved the maintainers' fix holds.
1The issue
The B extension adds bit manipulation instructions to a RISC-V core. With it turned on, the core should accept zext.h, one of those instructions. The report said the core classified zext.h as illegal instead. So a program that used it would take an illegal instruction exception, a trap, rather than run the instruction. The cause was in the instruction decoder, the part that works out what each instruction is.
The points on the issue
2What we did
- 1Wrote a rule: with the B extension on, zext.h must finish without an illegal instruction exception.
- 2Built both versions of the design with the B extension turned on, and ran the rule with formal verification, which checks every reachable state. The version before the fix fails.
- 3Ran the rule on the current design. It holds for every reachable state, and a bounded check 25 steps deep also passes.
- 4Read the fix by the core's maintainers only after the proof. It adds zext.h to the decoder, which is exactly the gap the failing case showed.
3Result
The bug is reproduced on the design before the fix, and the rule holds on the current design.
The result holds only for the configuration we ran, with all four B extension parts on, and the fix is checked only against our own checks.
Have a bug like this one?
Describe the problem in a few lines. An engineer replies, and we agree the scope together.
Discuss a verification problem