A timer write triggers an interrupt at rollover
An ordinary timer test passes. A write at the carry boundary reproduces a historical upstream defect and its spurious interrupt.
Public demonstration
This is not a client result. The recorded command and check status appear below.
Recorded outcome
Two ordinary scenarios pass before and after. Five boundary scenarios fail with the required diagnostic before the upstream fix and pass after it, including the spurious timer interrupt.
What was checked
- Problem
- A timer increments while software writes one half of its 64-bit value. At rollover, the old implementation also increments the untouched half. That can unexpectedly cross the interrupt threshold.
- Scope
- The real OpenHW verification platform mm_ram module, with its RAM and bus response helpers. This is a historical upstream defect reproduced independently, not a new Rivoryxa discovery or a processor core defect.
- Approach
- The same public bus transactions run against upstream revision 1726d147 and the correction at 00112741. Ordinary low writes and free-running carry pass on both. Targeted writes isolate low-half carry corruption, high-half preservation, and the resulting timer interrupt.
- Evidence
- Separate builds use exact unchanged historical RTL. Logs retain the named before failures, after passes, compiler commands, source and simulator hashes, tool versions, and timings. No timer state is forced. The original fix is attributed to its upstream author.
Scope and limits
What these checks do not establish.
- The fix was authored upstream by karabambus. Our work is the independent regression and reproduction, not authorship of that fix.
- This is verification-platform RTL, not an ACT test running on the CPU or a discovered processor bug.
- Directed simulation covers timer write and carry interactions only. It does not establish a formal proof or full peripheral correctness.
- RAM traffic, random stalls, byte-write semantics, debug generation, and the separate platform-register correction are outside this regression.
Reproduce and inspect
Recorded verification status
Independently reproduced from a fresh clone of harness revision 13172ba on 15 September 2026. The same bench runs seven scenarios on each of two unchanged upstream revisions: all fourteen expected outcomes match. Fifteen harness tests pass. Exact versions and source hashes are recorded in the repository.
git clone https://github.com/Rivoryxa-Technologies/riscv-act4-verification
cd riscv-act4-verification
# Install Python 3, Git, Verilator, make, and a C++ compiler.
python3 -m unittest discover -s tests -v
python3 historical/run.pyhistorical/README.mdcause, upstream attribution, and scopehistorical/mm_ram_timer_tb.svbus stimulus and checkshistorical/run.pyexact historical sources and outcome matrixrecorded/2026-09-15-historical-bus/independent logs and source hashesWant this method on your design?
Share the problem in a few lines. We will discuss the scope before any confidential project material changes hands.
Discuss a verification problem