Incorrect mixture of AIA interfaces

[reosdev]

RISC-V AIA specifies two interrupt delivery mechanisms:

1. MSI for the cores that support AIA. In this case the core side shall implement IMSIC file(s) with associated CSR-based interface. This is not supported by ACLIC.
2. Direct delivery to the cores that are not aware of AIA (incl. none RISC-V cores). There is no AIA functionality required at the core side except ability to handle single wired external interrupt. For such cores the APLIC provides IDC (interrupt delivery control) MMIO structure in addition to the domain configuration interface.

IDC MMIO structure is similar but not equal to the IMSIC CSR interface. ACLIC document describes mixture of AIA APLIC domain configuration, IDC and IMSIC interfaces. Short summary in the following table:

Reg name        IMSIC CSRs                  IDC MMIO structure      ACLIC  

topi            major id/prio               external id/prio        IMSIC-style  
topei           external eiid               n/a                     alias to IDC.topi, adds claim, wrong and confusing   
claimi          n/a                         ext claim               removed, reason not clear  
eithreshold     eiid/prio threshold         n/a                     alias to IDC ithreshold, wrong usage  
ithreshold      n/a                         id threshold            aliased, shall be used instead of eithreshold  
iedelivery      delivery on/off/mode        n/a                     IMSIC-style, wrong and confusing  
idelivery       n/a                         delivery on/off         removed, reason unclear  
eie             enable                      n/a                     IMSIC-style alias to APLIC domain configuration, index by ID (instead EIID) is wrong and confusing   
eip             pending                     n/a                     IMSIC-style alias to APLIC domain configuration, index by ID (instead of EIID) is wrong and confusing   

ACLIC specification mixes the IMSIC, APLIC IDC and domain configuration interfaces in part of registers names and functions. From one side it looks like APLIC IDC, from other side it mimics to IMSIC controller.

The suggestion is to either adopt APLIC domain configuration and IDC interface or switch to IMSIC-based core side controller.

[christian-herber-nxp]

You have a point.
I feel like we might actually need an additional delivery mode for ACLIC, that has neither IDC or the MSI address config.
This would also simplify the aliasing, as it is no longer needed to define the aliases towards the IDC registers.

Would this work from your end?
Unfortunately, DM is defined as a single bit. It seems the higher bits have intentionally been reserved to be able to extend this with new modes, but I am not sure it is right to make this field 2b wide. I think I would still do it. If not ok, the ARC will tell us.

[christian-herber-nxp]

I have created this PR introducing a new setting to DM: #583
I think this is the right direction and hope this makes it more acceptable for you.

[reosdev]

Proposal for ACLIC interface in APLIC style (indirect CSRs)

Group       Registers           Description
--------------------------------------------------------------------------------------
config      domaincfg           interrupt enable/disable
            sourcecfg[1..1023]  APLIC-like interrupt configuration
            target[1..1023]     APLIC-like interrupt priorities

IP-bits     setipnum            set IP-bit by number (injection interface)
            clripnum            clear IP-bit by number
    
IE-bits     setienum            set IE-bit by number 
            clrienum            clear IE-bit by number

IDC         idelivery           enable/disable
            iforce              test interface (optional)
            ithreshold          interrupt priority threshold
            topi                top P&E interrupt ID and PRIO
            claimi              interrupt claim (ACLIC vectorization/preemption is off)

Notes:

• Major interrupts wired to major interrupt controller (ACLIC vectorization/nesting is disabled) and to external interrupt controller (ACLIC vectorization/nesting is enabled).
• IDC structure part shall be implemented for both M and S modes.
• IDC structure can be mapped to single indirect CSR frame (single iselect value)
• "Preemption configuration" (xipreemptcfg) and "previous interrupt context" (xpinstatus) can be moved to iCSRs (not required for interrupt handlers, no need of CSR efficiency).
• Interrupt source and target configuration registers can be grouped by xiselect value.

