[BUG] Core lockup with short debug pulses (1-2 cycles)

[Amit-Matth]

Bug Description

Description

The cve2 core fails to enter debug mode and locks up (or behaves unpredictably) when the debug_req_i signal is asserted for a short duration (1 or 2 clock cycles). This was observed in the cv32e20-dv environment but is caused by the core's handling of the debug request signal.

Root Cause

The cve2_controller FSM uses combinatorial logic to detect debug requests:

assign enter_debug_mode = enter_debug_mode_prio_d | (trigger_match_i & ~debug_mode_q);

enter_debug_mode_prio_d is derived from debug_req_i. Use of grep confirms that enter_debug_mode_prio_q (the registered version) is assigned but never used in any state transition logic or output assignment. It effectively acts as dead code.

Because it is not used in the enter_debug_mode condition, the request is dropped immediately after the pulse ends if the core was not ready to accept it.

Steps to Reproduce

1. Run a test case (e.g., debug_test.c that pulses debug_req_i for 1 or 2 cycles.
2. Ensure the core is busy (e.g., executing instructions) during the pulse.
3. Observe that the core continues execution instead of entering debug mode, or enters an inconsistent state.
4. Simulation assertion failure (if enabled): IbexDontSkipExceptionReq.

Proposed Fix

Modify cv32e20/rtl/cve2_controller.sv to include the registered debug request signal (enter_debug_mode_prio_q) in the valid debug mode entry condition. This makes the request "sticky" for at least one extra cycle.

// old
// assign enter_debug_mode = enter_debug_mode_prio_d | (trigger_match_i & ~debug_mode_q);

// new
assign enter_debug_mode = enter_debug_mode_prio_d | enter_debug_mode_prio_q | (trigger_match_i & ~debug_mode_q);

Verification

With the proposed fix, the core correctly detects 1-cycle and 2-cycle debug pulses and transitions to the debug ROM address as expected.

[davideschiavone]

Dear @Amit-Matth , thanks for catching this up

The enter_debug_mode_prio_q is actually not dead, it is used here

Nevertheless, the bug you found could indeed be related to the combinatorial logic, and the fix you propose could make sense. I would need to try it (and I will do it asap)

Even if combinatorially, I see enter_debug_mode and related are present in different scenarios, so I guess the tests was in a state that did not catch it, and I am courious to know why.

[Amit-Matth]

Dear @Amit-Matth , thanks for catching this up

The enter_debug_mode_prio_q is actually not dead, it is used here

Nevertheless, the bug you found could indeed be related to the combinatorial logic, and the fix you propose could make sense. I would need to try it (and I will do it asap)

Even if combinatorially, I see enter_debug_mode and related are present in different scenarios, so I guess the tests was in a state that did not catch it, and I am courious to know why.

Thanks for pointing that out, you’re absolutely right that enter_debug_mode_prio_q is used in the FLUSH state (around line 690). I shouldn’t have implied it was dead code.

What I meant is that it is not part of the debug entry condition in DECODE (and similarly FIRST_FETCH, IDLE, etc.), which is where the core evaluates debug entry during normal execution.

In the failing scenario, the transition from DECODE to DBG_TAKEN_IF depends solely on the combinatorial enter_debug_mode. If a short debug_req_i pulse occurs while the core is busy (for example, during a multi-cycle instruction or a stall) and the pulse deasserts before the FSM evaluates the DECODE transition, the request can be missed.

Although enter_debug_mode_prio_q correctly registers and holds the request, DECODE does not currently take it into account for debug entry. That’s why the pulse can effectively be lost in that path.

The proposed change simply makes the debug entry condition in those states also consider the registered request, improving robustness to short pulses during normal operation.

I agree that the exact behavior depends on the FSM state at the time of the pulse, I’m also curious which specific condition in the test prevents it from being caught combinatorially.

[davideschiavone]

hi @Amit-Matth - what you say makes sense to me. @MikeOpenHWGroup is trying to reproduce it in Verilator so that I can fix the RTL. If in the meantime, you can further provoke the same bug in different states, it would be amazing so that we can add this to the cve2 regression test.

Once we fix this, we should also report it to the Ibex community as I briefly check the code and it remained unchanged, so I believe Ibex has the same bug

[Amit-Matth]

Hi @davideschiavone, thanks for taking the time to look into this.

Already on it! I've confirmed the bug for Test 1 (debug request during illegal instruction). Without the fix, the core silently misses the request and gets stuck waiting for the debugger forever. With the fix applied, it correctly catches the request and enters debug mode.

I'm now extending the test to cover two more scenarios:

WFI (sleep): The core is asleep waiting on a wfi instruction. When a single-cycle debug request arrives, the core starts waking up, but by the time it's ready to check for debug mode entry, the request has already gone low. So the core wakes up and just continues running normally, completely unaware a debug request was ever sent.

DIV (multi-cycle instruction): The core is in the middle of a division, which takes several clock cycles to complete. A single-cycle debug request arrives mid-way through, but by the time the division finishes and the core checks for debug requests, the signal is already gone. Again, the core just carries on as if nothing happened.

Both scenarios should hit the same root cause and will be added to the regression suite once confirmed.