Interrupts from external peripherals - can I (or should I) use FIRQ?

[jaaaaaaaaan]

I have some peripherals connected via Wishbone interface to the noerv32 and I would like them to request interrupts. At the beginning I thought I would use soc_firq_i input of neorv32_top entity port and simply connect that to adequate output of peripheral, but then I have spotted this two paragraphs in the docs, first one stating that:

2.3.2. NEORV32-Specific Fast Interrupt Requests
As part of the custom/NEORV32-specific CPU extensions, the CPU features 16 fast interrupt request signals (FIRQ0 – FIRQ15). These are used for processor-internal modules only (for example for the communication interfaces to signal "available incoming data" or "ready to send new data").

second one stating that :

Custom Fast Interrupt Request Lines
As a custom extension, the NEORV32 CPU features 16 fast interrupt request lines via the firq_i CPU (/Processor) top entity signals. These interrupts have custom configuration and status flags in the mie and mip CSRs and also provide custom trap codes in mcause.

And I don't quite understand. If I shouldn't use those interrupts for any "external stuff" then why they are available as an input in top entity? Why there are only 6 of them in the top module? Have I confused these with other interrupts? How can I implement what I want in the "right" way?

[stnolting]

I have some peripherals connected via Wishbone interface to the noerv32 and I would like them to request interrupts. At the beginning I thought I would use soc_firq_i input of neorv32_top entity port and simply connect that to adequate output of peripheral, but then I have spotted this two paragraphs in the docs, first one stating that:

Right. The FIRQ signals are no longer available via the processor top entity. I decided to use them only for processor internal modules.

second one stating that :

Seems like this section is a little bit misleading - I will fix the text there. 😉

So if you want to use "custom processor-external interrupts" you can use one of the processor top' interrupt signals:

    -- Interrupts --
    nm_irq_i       : in  std_ulogic := '0'; -- non-maskable interrupt
    mtime_irq_i    : in  std_ulogic := '0'; -- machine timer interrupt, available if IO_MTIME_EN = false
    msw_irq_i      : in  std_ulogic := '0'; -- machine software interrupt
    mext_irq_i     : in  std_ulogic := '0'  -- machine external interrupt

• nm_irq_i is a non-maskable interrupt intended for critical applications for example power failure.
• mtime_irq_i is reserved for a processor-external timer if the default internal timer (MTIME) is not used. this IRQ should not be used for custom applications.
• msw_irq_i this is a RISC-V standard interrupt that is specified for inter-CPU communication. However, you could use that for any custom purpose.
• mext_irq_i also is a RISC-V standard interrupt. This IRQ signal is designated for custom processor-external interrupt controllers, which handle several custom interrupt requests. So the most flexible way would be using this IRQ input and a custom interrupt controller that handles all of your interrupt sources.

Btw, how many interrupt sources do you have?

Maybe it would be a good idea to add an interrupt controller right inside the processor. This could serve as "external interrupt controller" providing something like 16 interrupt signals (via a new top signal) for custom usage. 🤔 I think this would make creating setups that require several interrupts much easier as there is no need to write a custom interrupt controller.

[stnolting]

Idea for a "workaround":

If you need several IRQs without a custom interrupt controller for mext_irq_i, you could use the GPIO input's pin-change interrupt. By this, any low-high or high-low transition on the GPIO input signals will trigger an interrupt. However, you will need some more software to determine the actual input signal that triggered the interrupt...

So maybe adding a new "external interrupt controller" module might be a good idea. 😉

[jaaaaaaaaan]

Btw, how many interrupt sources do you have?

For now 3, but might have more in the future. I think I'll go for ext. irq. controller, as you suggested, I think I might have an idea how to do it now, thanks for the answer once again.

[umarcor]

Maybe it would be a good idea to add an interrupt controller right inside the processor.

I think this might be considered a SystemTop, similar to the one with the Wishbone to AXI bridge. So, the interrupt controller can be external to the CPU, but provided in one of the preset SoC templates.

[GTrannoy]

It is good to know all about FIRQ because I used them.

So if it disappear I would to use maybe:
_ GPIO as you suggested: Good idea. But maybe it could be better to trig interrupt only on rising edge for example;
_ External interrupt controller: Another good option but you need to define communication through external bus or SPI, I2C, etc... ;
_ CFS ? Using CFS to add an interrupt controller with some registers directly accessible from core and interrupt on CFS inputs.

With last option, you can use CFS interrupt and have registers to enable/disable, choose rising/falling edge, etc...

btw if you add a specific interrupt controller, it would be better ! 😃

[stnolting]

@jaaaaaaaaan

I'm playing around with an interrupt controller I wrote some time ago for this project. I'm curious for your actual use case. Let's say we have 16 interrupt lines. Do you need different trigger configurations at the same time? So for example, IRQ(0) fires on high-level, IRQ(1) fires on a rising-edge and IRQ(2) fires on a falling-edge. Or do you think a global trigger configuration would be sufficient (all IRQs firing either on low-level, high-level, rising-edge or falling-edge)?

[GTrannoy]

For my personnal case, I think 16 is probably enough in most case.

