Some questions about tdata1.nmi and tdata2 of itrigger

[tmoil]

According to the RISC-V Privileged Specification, the interrupt encoding for NMI is implementation-defined, meaning NMI must have a corresponding cause code. Since this cause code exists, an itrigger could theoretically match an NMI interrupt by configuring tdata2. Why then is there a dedicated nmi field in tdata1 for itrigger?

thanks

[pdonahue-ventana]

The main reason is that this provides an implementation-independent way for a standard debugger to deal with NMIs. If every implementation has different causes then debuggers need to deal with lots of different possibilities for how to catch NMIs.

[tmoil]

In the hardware implementation, does it support either tdata2 or tdata1.nmi to allow itrigger to match on NMI interrupts, or does it only support the tdata1.nmi method? Based on your response, I believe you tend to implement it according to the latter approach? But i see that Spike supports both approaches, implemented as an OR logic. However, Spike makes an assumption that the cause of NMI is 0, whereas in our actual hardware implementation, the cause of NMI is not 0.