HW Interrupt Interfaces

[p d]

What are the hardware interrupt interfaces (interrupt request and acknowledge pin interfaces) defined in the RISC-V architecture?

[Dr Jonathan Kimmitt]

The platform level interrupt controller (PLIC) is mentioned in the The RISC-V Instruction Set Manual Volume II: Privileged Architecture Privileged Architecture Version 1.10 (on p69).

It does not constrain the implementation unduly but you can find example implementations in Rocket source code and in SiFive platform documentation.

On 15/10/18 11:01, p d wrote:

What are the hardware interrupt interfaces (interrupt request and acknowledge pin interfaces) defined in the RISC-V architecture?

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/a7f080b1-11b9-40dd-8c99-59fe6427f436%40groups.riscv.org.

[Gavin Stark]

The RISC-V architecture does not prescribe particular implementations. As a *core* all one is required to have for external interrupts is an external interrupt mechanism to drive the *single* external interrupt of the RISC-V (note that MEIP, SEIP and UEIP are all derived from the single external interrupt line, I believe).

PLIC details (see RISC-V privileged spec 1.10)

====================================

What the PLIC does (pg 72) is take level and edge sensitive interrupts and convert them into interrupt requests in PLIC ‘gateways’; the gateways must be memory-mapped from the processor, as each interrupt they present to the PLIC core must be acknowledged with some ‘interrupt completion message’. The spec does not provide details of an ‘interrupt completion message’, nor the memory map for any of this: it does note (pg 75) that an interrupt completion message is usually ‘ a write to a non-idempotent memory-mapped I/O control register’.

PCIe style MSI/MSI-X interrupt messages can be treated similarly to edge sensitive interrupts at a suitable PLIC gateway.

The PLIC core assigns a priority to each PLIC gateway input, and has selectable enables for each RISC-V ‘target’ (presumable a RISC-V hart) for each PLIC gateway input, and an interrupt threshold value for each target.

A target has its ‘external interrupt pending’ bit set if any of the PLIC gateways whose interrupts are enabled for the target are requesting an interrupt at a priority level greater than the threshold.

Priority levels start at 0 - actually meaning ‘never interrupt’ and go up.

If two PLIC gateways are requesting an interrupt at the same priority level for a specific target then the lowest numbered gateway is selected (gateways are numbered 1 upwards).

The PLIC core must provide access to an ‘interrupt claim’ register for a target that can be read to yield the ‘id’ of the selected gateway, atomically clearing the interrupt pending bit in the PLIC core for that gateway.

The interrupt routine must, if the id is not 0, handle the interrupt and then issue a completion to the gateway, which may then reassert the pending bit in the PLIC core.

Although the spec does not prescribe a PLIC register layout and so on, there is the standard RISC-V implementation problem here of - if it ain’t compatible with RocketChip, you’re on you’re own. For example, I’ve just been digging in to Zephyr; basically it assumes a PLIC unless you are qemu. And by PLIC, it means ‘the rocket-chip PLIC’. So whatever register layout it has (I have not dug in to that yet), you need too.

Summary of the PLIC

================

The PLIC needs to be memory mapped with a ‘gateway’ for each external interrupt source; each gateway expects a single wire that may be edge or level triggered depending on the gateway type. The gateways are also memory-mapped.

The PLIC is not required from what I can see if there are zero or one external interrupt sources.

In my mind a PLIC is not required for a microcontroller with few interrupts: it increases the silicon complexity, complicates the software (with associated die impact in SRAM size).

Whether that would end up being ‘compliant’ is probably moot - for low end micro controllers being platform compliant is way less important than cost.

In summary, a RISC-V hart requires a single level-sensitive external interrupt line which gets to the xEIP bits, or nothing if you have no interrupt support; if you have more than one interrupt source, the spec may required a PLIC.

—Gavin

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/8fd321fd-cd88-d18c-5db5-3b011049249e%40cam.ac.uk.

[Gavin Stark]

Well, upon further delving, this is slightly incorrect - I was focusing on machine mode, but (a) I did not get all of machine mode and (b) there are extra bits for user mode and supervisor mode but not actually for those modes but for machine mode after all.

It is allowed to have SEIP and a UEIP external interrupt pins (one for supervisor, one for user).

These have individual enables in the machine interrupt enable register, so a SEIP (supervisor external interrupt pending) can interrupt machine mode. This is in addition to the machine mode having a bit it can set/clear that is a soft SEIP.

SEIP is only a supervisor external interrupt *if* mideleg.seip is set.

