Stop cancelled work from returning after reset
Reset arrives with requests still in flight. The test checks that cancelled responses disappear and new work returns in order.
Public demonstration
This is not a client result. The recorded command and check status appear below.
Recorded outcome
All nine correct runs pass the reset, ordering, and latency checks. All nine deliberately broken runs report the expected reset failure. The result shows why a reset test must include work already in flight.
What was checked
- Problem
- A pipeline can appear correct during normal traffic yet return old responses after reset. The receiving system may mistake those responses for new work.
- Scope
- An original request and response pipeline that adds a constant to each accepted word. Reset cancels pending requests. Tests cover width/stage/bias settings 8/2/3, 8/3/7, and 16/5/257, each with seeds 1, 17, and 2026.
- Approach
- A scoreboard records the expected value and response cycle. Directed and seeded traffic exercise reset with pending work, repeated reset, and recovery. The deliberate mutant retains valid flags during reset, exposing responses that should have been cancelled.
- Evidence
- Each run retains compile and simulation logs, parameters, seeds, commands, tool versions, source hashes, and timings. A mutant counts as detected only when the named reset diagnostic and failure status are present. The correct design is also checked for output ordering and latency.
Scope and limits
What these checks do not establish.
- This is a small original demonstration with a seeded defect, not a result from a client system.
- Reset is synchronous within one clock domain. Asynchronous release and reset across clock domains are outside the test.
- The response consumer is always ready. Output backpressure is not implemented by this interface.
- Finite stimulus at the listed configurations is not an exhaustive proof or a timing guarantee. Tool runtimes do not measure engineering effort.
Reproduce and inspect
Recorded verification status
Rerun from public GitHub revision 66555fc on 15 September 2026 with Python 3.9.6 and Icarus Verilog 13.0. Nine correct runs pass; nine seeded variants fail the named reset check. Four runner regression tests also pass.
git clone https://github.com/Rivoryxa-Technologies/reset-recovery-verification
cd reset-recovery-verification
# Install Python 3.9+ and Icarus Verilog first.
python3 tools/run.py
python3 tools/test_runner.pyrtl/response_pipeline.svpipeline and explicit teaching switchtb/tb_reset_recovery.svcancellation, data, and latency checkstools/run.pyreproduction and measured resultstools/test_runner.pyfailure classification checksrecorded/2026-09-15/reviewed 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