CV32E40P does not signal signal 'halted', 'running', 'havereset' to the Debug Module

Created by: Silabs-ArjanB

The interface between the PULP Debug Module (https://github.com/pulp-platform/riscv-dbg) and the CV32E40P is not as it should be. In short the CV32E40P does not have a proper way to signal 'halted', 'running', 'havereset' to the Debug Module as is required from the Debug spec:

In the current implementation the Debug Module itself has a notion of whether the RISC-V core should be considered 'halted', 'running', or 'havereset'. Unfortunately the RISC-V state as thought of by the Debug Module can easily become out of sync with the actual CV32E40P state as is reported in https://github.com/pulp-platform/riscv-dbg/issues/65. Only the CV32E40P will know whether it has actually been reset; the Debug Module cannot assume that this happened for example because it caused an ndmreset.

The proper way to address this issue would be to make the CV32E40P itself responsible for signaling 'halted', 'running', 'havereset' on its interface (as written in the RISC-V debug spec). These signals are expected to be easily available (or constructable) from within the CV32E40P, e.g. 'halted' is equal to the existing debug_mode_q flop.