RISC-V - Software Interrupts

Question

I'm trying to implement a simple interrupt controller for my RV32I core. I believe I understand how an interrupt should be handled in RISC-V, and the role of the CSR registers in the process.

RISC-V defines three sources of interrupts: External, Software and Timer. I understand how a timer and an external interrupt would generate. However, I do not understand how or what would generate a software interrupt. An instruction? A sequence of instructions? Maybe implementation defined flags? I have no idea.

Could anyone give an example and the explanation of a software interrupt, preferably with the associated assembly code if it is relevant?

Thanks in advance!

Answer 1

What you are looking for are SSIP and USIP bits from the mip csr.

A supervisor-level software interrupt is triggered on the current hart by writing 1 to its supervisor software interrupt-pending (SSIP) bit in the sip register. A pending supervisor-level software interrupt can be cleared by writing 0 to the SSIP bit in sip. Supervisor-level software interrupts are disabled when the SSIE bit in the sie register is clear.

A user-level software interrupt is triggered on the current hart by writing 1 to its user software interrupt-pending (USIP) bit in the sip register. A pending user-level software interrupt can be cleared by writing 0 to the USIP bit in sip. User-level software interrupts are disabled when the USIE bit in the sie register is clear.

You can find this information in The RISC-V Instruction Set Manual Volume II: Privileged Architecture V20190608.

Answer 2

Software interrupts are caused by (user) program execution.

Software interrupts can occur from ecall — the equivalent of syscall on MIPS; this is a request of a user program for operating system services and it crosses privilege boundaries in a well-controlled manner.

Software interrupts can also occur from memory operations that are illegal or malformed, i.e. lw, sw.

Look at the list of exceptions on Tables 3.6, 4.1 (here I'm only showing the 2nd half; note that ecall appears in the first half):

• 0 Instruction address misaligned
• 1 Instruction access fault
• 2 Illegal instruction
• 3 Breakpoint
• 4 Reserved
• 5 Load access fault
• 6 AMO address misaligned
• 7 Store/AMO access fault
• 8-11 Environment

The first is caused by placing bad value (e.g. odd) in the program counter, which might be caused by a jump register or return whose stack was corrupted.

The next by allowing the program counter to refer to an unmapped address, i.e. a page not marked executable.

Breakpoint is used by software during debugging, usually.

Load access fault refers to using load or store to an unmapped or otherwise protected address.

The atomic operations are given their own exception numbers (not sure why).

And lastly, they can be caused by switching between privilege modes (U,S,H,M)