3

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!

zeke
  • 155
  • 3
  • 8

2 Answers2

3

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.

yflelion
  • 1,698
  • 2
  • 5
  • 16
  • The excerpt you shared is for ```sip``` register, not for ```mip``` register, and S-mode and U-mode are not mandatory. Nevertheless, according to the spec, the ```mip.MSIP``` bit is "written by accesses to memory-mapped control registers". Does this simply mean that a simple store instruction is used to set/clear that bit? – zeke Nov 16 '20 at 21:20
  • Restricted views of the mip and mie registers appear as the sip/sie. For the write It means you need to set the bit in the csr by using a csrw, csrs .... – yflelion Nov 16 '20 at 21:40
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)

Erik Eidt
  • 23,049
  • 2
  • 29
  • 53
  • 1
    This almost makes sense but what you listed are _exceptions_, not _interrupts_. So, how can they be _software interrupts_? In particular, you explicitly said ```ecall``` can trigger a software interrupt. However, the spec clearly states that an ```ecall``` instruction will generate a ```environment-call-from-X-mode``` exception, where __X__ is the privilige mode. Looks like there is some contradiction going on, can you clarify? – zeke Nov 16 '20 at 22:36
  • Software interrupts ***are*** exceptions. The processor uses the same exception handling mechanism for both external interrupts and software interrupts -- there is only one mechanism. – Erik Eidt Nov 16 '20 at 23:09
  • From a software perspective, software interrupts and external interrupts appear quite different. But from the hardware perspective, only one mechanism is needed to service both. – Erik Eidt Nov 16 '20 at 23:15
  • I agree that the handling mechanism is identical, however there are some important details that still do not add up. You're saying the _exceptions_ listed above __are__ _software interrupts_. In the priviliged spec, we can see the _exception codes_ for all interrupts and exceptions in RISC-V. [Here](https://imgur.com/a/u1zjW7g) is that table for convenience. Clearly, _software interrupts_ and _exceptions_ do not share the same exception codes. In fact, each of the exceptions you listed have their own exception codes. – zeke Nov 16 '20 at 23:28
  • So, for instance, in the case of an instruction address misaligned _exception_, how will the hardware handle it? Is it going to generate a _software interrupt_ as you claim? Or is it going to generate a ```instruction address misaligned``` _exception_? – zeke Nov 16 '20 at 23:30
  • There's not that much to it. Exceptions and Software Interrupts share the same hardware exception mechanism. For both/either, the same exception handler will be run and it will check to see what the cause was: it will consult the "interrupt" bit and if that is set it will interpret the "Exception Code" using the first half of the table, and if clear, it will consult the 2nd half of the table. – Erik Eidt Nov 16 '20 at 23:33
  • I see. I think the question I should have asked is this: When will the ```MSIP``` (machine software interrupt pending) bit will be set in the ```mip``` register? And I'm guessing the answer is: whenever the exceptions you listed above occur. Correct? – zeke Nov 16 '20 at 23:36
  • Sorry, I don't know the valid usages of the `MSIP`. Note that the RARS simulator will simulate exceptions of several kinds and you can write a custom exception handler that determines the cause (using the `mcause` CSR) and takes appropriate action. – Erik Eidt Nov 16 '20 at 23:42
  • See also https://stackoverflow.com/a/61916199/471129 and https://stackoverflow.com/a/63206687/471129 – Erik Eidt Nov 16 '20 at 23:44
  • I have that post open in another tab actually, and have been referring to it. Thanks for the tip! – zeke Nov 16 '20 at 23:46