But as we work with 32bits core, maybe it is not bad idea to use max of available field ?

And with 32 IRQs should follow 32bits registers for each IRQ like:
_ IRQ flags;
_ Enable/disable;
_ Mode level/front;
_ Parameter accordingly to mode (level: low/high or front: falling/rising);

• Probably a global register to allow global enable/disable and others if needed (...?)

I think it could help to allows choose each IRQ for different cases and be able to globally enable/disable all together.
But i know it could be done globally through a register with all individual enables too...

What concerning priority ?
More simple without, but maybe could be useful in some cases...

Just some propositions... 😉

[tmeissner]

We have similar requirements to the ones that @GTrannoy has. In our SW which currently runs on a Cortex-M3, we have quite a number of interrupts from external (custom) peripherals. Each one needs to be en/disabled, we use rising & falling edges modes. What we don't need is different priorities. I avoid them as I want to keep my SW simple. No different priorities -> No deadlocks caused by such things like priority inversion 😄

[GTrannoy]

As mentionned by @tmeissner, I have had the problem to handle with priorities too.
Often, I prefer avoiding situations of concurrent IRQs. And if i can not, I have always the question to define priorities with often hesitations because it is rarely very clear for all IRQs. And when it is done, it remains complicated to be sure that all would be correctly processed...

But anyway, in some cases, it is useful and even necessary... So I asked me if it could be a condition to synthetize or not that mecanism ?

I know it does not simplify the task ! 😉

Another possibility could be to keep it simpler and to let the 'mext_irq_i' available to add another more sophisticated interrupt controller, if needed.

And maybe it could be better to adding the interrupt controller nearby the processor in SoC templates as proposed by @umarcor . That way, it could be exchanged by others if needed. 👍

[stnolting]

But as we work with 32bits core, maybe it is not bad idea to use max of available field ?
And with 32 IRQs should follow 32bits registers for each IRQ like:
_ IRQ flags;
_ Enable/disable;
_ Mode level/front;
_ Parameter accordingly to mode (level: low/high or front: falling/rising);

• Probably a global register to allow global enable/disable and others if needed (...?)

This is quite close to what the RISC-V Interrupt Controller implements 😄

I think it would be better to have a rather small and simple controller that fits most needs. If you want, you could still disable this small IRQ controller by its generic and implement the full-scale RISC-V controller using the external bus interface and the provided RISC-V interrupt input signals. Or you could use this proposed small controller as template and implement a full custom one (maybe as CFS).

---

So this is what I came up with so far (let me know what you think 😉):

• use two or four 32-bit memory-mapped registers for configuration and status
• individual enable bits for each IRQ input
• a single global trigger configuration: I think a one-bit flag is sufficient here: high-level or rising-edge trigger. If you need low-level or falling-edge, you could just add a NOT to the according IRQ signal
• provide a pending register to check which IRQ inputs are active (have fired)
• provide a prioritized source register to check which IRQ should be served first (the one with highest priority)
• "merge" all interrupt into a single CPU FIRQ
  • no global enable required as the CPU already contains enable flags for each single FIRQ

From a software point of view, two concepts would be possible using the same interrupt controller.

1. Prorization by hardware

void external_irq_handler(void) { // gets automatically called the controller's FIRQ fires
  
  int source = get_irq_source(); // read the controller's source register, automatically acknowledges the according IRQ
  switch (source) {
    case 0: execute_handler_source_0(); break;
    case 1: execute_handler_source_1(); break;
  ...

2. Priorization by software designer

void external_irq_handler(void) { // gets automatically called the controller's FIRQ fires
  
  int source = get_pending_irqs(); // read the controller's pending register

  if (source & (1 << 0)) { // check if IRQ is firing
    ext_irq_ack(1 << 0); // acknowledge external IRQ; clears the according bit in pending register
    execute_handler_source_0();
  }

  if (source & (1 << 1)) { // check if IRQ is firing
    ext_irq_ack(1 << 1); // acknowledge external IRQ; clears the according bit in pending register
    execute_handler_source_1();
  }
  ...

This is just a general example that is not optimized for latency. But it would work "out of the box" 😉

The question is how many interrupt channels should we provide? 16? 32? 64?

[stnolting]

I have added a first (tested!) version of the new external interrupt controller XIRQ.

Top Entity

• new generics
  • XIRQ_NUM_CH, number of XIRQ channels to implement, 0..32
  • XIRQ_TRIGGER_TYPE trigger type per channel, 32-bit: 0 = level-triggered, 1 = edge-triggered
  • XIRQ_TRIGGER_POLARITY trigger polarity per channel, 32-bit: 0 = low-level/falling-edge, 1 = high-level/rising-edge
• new signals
  • xirq_i (XIRQ_NUM_CH-1 downto 0): XIRQ interrupt request lines

Sources

• rtl file: rtl/core/neorv32_xirq.vhd
• software "driver":
  • sw/lib/include/neorv32_xirq.h
  • sw/lib/source/neorv32_xirq.c
• demo program: sw/example/demo_xirq/main.c
• documentation: datasheet "External Interrupt Controller (XIRQ)"

Feel free to comment if have questions, ideas or any remarks. 😉