Debug, interrupt, and exception verification
Check how the controller handles a debug halt, an interrupt request, or an exception.
How the check works
Follow the event through the controller.
Present the events
Exercise a halt or fetch fault alongside a qualified interrupt request.
Check the priority
Observe the cause, acknowledgement, and state selected by the controller.
Follow the next step
Check the return from debug or the exception redirect outputs.
Concept illustration. The published controller example models the surrounding pipeline and qualified interrupt input. Those assumptions remain part of its result.
What you receive
- Directed tests for the agreed debug, interrupt, and exception interactions.
- Recorded control outputs and failure diagnostics.
- A regression that checks the same requirements after a change.
- The tested configuration, environment assumptions, and untested behaviours.
When this is useful
- Debug entry and interrupts arrive close together.
- Single step or return from debug behaves unexpectedly.
- A controller change needs a focused regression around debug, interrupts, or exception priority.
Problem, approach, and required inputs
The problem
Debug and interrupts can interact at the same instruction boundary. A check of each feature on its own may miss a priority error, an interrupt acknowledged during debug, or a failure to resume.
What we do
We define the sequences and expected control responses, drive the agreed inputs, and inspect debug state, interrupt acknowledgement, exception routing, and return behaviour. A controller test isolates control logic; whole-core software execution and external debug transport require additional integration work and an explicit scope.
Inputs agreed after scoping and NDA
- The core revision and enabled features.
- The debug and interrupt requirements and the relevant interface behaviour.
- The pipeline or testbench assumptions under which the checks should run.
Related public demonstration
Public demonstration, not a client result
A brief halt request is lost at a control boundary
Ordinary tests pass, but requests arriving during a stall, exception flush, or debug return expose seeded faults in a real RISC-V controller.
Technical details
How the result is checked
The public example tests an unchanged, pinned OpenHW CV32E40P controller. Ordinary tests pass on four synthetic variants, while temporal checks expose request-retention and validity-gating faults around stalls, exception flush, and debug return. It also retains normal halt, resume, single-step, and interrupt-priority checks.
Tools used for this kind of work
- SystemVerilog
- Verilator
- Python
Scripts are handed over as agreed in the scope. If we have not tested your simulator or flow, the scope says so.
Discuss this problem.
Tell us what you are trying to verify and what is blocking you. A person replies, and the scope comes back in writing after a call.
Discuss a verification problem