Pros:

• Interface in iCSRs, minimum new CSRs.
• No AIA CSRs/iCSRs are required, no dependency on AIA.
• Better SW compatibility (exact subset of APLIC interface incl. IDC structure in iCSR space)
• Single place to define priorities (both major & external)
• ISA compliant register interface and priority order for legacy ISA interrupt handling modes (backward compatibility)

Cons:

• Lack of security (system level interrupt assignment visible to less privileged mode, same as current version).
• Dependency on Smcsrind/Sscsrind (same as current version, can be optimized by using of AIA-style iCSRs).
• Interrupt filtering is difficult (cannot inject interrupt with the same ID as the HW source, same as current version).

[christian-herber-nxp]

CSR instructions are somewhat different the load/stores.
As an example, you cannot map IDC claimi to a CSR, as it has a side effect on read, which is disallowed on CSRs.

How does you proposal expose the interrupt enable bits and the pending bits?

As in the other issue, I think mixing the redirection of major interrupts to external interrupts into this is unnecessary.
I think we should just discuss the interface.

"Preemption configuration" (xipreemptcfg) and "previous interrupt context" (xpinstatus) can be moved to iCSRs (not required for interrupt handlers, no need of CSR efficiency).

This can be discussed, but I would like to see a separate issue on that. As the spec is modular, fast access to this is needed if you do not implement trap push/pop.

[reosdev]

CSR instructions are somewhat different the load/stores.
As an example, you cannot map IDC claimi to a CSR, as it has a side effect on read, which is disallowed on CSRs.

Do not understand this comment. The proposal above assumes iCSR-mapped interface. Actually the only xintstatus (from current ACLIC specification) cannot be easilly moved to iCSRs.

As in the other issue, I think mixing the redirection of major interrupts to external interrupts into this is unnecessary.
I think we should just discuss the interface.

Don't you agree that implementing of iprio array and 32-elements vector tables for major interrupts is expensive for low-area configurations?

This can be discussed, but I would like to see a separate issue on that. As the spec is modular, fast access to this is needed if you do not implement trap push/pop.

Lets first agree on overall interface look.

[christian-herber-nxp]

CSR instructions are somewhat different the load/stores.
As an example, you cannot map IDC claimi to a CSR, as it has a side effect on read, which is disallowed on CSRs.

Do not understand this comment. The proposal above assumes iCSR-mapped interface. Actually the only xintstatus (from current ACLIC specification) cannot be easilly moved to iCSRs.

claimi in the APLIC is defined as

When this value is not zero, reading claimi has the
simultaneous side effect of clearing the pending bit for the reported interrupt identity, if possible.

You cannot expose such a register to an indirect CSR access.

As there is already an xtopei register defined, I think it will be very hard to justify adding another such mechanism.

[reosdev]

You cannot expose such a register to an indirect CSR access.

I don't see the problem. If this works in case of MMIO (as used by APLIC), then why the iCSR mapped version may have trouble?

[christian-herber-nxp]

because it violates the rules for CSRs.

Standard CSRs do not have side effects on reads but may have side effects on writes.

[reosdev]

According to your citation of AIA/APLIC:

When this value is not zero, reading claimi has the
simultaneous side effect of clearing the pending bit for the reported interrupt identity, if possible.

I still see no problem there. Immediate effect is not required, just predictable. This claim interface is required for non-preemptive handling, so there always enough cycles before next interrupt may be taken.

If you are warry about side effect on read operation itself, then I think adding requirement to perform read-write access to claimi is not a big problem.

[reosdev]

As there is already an xtopei register defined, I think it will be very hard to justify adding another such mechanism.

Justification is very simple:

• xtopei register is defined by another specification and has different meaning.
• xtopei as claim/complete interface restricts the implementation a lot. In case of CSR, the effect (clear pending bit, re-arbitration and new xtopei value) should be taken immediately. Re-arbitration in less than 1 cycle is very hard restriction for low area designs. This works fine in case of IMSIC file, where arbitration is quite simple. If we have to compare numeric priorities as in case of APLIC/ACLIC, then this is not trivial.

