LMARV-1 reboot part 6: About CSRs and interrupts

This part explains a bit about CSRs (Control and Status Registers) and how interrupts get handled.
nMigen exercises: github.com/RobertBaruch/nmige...
github repo for code: github.com/RobertBaruch/riscv...
RISC-V specs: riscv.org/technical/specifica...
nMigen tutorial: github.com/RobertBaruch/nmige...

[@douggale5962]

Little psychology tip: when giving people a set of alternatives, always give them the choice that you want to encourage them to pick as the last option. If they are indifferent, and don't care which one, they will tend to pick the last one, because it is easiest to remember. Should be more like, "upvote if you thought it was useful", and just omit the not up-voting, the "if" covers it!

[@TomStorey96]

Im already feeling the anxiety of this becoming a huge project 😋

[@der.Schtefan]

If ECALL, context switches, etc. seem to be too problematic, you can opt for not supporting interrupts in V1 of your hardware or only support it in a limited fashion (Machine level external interrupt routine for IO), especially if you have a microcontroler-like machinelevel-only hardware. V2 of your hardware (or nMigen simulation) then can add more and more. It is easy to lose oneself in the vast space of Interrupts, context switches, and the dozens and dozens of CSRs Risc-v can support. But since right now you are also in control of the software that will run on your hardware, you can limit the support as far as needed to have a minimum-viable-hardware, and add more later. Helps preventing frustration :)

[@AmitsLife]

Thank you

[@maikmerten]

17:10 I think that ecall from machine mode in that table is Interrupt=0, ExceptionCode=11 and ebreak is Interrupt=0, ExceptionCode=3.

[@xavierthomas1980]

Yes I think too. The machine software interrupt (Interrupt=1, ExceptionCode=3) is for IPI (inter-processor interrupts) and happens when writing to a specific memory-mapped CSR of the HART's interrupt controller.

[@der.Schtefan]

ECALL vs INT: x86 has a similar situation with the SYSCALL and INT 80h semantic. SYSCALL on x86 is newer/faster, vs the old method of setting up registers and then calling INT 80h (which is simply a random convention in software like MS-DOS or old windows, etc). RISC-V maps ECALL to various interrupts, depending on wether the ECALL happened in User/Supervisor/Machine mode. This is the way how RISC-V performs kernel calls (setup registers in user mode, then call ECALL, which is handled by a handler running in Supervisor / machine mode). If you only want to run privileged machine level code like in a microcontroller without an operating system, ECALL would always hit INT 0/11. You can also skip calling ECALL in such a case, since you'd anyway just call whatever code you want. RISC-V also supports interrupt handling, and software can setup and trigger interrupts. Google For the SiFive Interrupt Cookbook: sifive.cdn.prismic.io/sifive/0d163928-2128-42be-a75a-464df65e04e0_sifive-interrupt-cookbook.pdf SiFive is the company that is driving RISC-V software and hardware development the most prominent, and their interrupt overview is quite nice.

[@paco3447]

Amazing. As a matter of curiosity, did the previous ttl tangible version were built using bit slices? Let’s say amd 4bit or whatever. I remember some Apollo workstation emulating a 68k10 Instruction Set out of amd bit slices.

[@RobertBaruch]

Nope, no bit slices.

[@paco3447]

@@RobertBaruch Awesome. Thank you.

[@costa_marco]

I am concerned about conditional jump. PC+4 at interrupt return might not work. But I didn't read the RISCV documentation about it.

[@RobertBaruch]

Me too, I'm not completely sure how it's supposed to work. We know what PC we're targeting once the branch instruction is done, but why wouldn't we store that in MEPC? Unless it's different between interrupts (store the return address) vs exceptions (store the exception-causing instruction address)?

[@costa_marco]

Unless you just keep the next PC as it is in the PC register and stores the current executing PC into the CSR. When you return, the PC is already pointing to the right address. That is my interpretation of the document. You said you will have a switchable register bank, that would work just fine, as all registers are swapped at interrupt service.

[@maikmerten]

@@RobertBaruch From section 3.2.1 of the Priv Spec: "ECALL and EBREAK cause the receiving privilege mode’s epc register to be set to the address of the ECALL or EBREAK instruction itself, not the address of the following instruction." In general, it appears that if an instruction causes a trap/interrupt, then MEPC will contain the address of that instruction. To resume, one would read MEPC, increment it by the instruction length, write back MEPC, then return from the service routine. For external interrupts MEPC contains the return address. A few years back I filed an issue for a clarification in the spec: github.com/riscv/riscv-isa-manual/issues/106

[@der.Schtefan]

Before serving an interrupt, you might need to compute the next instruction (PC+4 or target instruction in case of a jump (even unconditional jump)), store that on stack, and jump there afterwards. Storing the registers during a context switch might be imperative anyway. See section 5.2 Context Switch Overhead for a quick overview in case of an ECALL instruction of the SiFive interrupt cookbook. sifive.cdn.prismic.io/sifive/0d163928-2128-42be-a75a-464df65e04e0_sifive-interrupt-cookbook.pdf

[@TomStorey96]

@@RobertBaruch I think that sounds logical. In an exception you want to know what broke, but in an interrupt you want to know where you should go back to. An exception handler can try and recover from the error and could then return to the application that caused it by doing it's own calculation on the return PC (or go back to the original PC and retry), or it could simply trash it and restart it.