Debug-mode exceptions mis-vector: parking_loop+8 assumes a 2-slot ROM, collides with a 3-slot riscv-dbg ROM

Summary

When c-class is integrated with PULP riscv-dbg as the external Debug Module, a trap taken in Debug Mode is mis-vectored — it lands on riscv-dbg's resume handler instead of its exception handler. Consequently, an abstract-command access to an unimplemented CSR (which c-class correctly traps) causes the hart to resume out of debug, and abstractcs.cmderr is never set (stays 0 with stale data).

Root cause

c-class vectors a Debug-Mode exception to debug_parking_loop + 8 (csrbox.bsv:253-254). This assumes a 2-slot debug ROM (entry@base, exception@base+8). PULP riscv-dbg uses a 3-slot ROM: Halt@base, Resume@base+8, Exception@base+16. So with parking_loop = 0x800, a Debug-Mode exception vectors to 0x808 = riscv-dbg's Resume handler (which signals "resume"), not 0x810 = the Exception handler (the only handler that sets cmderr=3).

Evidence

  • c-class DOES trap on the unimplemented CSR (decoder.bsv:480,551,568, address_valid()==False -> illegal-instruction).
  • The trap jumps to 0x808 -> the hart resumes out of debug; the ExceptionAddress write never happens -> cmderr stays 0, data is stale.
  • Single-step / ebreak are unaffected (they use the correctly-aligned entry vector at base).
  • This affects ALL Debug-Mode exceptions, not only unimplemented-CSR accesses.

Expected

A Debug-Mode exception should reach the Debug Module's exception handler so cmderr is set and the hart stays halted.

Suggested fix

Make the Debug-Mode exception vector configurable (rather than hardcoding parking_loop + 8), so an integrator can point it at a 3-slot ROM's Exception slot — or document the debug-ROM layout contract c-class assumes.

Question

Is the parking_loop + 8 exception offset intended to be fixed (2-slot ROM only)? A configurable offset would let c-class integrate cleanly with a standard riscv-dbg 3-slot ROM.