[christian-herber-nxp]

the effect (clear pending bit, re-arbitration and new xtopei value) should be taken immediately. Re-arbitration in less than 1 cycle is very hard restriction for low area designs. This works fine in case of IMSIC file, where arbitration is quite simple. If we have to compare numeric priorities as in case of APLIC/ACLIC, then this is not trivial.

I agree that this is difficult, and will likely take a couple of cycles for higher number of sources.
At the same time, I have not seen anything in the spec that mandates this.
Also, having an xtopei indirect CSR does not change anything.

Practically speaking, I do not believe there is any issue. There will be many cycles in between reading xtopei, potentially even guaranteed by design when used by push/pop.
I agree we should take a note on that in the spec, as it is clearly different from the behavior in IMSIC.

[reosdev]

Practically speaking, I do not believe there is any issue. There will be many cycles in between reading xtopei, potentially even guaranteed by design when used by push/pop.
I agree we should take a note on that in the spec, as it is clearly different from the behavior in IMSIC.

I think that this is mistake to rely on push/pop. In vectored mode the interrupt ID (required to make a jump by vector) must be known before first instruction of particular interrupt handler can be executed.

However, the topic is about incorrect mixture of interfaces. And this is the case:

• AIA defines topi for major interrupts only. This is clear overhead to extend the number of major interrupts when another local interrupt controller is available.
• AIA/IMSIC defines xtopei for IMSIC interrupts only when MSI delivery is enabled (incl. claim/complete feature). This register cannot report original interrupt ID (only priority is available in case of MSI).
• AIA/APLIC defines IDC.topi to report top P&E external interrupt when Direct delivery is enabled (this is not xtopi).
• AIA/APLIC defines IDC.claim to claim top P&E external interrupt when Direct delivery is enabled (similar to xtopei, but for direct delivery).

I think usage of IMSIC interface for ACLIC is not correct and propose to reuse APLIC IDC structure. ACLIC delivery is closer to APLIC direct delivery rather than MSI.

[christian-herber-nxp]

If we were to change to a more APLIC style behavior, you would still want

• an ie and ip array. This is the most efficient style of CSR to interact with. The APLIC definitions have been optimized for memory mapped registers.
• an xtopei CSR, directly mapped, because we do not mandate push/pop. Indirect CSR is to slow without push/pop
• a threshold CSR that is a direct CSR, as handlers have to access this quite a bit.

To conserve CSR encoding space, I think it is extremely likely that the ARC will want us to reuse the encodings already present for IMSIC.

[reosdev]

If we were to change to a more APLIC style behavior, you would still want

• an ie and ip array. This is the most efficient style of CSR to interact with. The APLIC definitions have been optimized for memory mapped registers.

APLIC domain configuration has ie/ip bits that can be optionally exposed via iCSRs without any problem. For compact implementations setxxnum/clrxxnum is enough. I don't see advantage of multi-bit access to ie/ip bits.

• an xtopei CSR, directly mapped, because we do not mandate push/pop. Indirect CSR is to slow without push/pop

Explicit access to IDC interface is required only in case of non-vectored (non-ACLIC) interrupt handling mode when indirect access overhead has no impact.

• a threshold CSR that is a direct CSR, as handlers have to access this quite a bit.

I assumed that nested vectored mode manages the threshold at the HW side. I cannot imagine real scenario when nested vectored interrupt handler needs to access threshold value. For RISC-V standard interrupt handling mode indirect access overhead is not an issue.

To conserve CSR encoding space, I think it is extremely likely that the ARC will want us to reuse the encodings already present for IMSIC.

ACLIC interface is orthogonal to IMSIC. Using IMSIC registers for ACLIC operation is confusing. Why ARC may require IMSIC interface?