UEIP is only a user external interrupt *if* mideleg.ueip is set.

User-mode interrupts are an extension to the base ISA (extension N). That is not ratified yet.

The spec mentions that a PLIC *may generate* the SEIP and UEIP external interrupt pins.

So, in summary again, my reading *as of now* is:

A RISC-V hart requires a single level-sensitive machine external interrupt line which gets to the MEIP bit, or nothing if you have no interrupt support; if you have more than one interrupt source, the spec may required a PLIC. It may also have SEIP and UEIP external interrupt lines that are also level-sensitive, which may come from the PLIC.

—Gavin

[kr...@berkeley.edu]

In a bare core, there are also space for custom local interrupt
signals in bits 16 and up of mip/mie. These can be hardware vectored.

The new CLIC proposal replaces these with a more flexible local
interrupt controller,

Krste

| 8fd321fd-cd88-d18c-5db5-3b011049249e%40cam.ac.uk.

| --
| You received this message because you are subscribed to the Google Groups
| "RISC-V HW Dev" group.
| To unsubscribe from this group and stop receiving emails from it, send an email
| to hw-dev+un...@groups.riscv.org.
| To post to this group, send email to hw-...@groups.riscv.org.
| Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
| To view this discussion on the web visit https://groups.google.com/a/
| groups.riscv.org/d/msgid/hw-dev/

| D2D94277-721A-4FC3-91CA-615AA0DE2837%40gmail.com.

[Gavin Stark]

Indeed; in an italicised note in the Privileged spec v1.10 page 30 it notes:

Implementations can add additional platform-specific machine-level interrupt sources to the high bits of these registers, though the expectation is that most external interrupts will be routed through the platform interrupt controller and be delivered via MEIP

I hadn’t spotted that earlier; Table 3.6, though, for mcause indicates that values 12+ are reserved - presumably that does not match up with the italicised commentary note? Presumably these extra interrupts are also delegatable by mideleg? And the upper bits of mip are not WIRI in this case, and those of mie are not WPRI?

[I’m writing up summaries of the specs and mailing list discussions on my wordpress site as I try to finish my RISC-V implementations - and today was interrupts - so if I can get clarity here it will help posterity (until a later-than-v1.10 comes out)]

—Gavin

[Samuel Falvo II]

On Mon, Oct 15, 2018 at 6:15 AM Gavin Stark <atthec...@gmail.com> wrote:
> SEIP is only a supervisor external interrupt *if* mideleg.seip is set.
> UEIP is only a user external interrupt *if* mideleg.ueip is set.

More precisely, UEIP is only a user external interrupt if and only if
mideleg.ueip=1 **and** S-mode exists **and** sideleg.ueip=1 **and**
U-mode exists **and** N-extension is supported.

> A RISC-V hart requires a single level-sensitive machine external interrupt line which gets to the MEIP bit, or nothing if you have no interrupt support; if you have more than one interrupt source, the spec may required a PLIC. It may also have SEIP and UEIP external interrupt lines that are also level-sensitive, which may come from the PLIC.

You can have up to XLEN interrupt pins. For example, an RV32 system
can respond to up to 32 external interrupts without additional
hardware support. Note that timer and inter-processor interrupts are
merely conventional applications of those eponymously named interrupt
bits, but can in fact be used for anything.

--
Samuel A. Falvo II

[Puneet Dhar]

Hello All.. 

Thank you all for pouring in with so much information. I understand this much better now. I have two more questions. 

Between the PLIC and the RISC-V core - there has to be memory port for access to the PLIC programmable memory mapped registers. 

Q1) Besides that PLIC port, is there a slave port on the RISC-V core/cores that are working with a PLIC to allow for memory mapped access to the mip register? 

Q2) And what about the interprocessor interrupts - are the interprocessor interrupts established through the memory accesses via these slave ports on the riscv core's memory mapped mip register's software register bits?

[Samuel Falvo II]

On Mon, Oct 22, 2018 at 5:14 AM Puneet Dhar
<thatstheb...@gmail.com> wrote:
> Q1) Besides that PLIC port, is there a slave port on the RISC-V core/cores that are working with a PLIC to allow for memory mapped access to the mip register?

While that is one approach, it's quite unnecessary.

The simplest implementation that remains compliant to the
specifications is to have the mip register be a kind of input port --
if an interrupt pin is asserted, the corresponding bit in mip turns
'1'. If the interrupt pin becomes negated, the mip bit turns '0'.
Indeed, if mie is set to all zeros, you can use mip as a kind of
general purpose input port.