Closed hegza closed 3 months ago
Wooohoo! Love to see this, thanks so much :) I'll take a look at your implementation ASAP.
Beware that the specification of the CLIC is in flux. So what's in the current spec may change.
Ah, the CLIC spec has actually just a few days ago left it up to the implementor to define the MMIO layout that this PR implements. The few platforms that do implement CLIC do use this layout however so I guess it can be useful 😃 Gosh. Let's sit on it a while and see where this goes.
The CSR updates have stayed the same and we'll be implementing & testing that behavior anyway. mtvt
, mnxti
, mintstatus
and mintthresh
CSRs are used in testing already but not yet part of this PR.
Forgot about this PR!
I'm OK with merging in master an implementation that matches the current specification and updating this implementation as the specification changes.
OK yeah, that sounds reasonable. I've been writing a journal the last 2 weeks and I was just getting back into working on the real-time system implementing this CLIC starting halfway through next week. I think I can get some update done on this within the next month.
Closed due to MMIO interface obsolescene. I'll re-open / link to this one once I've got the new CSR API working.
Specification: https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc
We've made a research prototype hardware implementation of rv32emc + CLIC and have completed preliminary tests showing that this software implementation for CLIC works. However, there's a few open issues:
riscv::register::mcause
dynamically allocates a different number of bits forcode
depending on whetherriscv::mtvec::trap_mode
is set toClic = 0b11
or not.riscv_peripheral::clic::intctl
depends on the value set inriscv_peripheral::clic::smclicconfig::mnlbits
.clicintx
registers slightly un-ideal.