Major and external interrupts unification [proposal]

[evgeniy-paltsev]

Current ACLIC spec has two interrupt types: major and external interrupts.

To achieve interrupts nesting and vectoring for both interrupt types the ACLIC spec introduces several new CSRs and extensions:

• new mivt, sivt, meivt, seivt CSRs for major and external IVTs
• new Smaiae extension to provide
  • stopi, mtopi CSRs which needed for information about priority and identity of current top major interrupt
  • iprio0-15 iCSRs array to have configurable priority for major interrupts

We want to propose an alternative approach, which is that we unify major and external interrupts:

• In ACLIC mode all major interrupt sources are forwarded to ACLIC, according to their identity numbers. CLINT is not used at all and ACLIC becomes the only source of interrupts for M/S-mode.
• When ACLIC mode is disabled (legacy mode) major interrupts are routed to CLINT (as in RISC-V ISA). In that mode there is no configurable priority for major interrupts, no vectoring, no nesting.

The resource-constrained systems targeted by ACLIC are likely to have limited number of major local interrupt sources (M-timer, S-timer, M-software interrupts). Among all of them, only the M-timer interrupt is mandatory, according to the RISC-V ISA spec. So the resources duplication between CLINT and ACLIC is minimal.

Proposed approach has several advantages:

• we don't need multiple IVTs and mivt, sivt, meivt, seivt CSRs. Existing xtvec CSRs can be used for vector base.
• no need in mtopi, stopi CSRs
• no need in iprio0-15 iCSRs array
  • we can avoid introducing of new Smaiae extension and drop AIA dependency
    • if we drop AIA dependency we can also drop miph, siph, mieh, sieh, midelegh CSRs
• we simplify interrupt trap logic
• we simplify interrupt configuration logic - all interrupts are configured the same way
• we simplify push logic of tpush extension
• still fully compatible with RISC-V ISA
• trivial further size reduction:
  • i.e.: application-specific IC with stricter resource constraints (and without requirement of being fully compatible to RISC-V) can implement ACLIC without CLINT at all. No ACLIC architectural changes needed for that, HW still be fully compatible with ACLIC handling mode

Since this approach offers a minimalistic ACLIC implementation, it may be more beneficial to use it as the default rather than as a separate extension.

[mark-honman]

This proposal is a lot like the way the CLIC spec was a year ago. At that time there was a distinct CLIC vector table - which enabled seamless switching between CLINT vectored mode, and CLIC vectored mode. The previous CLIC spec also contained a mechanism designed to enable tail-chaining, called MNXTI (sort of like claimi, but overcomplicated).

One useful idea implicit in this proposal is that synchronous exceptions can be handled without a separate trap handler address, because interrupt ID 0 cannot be used (according the RISC-V Privileged spec). At least, I am assuming that the trap handler address is found in the first slot of the vector table.

However the cost of the proposal is that it introduces a different set of concepts to AIA, or even worse re-uses some AIA mechanisms but drops others (assuming that eidelivery, topei, etc. all go). So from a SW developer perspective there is very little AIA knowledge or code that can be re-used.

Having both implemented RTl for the previous CLIC spec and written SW to use it, I see AIA alignment as highly desirable.

I've not looked at all the claimed simplifications, but some of them don't seem to be any kind of saving, just a couple of examples:

1. Simplified interrupt trap logic. If this means SW, no it's just the same. If this means HW, there will be a potential saving of 10s of bit-registers.
2. saving of iprio0-15 - illusory, because registers only need to be implemented for the major interrupts that actually exist in HW.
3. CLINT delete option - doesn't save logic because if some interrupts are handled by CLINT, the ACLIC will be smaller. Arguably the more interrupt are handled by CLINT, the greater the area saving because CLIC requires more complex functionality per interrupt.

[reosdev]

I don't think this proposal introduces concepts different from AIA. It inherits and is fully compliant with APLIC direct interrupt delivery. This is much better compared to reusing AIA register names with redefined functionality in background (this does not make it compatible with AIA). In the vectored mode, any solution will not be AIA compliant in part of interrupt handling.

Saving registers is not an intend of this proposal. The target is to get only single place to work with priorities. This allows to manage interrupt nesting at the controller side in HW (like it was done in previous ACLIC versions). This significantly simplifies the implementation of advanced latency optimizations like late preemption and tail chaining. Single source of preemption may guarantee the level information (that cannot be broken by improper SW). E.g., ACLIC in primary mode can distinguish between normal and interrupt context and provide this information to the core triggering stack switch and context push/pop (instead of relying on SW agreements and complex conditions).

[christian-herber-nxp]

As several of you have previously observed, most systems will have a very limited use of major interrupts.
E.g. Zephyr uses only the software interrupt, plus the timer interrupt if you choose to.
External interrupt is used in addition if you are using the PLIC.
Additionally, interrupts like the software interrupt will tend to not be direct interrupts (in Zephyr very clearly this is an OS interrupt). Same would apply for the timer interrupt. Thus, HW-vectoring does not benefit them.

I am entertaining the idea of dropping dropping the HW-vectoring of major interrupts. They could just trap to xtvec.
This gets rid of one CSR and its associated state.

I am very skeptical of moving the current major interrupts away from the register in which they have lived for the past 10+ years.
I do not yet understand why the current proposal does not support managing interrupt nesting in HW. It would be great if you could elaborate on that.

[reosdev]

Proposed solution keeps the compatibility with current implementation when there is no need in nested vectored interrupts (major interrupts are in CSRs as during past 10+ years). For new interrupt handling modes it will be strange to have different way to work (configure and handle) with interrupts in one system. Trick with major interrupt redirection allows to have the same configuration space, vector table and handling interface for all interrupts. The cost of this is little, whereas the benefit is obvious.

The ACLIC nesting management is 50/50 HW/SW. There is a way to move all nesting management to HW and make it fully transparent for SW (no need in extra status and threshold management for SW). This feature may be run-time configurable providing backward compatibility with existing SW and/or SW that does not care about nesting.

[christian-herber-nxp]

Having the nesting transparent to software is not a feature in my eyes.
SW control over the threshold is important.
It is anyway needed for PCP.
In addition, for ISR offloading, software needs to be able to do everything that hardware does to emulate an interrupt without a physical source.

[evgeniy-paltsev]

Hi @christian-herber-nxp,

SW control over the threshold is important.

I totally agree.

Moving nesting management to HW doesn't mean we remove SW control over threshold.
It simply allows us to avoid manual saving/restoring of previous interrupt threshold value (pithreshold).

Having the nesting transparent to software is not a feature in my eyes.

This is especially valuable in the context of #614. If we don't have pithreshold - we don't really need new separate xpistatus CSR and we can simply save/restore original xstatus register, without copying more and more bits to xpistatus.