riscv
Add read-only shortcut to pending interrupts?
Currently to be able to see which interrupts are pending, software would have to do a LD instruction to access each clicintip.
Should we add a read-only ip status range with 1 bit per pending interrupt (similar to AIA external interrupt-pending registers eip0-eip63) so software can quickly see the state of interrupt pending bits?
It might also be useful to have a memory map view similar to AIA external interrupt-enable registers (eie0-eie63) where software can quickly enable, disable multiple interrupt enables. xintthresh kind of allows this kind of ability, but sometimes the set of interrupt enables may be based more on functional mode instead of level priority.
would it make sense to have a software clint compatibility mode option where writes to CSR xIP, xIE is equivalent to writing to these shortcut bits? AIA directly references CLINT xIP xIDELEG registers. might be nice to have CLIC compatible with software like riscv-sbi ( https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/riscv-sbi.adoc )which references xIP, xIE. AIA compatible software will probably reference xIP, xIE also. seems like it would be easy for CLIC to support this alternate access method for interrupt pending and interrupt enables.
Not clear that CLIC needs this given that the hardware can automatically jump to the appropriate handler for a given interrupt input. Adding ability to read some bits via CSR might be OK, but allowing writes requires that a CSR write generates a memory-mapped I/O transaction in most implementations. Would need to see some use case that benefits from the feature.
just pointing out that CLIC already has defined the ability to clear clicintip via CSR: If the pending interrupt is edge-triggered, hardware will automatically clear the corresponding pending bit when the CSR instruction that accesses xnxti includes a write
Having a compressed bitmap view of the ip and ie bits could be useful, but should be done via a memory-mapped access to the CLIC registers. This would represent an alternative memory-mapped view of the same bits. This should provide the needed functionality without requiring new CSRs that perform memory transactions.